RabbitMQ 第四课 如何保障100%的投递方案？

3. RabbitMQ的高级特性

本章导航

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

2.幂等性概念详解

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

4. Confirm确认消息、Return 返回消息

5. 自定义消费者

6. 消息的ACK与重回队列

7. 消息的限流

8. TTL消息

9. 死信队列

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


什么是生产端的可靠性投递？
1. 保障消息的成功发出
2. 保障MQ节点的成功接收
3. 发送端收到MQ节点（Broker）确认应答
4. 完善的消息进行补偿机制

生产端 - 可靠性投递（一）
BAT/TMD 互联网大厂的解决方案
1. 消息落库，对消息状态进行打标
2. 消息的延迟投递，做二次确认，回调检查

生产端 - 可靠性投递（三）
1. 保障MQ我们思考如果第一种可靠性投递，在高并发的场景下是否适合？
2. 消息的延迟投递，做二次确认，回调检查。

节省了数据落库的这一步

2. 幂等性概念

幂等性是什么？

1. 我们可以借鉴数据库的乐观锁机制：

2. 比如我们执行一条更新库存的SQL语句

3. update T_reps set count = count -1, version = version +1 where version = 1

一句话概括：可能你要对一件事情进行操作100次，1000次，结果都是相同的。

比如 对一个SQL执行100次1000次，

消费端 - 幂等性保障
在海量订单产生的业务高峰期，如何避免消息的重复消费问题
1. 消费端实现幂等性，就意味着，我们的消息永远不会消费多次，即使我们收到了多条一样的消息。

业界主流的幂等性操作解决方案：
（1）唯一Id + 指纹码 机制，利用数据库主键去重
　　1）select count(1) from T_order where id = 唯一ID + 指纹码
　　2）好处：实现简单
　　3）坏处：高并发下有数据库写入的性能瓶颈
　　4）解决方案：跟进ID进行分库分表进行算法路由
（2）利用Redis的原子性取实现
　　1）第一：我们是否要进行数据落库，如果落库的话，关键解决的问题是数据库和缓存如何做到原子性？
　　2）第二：如果不进行落库，那么都存储到缓存中，如何设置定时同步的策略。


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

标签：第四课,可靠性,落库,保障,100%,确认,RabbitMQ,投递,消息
来源： https://www.cnblogs.com/guchunchao/p/13139428.html