RabbitMQ 100% 投递成功方案详解

一. 生产端的可靠性投递

1. 保障消息的成功发出

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

3. 发送端收到MQ节点（broker）确认应答

4. 完善的消息补偿机制
复制代码

在实际生产中，很难保障前三点的彻底可靠，好比在极端的环境中，生产者发送消息失败了，发送端在接受确认应答时忽然发生网络闪断等等状况，很难保障可靠性投递，因此就须要有第四点完善的消息补偿机制。

2、互联网大厂的解决方案

第一种：消息落库，对消息状态进行达标。具体来讲就是将消息持久化到数据库并设置状态值，收到消费端的应答就改变当前记录的状态。再用轮询去从新发送没接收到应答的消息，注意这里要设置重试次数。

第二种：消息的延迟投递，作二次确认，回调检查。
复制代码

3、消息落库，对消息状态进行打标

消息落库的流程图

流程的示意图如上所示，好比我下单成功了，这是进行 step1，对个人业务数据进行入库，业务数据入库完毕（这里要特别注意必定要保证业务数据入库）再对要发送的消息进行入库，图中采用了两个数据库，能够根据实际业务场景来肯定是否采用两个数据库，若是采用了两个数据库，有人可能就像到了采用分布式事务来保证数据的一致性，可是在大型互联网中，基本不多采用事务，都是采用补偿机制。

对业务数据和消息入库完毕就进入 setp2，发送消息到 MQ 服务上，按照正常的流程就是消费者监听到该消息，就根据惟一 id 修改该消息的状态为已消费，并给一个确认应答 ack 到 Listener。若是出现意外状况，消费者未接收到或者 Listener 接收确认时发生网络闪断，接收不到，这时候就须要用到咱们的分布式定时任务来从 msg 数据库抓取那些超时了还未被消费的消息，从新发送一遍。重试机制里面要设置重试次数限制，由于一些外部的缘由致使一直发送失败的，不能重试太屡次，要否则会拖垮整个服务。例如重试三次仍是失败的，就把消息的 status 设置成 2，而后经过补偿机制，人工去处理。实际生产中，这种状况仍是比较少的，可是你不能没有这个补偿机制，要否则就作不到可靠性了。

要看代码实现的能够去看看个人这个系列：www.jianshu.com/c/c1785aa6c…

4、延迟投递，作二次确认，回调检查。

回想第一种方案，生产端既要对业务数据入库，又要对消息数据入库，这种设计在高并发场景下，真的合适吗？在核心链路上，每一次持久化都是须要很精心考量的，持久化一次就花费 100 - 200 毫秒，这在高并发场景下是忍受不了的。这时候须要咱们的第二种方案了，流程图以下。

upstream Server 就是咱们的上游服务，也就是生产者，生产者将业务数据入库成功后，生成两条消息，一条是当即发送出去给到下游服务 downstream Server的，一条是延迟消息给到 补偿服务 callback Server的。

正常状况下，下游服务监听到这个即时的消息，会发送一条消息给到 callback Server，注意这里不是采用第一种方案里面的返回 ack 方式，而是发送了一条消息给回去。

callback Server 监听到这个消息，知道了刚才有一条消息消费成功了，而后把这个持久化到数据库中，当上游服务发送的延迟消息到达 callback Server 时，callback Server 就会去数据库查询，刚才下游服务是否有处理过这个对应的消息，若是其 msg DB 里面有这个记录就说明这条消息是已经被消费了，若是不存在这个记录，那么 callback Server 就会发起一个 RPC 请求给到上游服务，告诉上游服务，你刚才这个消息没发送成功，须要从新发送一遍，上游服务就从新发送即时和延迟的两条消息出去，按照以前的流程继续走一遍。

虽然第二种方案也是没法作到 100% 的可靠传递，在特别极端的状况，仍是须要定时任务和补偿机制进行辅助的。可是第二种方案的核心是减小数据库操做，这个点很重要！

在高并发场景下，我考虑的不是百分百的可靠性了，而是考虑可用性，性能可否扛得住这个流量，因此我能减小一次数据库操做就减小一次。我上游服务减小了一次数据库操做，个人服务性能相对而言就提升了一些，并且又能把异步 callback Server 补偿服务解耦出来。

5、结论

这两种方案都是可行的，须要根据实际业务来进行选择，大型的超高并发的场景会选择第二种方案，普通的就采用第一种便可。