消息如何保障100%的投递成功?
什么是生产端的可靠性投递?
u 保障消息的成功发出
u 保障MQ节点的成功接收
u 发送端收到MQ节点(Broker)确认应答
u 完善的消息进行补偿机制
BAT/TMD互联网大厂的解决方案:
u 消息落库,对消息状态进行打标
u 消息的延迟投递,做二次确认,回调检查
幂等性概念
幂等性是什么?
u 我们可以借鉴数据库的乐观锁机制
u 比如我们执行一条更新库存的SQL语句
u Update t_repository set count = count -1,version = version + 1 where version = 1
u Elasticsearch也是严格遵循幂等性概念,每次数据更新,version+1(博主博客前面有提到)
消费端-幂等性保障
在海量订单产生的业务高峰期,如何避免消息的重复消费问题?
消费实现幂等性,就意味着,我们的消息永远不会消费多次,即使我们收到了多条一样的消息
业界主流的幂等性操作
唯一ID+指纹码机制,利用数据库主键去重
利用Redis的原子性去实现
唯一ID+指纹码 机制
唯一ID+指纹码机制,利用数据库主键去重
Select count(1) from T_order where ID=唯一ID+指纹码
好处:实现简单
坏处:高并发下有数据库写入的性能瓶颈
解决方案:根据ID进行分库分表进行算法路由
利用Redis的原子性去实现
使用Redis进行幂等,需要考虑的问题
第一:我们是否要进行数据落库,如果落库的话,关键解决的问题是数据库和缓存如何做到原子性?
第二:如果不进行落库,那么都存储到缓存中,如何设置定时同步策略?
over......
备案号:湘ICP备19000029号
Copyright © 2018-2019 javaxl晓码阁 版权所有