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 具有更少的请求数和更低的平均延迟。 |
| CMQ 生产/消费消息顺序写单个文件,并周期性落盘存储,能最大限度地充分利用文件系统缓存。RabbitMQ 持久化消息机制为先入内存队列进行状态转换,然后写日志缓存,最后写消息文件和索引文件(索引文件为顺序写、消息文件为随机写),涉及三次 IO 操作,性能较差。 |
| RabbitMQ 的日志缓存和状态转换运算较为复杂,需大量耗用 CPU 资源,性能较差。 |
可用性提升
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。
|
| 24核 Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz |
| |
| 12*2T SATA 12块 SATA 组成 Raid0 |
| |
| |
| |
| |
测试数据如下:
在高可靠场景中,CMQ 吞吐量优于 RabbitMQ 的四倍以上。
本页内容是否解决了您的问题?