RabbitMQ之消息模式

消息100%的投递

消息如何保障100%的投递成功？

什么是生产端的可靠性投递？

保障消息的成功发出
保障MQ节点的成功接收
发送端收到MQ节点（Broker）确认应答
完善的消息进行补偿机制

BAT/TMD互联网大厂的解决方案：

消息落库，对消息状态进行打标
消息的延迟投递，做二次确认，回调检查

方案1一 消息落库，对消息状态进行打标

流程如下：
第1步：将订单入库，创建一条MSG(状态为0) 入MSG DB库
第2步：将消息发出去
第3步：监听消息应答(来自Broker)
第4步：修改消息的状态为1(成功)
第5步：分布式定时任务抓取状态为0的消息
第6步：将状态为0的消息重发
第7步：如果尝试了3次(可按实际情况修改)以上则将状态置为2(消息投递失败状态)

方案二 消息的延迟投递，做二次确认，回调检查

第1步：首先业务数据落库，成功才后第一次消息发送
第2步：紧着着发送第2条消息（可以用于寻找第1条消息），用于延迟(可能2,3分钟后才发送)消息投递检查
第3步：Broker端收到消息后，消费端进行消息处理
第4步：处理成功后，发送confirm消息
第5步：收到confirm消息后，将消息进行持久化存储
第6步：收到了delay消息，检查DB数据库，若对应的第1条消息已处理完成，则不做任何事情；若收到了delay消息，检查DB数据库，发现对应的第1条消息处理失败(或无记录)，则发送重传命令到上游服务，循环第1步

幂等性概念

幂等性是什么？

我们可以借鉴数据库的乐观锁机制
比如我们执行一条更新库存的SQL语句
Update t_repository set count = count -1,version = version + 1 where version = 1
Elasticsearch也是严格遵循幂等性概念，每次数据更新，version+1（博主博客前面有提到）

消费端-幂等性保障

在海量订单产生的业务高峰期，如何避免消息的重复消费问题？

消费实现幂等性，就意味着，我们的消息永远不会消费多次，即使我们收到了多条一样的消息

业界主流的幂等性操作

唯一ID+指纹码机制，利用数据库主键去重
利用Redis的原子性去实现

唯一ID+指纹码 机制

唯一ID+指纹码机制，利用数据库主键去重
Select count(1) from T_order where ID=唯一ID+指纹码
好处：实现简单
坏处：高并发下有数据库写入的性能瓶颈
解决方案：根据ID进行分库分表进行算法路由

利用Redis的原子性去实现

使用Redis进行幂等，需要考虑的问题
第一：我们是否要进行数据落库，如果落库的话，关键解决的问题是数据库和缓存如何做到原子性？
第二：如果不进行落库，那么都存储到缓存中，如何设置定时同步策略？

Confirm确认消息

理解Confirm消息确认机制

消息的确认，是指生产者投递消息后，如果Broker收到消息，则会给我们生产者 一个应答。
生产者进行接收应答，用来确定这条消息是否正常的发送到Brokerÿ