RabbitMq——生产端可靠性投递与消费端幂等性

生产端-消息可靠性投递方案+幂等性

1、消息可靠性投递说明

1.1、消息落库方案

1.2、延迟投递方案

2、 幂等性

2.1、消费端-幂等性保障

2.2、业界主流的幂等性操作

1、消息可靠性投递说明

所谓消息可靠性投递，就是解决 “如何保障消息 100%的投递成功？” 的问题。

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

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

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

• 方案A：消息落库，对消息状态进行打标。
• 方案B：消息的延迟投递，做二次确认，回调检查。

1.1、消息落库方案

第一步：做业务数据的入库，和消息数据的入库（此时消息状态为：未成功0）。这一步要加事务，防止业务数据入库成功而消息数据入库失败，比如用户商品下单成功，但是因为订单消息入库失败，而导致订单没办法同步到物流系统，导致用户收不到商品。
第二步：向消息服务器发送消息。
第三步：消息服务器收到消息后，发送确认消息（确认应答) Ack。
第四步：生产者接收到服务器发送的确认消息 Ack，修改数据库中消息的状态为成功（1）。
第五步：定时任务，查询数据库中消息状态为未成功（0）的数据。
第六步：重新发送第五步中的数据。
第七步：定时任务查询，当重新发送的次数，大于一定的值时，修改该条消息状态为发送失败（2）。

步骤 1 中这里首先保证业务数据入库，然后再保证消息数据入库（记录即将发送的队列消息信息到数据库），然后发送队列消息。这里业务数据库和消息数据库可以是同一个。这里操作了两次数据库，对高并发和海量数据的业务场景，比较影响性能。

但是这个方法也有弊端

1. 弊端1：第一步将消息存入数据库的时候 如果存入的时候发生异常 那么会造成事务回滚，且事务会导致性能下降。
2. 弊端2：应为是两个数据库更多的时候可能会有45个 那么插入耗时肯定很长

1.2、延迟投递方案

 

第一步：上游服务器（消息生产者）维护业务数据入库。
第二步：上游服务器（消息生产者）向消息服务器发送队列消息。
第三步：上游服务器（消息生产者）在 first Send 后 的 n 秒(时间根据业务自定义)，发送延迟投递消息。
第四步：下游服务器（消息消费者）监听消息服务器上的消息，并对消息进行消费。
第五步：下游服务器（消息消费者）向消息服务器发送确认消息。
第六步：Callback 服务监听下游服务发送的消息（第五步发送的消息），如果收到消息则对消息状态（投递成功）做记录。
第七步：Callback 服务监听上游服务器发送的消息（第三步发送的消息），查看该消息是否在第六步中已记录。如果没有记录，则通知上游服务再次发送消息（RPC Res）。
 

 

2、 幂等性

2.1、消费端-幂等性保障

如果电商系统发送一个订单消息两次到物流系统，如果不实现幂等性，那么物流系统就会发送两次商品（太亏了）。

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

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

2.2、业界主流的幂等性操作

（1）唯一ID + 指纹码 机制，利用数据库主键去重来实现。指纹码可以是订单号+商品类型+商品号等，只要能唯一就行。

消息入库前先执行一下查询，如果该查询有数据，则表示已消费，如果查询无数据，则按查询id 进行插入操作。

select count(1) from t_table where id = 唯一ID + 指纹码 （如果该查询有数据，则表示已消费，如果查询无数据，则按查询id 进行插入操作。）

好处：实现简单。

坏处：高并发下有数据库写入的性能瓶颈。

解决方案：根据 ID 进行分库分表进行算法路由。

数据库要对字段进行唯一标识的约束，毕竟两个线程同时插入同一条消息数据时，执行查询语句时，count的结果都是0，两个线程都会执行插入，只有为字段添加了唯一约束，才能保证直插入一次。即使加了唯一约束也要执行一开始的查询，毕竟这样能减少很多数据库的插入操作（插入失败也一样消耗性能）。

（2）利用 Redis 的原子性来实现。

使用Redis 进行幂等，需要考虑的问题。

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