从RabbitMQ平滑迁移到RocketMQ技术实战( 二 ) _RabbitMQ

三、开源组件选型调研基于当前RabbitMQ平台的问题和对下一代消息中间件平台的项目需求，我们开展了针对当前较流行的两款消息中间件：RocketMQ、Pulsar的调研。
调研过程中主要针对以下两方面进行对比：
3.1 高可用能力分析对比3.1.1 高可用架构与负载均衡能力对比

文章插图

Pulsar部署架构（来源：Pulsar社区）

文章插图

RocketMQ部署架构（来源：RocketMQ社区）
Pulsar：

采用计算与存储分离架构设计，可以实现海量数据存储，并且支持冷热数据分离存储。
基于ZK和Manager节点控制Broker的故障切换以实现高可用。
BooKeeper采用分层分片存储设计，天然支持负载均衡。

RocketMQ：

采用存算一体架构设计，主从模式部署， master节点异常不影响消息读取， Topic采用分片设计。
需要二次开发支持主从切换实现高可用。
未实现Broker的自动负载均衡，可以将top n流量Topic分布到不同的Broker中实现简单的负载均衡。

3.1.2 扩缩容与故障恢复对比Pulsar

Broker与BooKeeper独立扩缩容，并且扩缩容后会完成自动负载均衡。
Broker节点无状态，故障后承载Topic会自动转移到其它Broker节点，完成故障秒级恢复。
BooKeeper由自动恢复服务进行ledger数据对齐，并恢复到设置的QW份。
故障期间已ack消息不会丢失，未ack消息需要客户端重发。

RocketMQ

Broker扩缩容后需要人工介入完成Topic流量均衡，可开发自动负载均衡组件结合Topic的读写权限控制自动化完成扩缩容后的负载均衡。
基于主从切换实现高可用，由于客户端定期30秒从NameSrv更新路由，因此故障恢复时间在30~60秒，可以结合客户端降级策略让客户端主动剔除异常Broker节点，实现更快故障恢复。
采用同步复制异步刷盘部署架构，在极端情况下会造成少量消息丢失，采用同步复制同步刷盘，已写入消息不会丢失。

3.1.3 性能对比Pulsar

可支撑百万Topic数量，实际受到ZK存储元数据限制。
根据内部压测1KB消息可支撑TPS达数十万。

RocketMQ

逻辑上可支撑百万Topic ，实际在达到数万时Broker与NameSrv传输心跳包可能超时，建议单集群不超过5万。
根据压测可支撑1KB消息体TPS达10万+ 。

3.2 功能特性对比

文章插图

3.3 总结从高可用架构分析， Pulsar基于Bookeeper组件实现了架构的计算与存储分离，可以实现故障的快速恢复；RocketMQ采用了主从复制的架构，故障恢复依赖主从切换。
从功能特性分析， Pulsar支持了丰富的过期策略，支持了消息去重，可以支持实时计算中消息只消费一次的语义；RocketMQ在事务消息、消息轨迹、消费模式等特性对在线业务有更好的支持。
从这两方面对比，最终选择了RocketMQ构建我们下一代的消息中间件平台。
四、平滑迁移建设通过技术调研，确定了基于RocketMQ建设下一代消息中间件平台。
为了实现业务从RabbitMQ平滑迁移到RocketMQ ，就需要建设消息网关实现消息从AMQP协议转换到RocketMQ；RabbitMQ与RocketMQ的元数据语义与存储存在差异，需要实现元数据语义的映射与元数据的独立存储。
主要有以下四个事项需要完成：4.1 消息网关独立部署与嵌入式部署差异对比