MQ 消息的可靠性投递

1、消息可靠性投递说明

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

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

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

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

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

1.1、消息落库方案

 

 

• 第一步：做业务数据的入库，和消息数据的入库（此时消息状态为：未成功0）。
• 第二步：向消息服务器发送消息。
• 第三步：消息服务器收到消息后，发送确认消息（确认应答) Ack。
• 第四步：生产者接收到服务器发送的确认消息 Ack，修改数据库中消息的状态为成功（1）。
• 第五步：定时任务，查询数据库中消息状态为未成功（0）的数据。
• 第六步：重新发送第五步中的数据。
• 第七步：定时任务查询，当重新发送的次数，大于一定的值时，修改该条消息状态为发送失败（2）。
   
   
         步骤 1 中这里首先保证业务数据入库，然后再保证消息数据入库（记录即将发送的队列消息信息到数据库），然后发送队列消息。这里业务数据库和消息数据库可以是同一个。这里操作了两次数据库，对高并发和海量数据的业务场景，比较影响性能。

1.2、延迟投递方案

 

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

2、 幂等性

2.1、消费端-幂等性保障

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

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

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

• 唯一ID + 指纹码 机制，利用数据库主键去重来实现。

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

• 好处：实现简单。

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

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

• 利用 Redis 的原子性来实现。

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

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

 
 
 
 
 
 
.