[Java知识库]My技术总结

技术总结（不定期更新）

记录我的日常工作的技术总结，属于个人感悟，不定期更新

代码开发

接口篇

• 接口支持高级分页

分页可以减少客户端接收的数据数目，但是当你需要将分页结果与不断接收的新条目结合时，通常的限制limit和偏移offset分页参数是低效的，因为每次当有个新条目在服务端被添加到先前的集合时，先前发送到客户端的偏移offset都变得无效，而且客户端无法得知在两次请求间新增了多少条目。保持客户端同步一个比较好的办法是使用before_id和after_id参数组合，比如客户端将已知的最新条目的id作为after_id请求参数，然后检索之后创建的新条目（当分页结果总数比较大时，获取靠后的分页结果会及其的慢，因为offset分页已经效率很低了，即使已经加了索引——实际工作场景中遇到的是要获取一个总数为10万的分页结果[该表做了8个分库操作]，每页500条数据，当获取靠后页码的分页结果时，查询效率已经很低了，有的甚至超过了5秒，这对于分布式系统是无法接受的）

• 提供了分页的外部接口就不要再提供查询总数接口

过多的给外部提供接口会让后期维护成本变得更高，会使得难以管理和改动

MQ篇

• 如果MQ由于种种原因无法保证数据库操作和发MQ在同一个事务下保证，则必须先进行数据库事务操作，再发MQ

1. 如果先发送MQ再进行数据库事务操作，则可能会造成MQ已经发送成功，数据库事务提交失败，此种错误不易进行补偿
2. 如果先进行数据库事务操作，则发送MQ，当MQ发送失败，需要记录失败日志，同时进行告警或者通知到相关人员，进行MQ重发操作进行补偿
3. 如果是使用的MQ本地消息表或者其他方式能够保证数据库事务和MQ在同一事务，则无需关心此问题（RocketMQ、Seata、Hmily等来解决）

指导文章

专题文章

梁的主页

• 谈谈线程池
• 接口设计技巧和最佳实践

非专题文章

• 分布式事务解决方案-RocketMQ实现可靠消息最终一致性
• hmily: 高性能异步分布式事务TCC框架
• Hmily 源码解析

大厂技术

美团技术 （github）

• 配置中心——MCC
• PRC——Mthrift（基于thrift）
• 任务调度——Crane
• 分布式监控——CAT【开源】
• 内部知识网——学城（大佬技术文章都有，有广度有深度）
• 缓存——squirrel（基于Redis）
• MySQL访问——Zebra【开源】

京东技术（gitee）

• 配置中心——DUCC
• PRC——JSF（基于Dubbo）
• 任务调度——天鸽（基于xxl-job）
• 分布式监控——UMP
• 内部知识网——CF
• 缓存——Laf（基于Redis）

百度技术（gitee）