RabbitMQ消息模式（消息100%的投递，幂等性概念，自定义消费者）

消息100%的投递

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

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

2. 保障消息的成功发出

3. 保障MQ节点的成功接收

4. 发送端收到MQ节点（Broker）确认应答

5. 完善的消息进行补偿机制

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

方法1. 消息落库，对消息状态进行打标

用户现在是下订单完毕后
我们需要将订单存进数据库 将短信消息也存进数据库

1. step1 第一步就是将消息入库的 订单数据库 消息数据库 这时候消息数据库字段的状态为0

2. step2 发送指令给broker 做异步处理 也就是发短信

3. step3 broker接到指令 发送消息给确认消息的监听器Confirm Listener 在监听器确认指令后就可以投递成功

4. step4 我们之前将短信存入数据库时并没有发送短信 而且那时候字段为0 现在收到确认消息后我们修改MSG DB数据库字段为1
   这就是将消息状态进行打标 这就确保了用户订单下单成功了 短信发送也成功了

但是这个方法也有弊端

1. 弊端1：第一步将消息存入数据库的时候 如果存入的时候发生异常 那么会造成事务回滚
2. 弊端2：应为是两个数据库更多的时候可能会有45个 那么插入耗时肯定很长
3. 消息的延迟投递，做二次确认，回调检查

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

1.还是先订单入库
step1：直接发送消息到broker去
step2：延迟发送 间隔几秒再次发送消息到broker去
第一次发送消息到broker里面去是为了发送短信 我们发了一个消息过去
第二次发送消息到broker里面去是为了检查短信有没有发送成功
将订单DB 和短信发送DB完全解耦了

只有短信发送成功了 才会将信息记录到数据库里面去

幂等性概念

幂等性是什么？

消费端-幂等性保障
核心思想在海量订单产生的业务高峰期，如何避免消息的重复消费问题？

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

业界主流的幂等性操作
唯一ID+指纹码机制，利用数据库主键去重
利用Redis的原子性去实现

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

利用Redis的原子性去实现
使用Redis进行幂等，需要考虑的问题

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

Confirm确认消息

理解Confirm消息确认机制
消息的确认，是指生产者投递消息后，如果Broker收到消息，则会给我们生产者 一个应答。
生产者进行接收应答，用来确定这条消息是否正常的发送到Broker，这种方式也是消息的可靠性投递的核心保障

如何实现