RabbitMQ 是具有代表性的开源消息中间件，当前较多地应用于企业系统内，用于对数据一致性、稳定性和可靠性要求较高的场景中。
腾讯云 CMQ 基于 RabbitMQ 高可靠的原理，并使用 Raft 协议重新设计实现，在可靠性、吞吐量和性能上有了大幅提升。
本文将重点介绍 RabbitMQ 的可靠性原理、腾讯云 CMQ 进行的改进以及性能对比。
RabbitMQ 的消息可靠交付
确认机制
网络异常、机器异常、程序异常等多种情况都可能导致业务丢失消息。对消息进行确认可以解决消息的丢失问题，确认成功意味着消息已被验证并正确处理。
?
RabbitMQ 使用生产消息确认、消费者确认机制来提供可靠交付功能。
生产消息确认：生产者向MQ发送消息后，等待 MQ 回复确认成功；否则生产者向 MQ 重发该消息。此过程可以异步进行，生产者持续发送消息，MQ 将消息批量处理后再回复确认；生产者通过识别确认返回中的 ID 来确定哪些消息被成功处理。
消费者确认：MQ 向消费者投递消息后，等待消费者回复确认成功；否则 MQ 重新向消费者投递该消息。该过程同样可以异步处理，MQ 持续投递消息，消费者批量处理完后回复确认。
可以看出 RabbitMQ 提供的是“至少一次交付”（at-least-once delivery），异常情况下，消息会被重复投递或消费。
消息存储
为提高消息的可靠性，保证在 RabbitMQ 重启服务不可用时，要对收到的消息持久化写入磁盘。在收到消息时 RabbitMQ 将消息写入文件中，当写入达到一定数量或一定时间周期后 RabbitMQ 将文件落盘存储。
生产消息确认就是在消息落盘存储后，MQ向生产者回复已落盘存储的消息 ID。
腾讯云 CMQ 与 RabbitMQ 的对比
CMQ 与 RabbitMQ 的底层原理、实现方式有很多相似之处，但在更大程度上进行了升级改造：
功能升级
除了生产、消费确认机制，CMQ 还提供了消费回溯功能。
用户可以指定腾讯云 CMQ 保存生产消息一定天数，随后将消费回溯到该时间段内某一时间点，从该点开始重新消费。在用户业务逻辑异常时，以时间为起点的消息重放功能对业务恢复非常有帮助。
性能优化
性能指标 | 说明 |
网络 IO | CMQ 能够批量生产/消费消息，RabbitMQ 则不支持批量生产。在大量小消息场景中，CMQ 具有更少的请求数和更低的平均延迟。 |
文件 IO | CMQ 生产/消费消息顺序写单个文件，并周期性落盘存储，能最大限度地充分利用文件系统缓存。RabbitMQ 持久化消息机制为先入内存队列进行状态转换，然后写日志缓存，最后写消息文件和索引文件（索引文件为顺序写、消息文件为随机写），涉及三次 IO 操作，性能较差。 |
CPU 性能 | RabbitMQ 的日志缓存和状态转换运算较为复杂，需大量耗用 CPU 资源，性能较差。 |
可用性提升
CMQ 和 RabbitMQ 都能够使用多台机器进行热备份，提高可用性。CMQ 基于 Raft 算法实现，简单易维护。RabbitMQ 使用自创的 GM 算法（Guaranteed Multicast），学习难度较高。
Raft 协议中，Log 复制只要大多数节点向 Leader 返回成功，Leader 就可以应用该请求，向客户端返回成功：
?
?
GM 算法要求 Log 在集群所有节点同步之后才能向客户端返回成功；Raft 算法则只要求大多数节点同步完成。Raft 算法在同步路径上比 GM 算法减少了近一半的等待时间。
CMQ 对比 RabbitMQ 的性能测试
测试场景如下：三台同样配置的机器组成一个集群，腾讯云 CMQ、RabbitMQ 均配置为镜像队列，数据均在三台机器上同步。腾讯云 CMQ 和 RabbitMQ 都开启生产、消费消息确认机制。测试中的生产消息大小为1KB。
测试环境 | 环境说明 |
CPU | 24核 Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz |
内存 | 64G |
磁盘 | 12*2T SATA 12块 SATA 组成 Raid0 |
网卡 | 10G |
Linux 版本 | 2.6.32.43 |
RabbitMQ 版本 | 3.6.2 |
Erlang 版本 | 18.3 |
测试数据如下：
QPS 对比 | 仅生产 | 仅消费 | 同时生产/消费 |
CMQ | 生产：6.8w/s | 消费：9w/s | 生产：3.6w/s 消费：3.6w/s |
RabbitMQ | 生产：1.25w/s | 消费：2.6w/s | 生产：0.85w/s 消费：0.85w/s |
在高可靠场景中，CMQ 吞吐量优于 RabbitMQ 的四倍以上。
