tencent cloud

RabbitMQ 是具有代表性的开源消息中间件，当前较多地应用于企业系统内，用于对数据一致性、稳定性和可靠性要求较高的场景中。
　　　
腾讯云 CMQ 基于 RabbitMQ/AMQP 高可靠的原理，并使用 Raft 协议重新设计实现，在可靠性、吞吐量和性能上有了大幅提升。

本文将重点介绍 RabbitMQ 的可靠性原理、腾讯云 CMQ 进行的改进以及性能对比。

RabbitMQ 的消息可靠交付

确认机制

网络异常、机器异常、程序异常等多种情况都可能导致业务丢失消息。对消息进行确认可以解决消息的丢失问题，确认成功意味着消息已被验证并正确处理。

RabbitMQ 使用生产消息确认、消费者确认机制来提供可靠交付功能。

• 生产消息确认：生产者向MQ发送消息后，等待 MQ 回复确认成功；否则生产者向 MQ 重发该消息。此过程可以异步进行，生产者持续发送消息，MQ 将消息批量处理后再回复确认；生产者通过识别确认返回中的 ID 来确定哪些消息被成功处理。

• 消费者确认：MQ 向消费者投递消息后，等待消费者回复确认成功；否则 MQ 重新向消费者投递该消息。该过程同样可以异步处理，MQ 持续投递消息，消费者批量处理完后回复确认。

可以看出 RabbitMQ/AMQP 提供的是“至少一次交付”（at-least-once delivery），异常情况下，消息会被重复投递或消费。

消息存储

为提高消息的可靠性，保证在 RabbitMQ 重启服务不可用时，要对收到的消息持久化写入磁盘。在收到消息时 RabbitMQ 将消息写入文件中，当写入达到一定数量或一定时间周期后 RabbitMQ 将文件落盘存储。

生产消息确认就是在消息落盘存储后，MQ向生产者回复已落盘存储的消息 ID。

腾讯云 CMQ 与 RabbitMQ 的对比

CMQ 与 RabbitMQ 的底层原理、实现方式有很多相似之处，但在更大程度上进行了升级改造：

功能升级

除了生产、消费确认机制，CMQ 还提供了消费回溯功能。

用户可以指定腾讯云 CMQ 保存生产消息一定天数，随后将消费回溯到该时间段内某一时间点，从该点开始重新消费。在用户业务逻辑异常时，以时间为起点的消息重放功能对业务恢复非常有帮助。

性能优化

可用性提升

CMQ 和 RabbitMQ 都能够使用多台机器进行热备份，提高可用性。CMQ 基于 Raft 算法实现，简单易维护。RabbitMQ 使用自创的 GM 算法（Guaranteed Multicast），学习难度较高。

Raft 协议中，Log 复制只要大多数节点向 Leader 返回成功，Leader 就可以应用该请求，向客户端返回成功：

　　　
GM 可靠多播将集群中所有节点组成一个环。Log 复制依次从 Leader 向后继节点传播，当 Leader 再次收到该请求时，发出确认消息在环中传播，直至 Leader 再次收到该确认消息，表明 Log 在环中所有节点同步完成。

GM 算法要求 Log 在集群所有节点同步之后才能向客户端返回成功；Raft 算法则只要求大多数节点同步完成。Raft 算法在同步路径上比 GM 算法减少了近一半的等待时间。

CMQ 对比 RabbitMQ 的性能测试

测试场景如下：三台同样配置的机器组成一个集群，腾讯云 CMQ、RabbitMQ 均配置为镜像队列，数据均在三台机器上同步。腾讯云 CMQ 和 RabbitMQ 都开启生产、消费消息确认机制。测试中的生产消息大小为1KB。

测试数据如下：

在高可靠场景中，CMQ 吞吐量优于 RabbitMQ 的四倍以上。