4种高可用RocketMQ集群搭建方案

背景

笔者所在的业务线&＃xff0c;最初化分为三个服务&＃xff0c;由于业务初期业务复杂度相对简单&＃xff0c;三个业务服务都能很好的独立完成业务功能。

随着产品迭代&＃xff0c;业务功能越来越多后慢慢也要面对高并发、业务解耦、分布式事务等问题&＃xff0c;所以经过团队内部讨论&＃xff0c;引入 RocketMQ 消息中间件来更好的处理业务。

由于公司内部业务线部署相互独立&＃xff0c;我们业务线对引入 RocketMQ 的需求也比较急切&＃xff0c;所以打算自己搭建一套高可用的 RocketMQ 集群&＃xff0c;同时对于自建的 RocketMQ 集群需要如下特性&＃xff1a;

• 高可用
• 高并发
• 可伸缩
• 海量消息

命名服务&＃xff08;NameServer&＃xff09;

首先第一步要让 NameServer 高可用&＃xff0c;前期规划了三台机器部署 NamseServer 这样可以充分保证可用性&＃xff0c;即使两台机器挂掉也能保证集群的正常使用&＃xff0c;只要有一个 NamseServer 还在运行&＃xff0c;就能保证 RocketMQ 系统的稳定性。

NameServer 的设计是相互的独立的&＃xff0c;任何一台 NameServer 都可以的独立运行&＃xff0c;跟其他机器没有任何通信。
每台 NameServer 都会有完整的集群路由信息&＃xff0c;包括所有的 Broker 节点的信息&＃xff0c;我们的数据信息等等。所以只要任何一台 NamseServer 存活下来&＃xff0c;就可以保存 RocketMQ 信息的正常运行&＃xff0c;不会出现故障。

Broker 集群部署架构

开始部署 RocketMQ 之前&＃xff0c;我们也做过一些功课&＃xff0c;对现在 RocketMQ 支持的集群方案做了一些整理&＃xff0c;目前 RocketMQ 支持的集群部署方案有以下4种&＃xff1a;

• 多Master模式&＃xff1a;一个集群无Slave&＃xff0c;全是Master&＃xff0c;例如2个Master或者3个Master
• 多Master多Slave模式-异步复制&＃xff1a;每个Master配置一个Slave&＃xff0c;有多对Master-Slave&＃xff0c;HA采用异步复制方式&＃xff0c;主备有短暂消息延迟&＃xff08;毫秒级&＃xff09;
• 多Master多Slave模式-同步双写&＃xff1a;每个Master配置一个Slave&＃xff0c;有多对Master-Slave&＃xff0c;HA采用同步双写方式&＃xff0c;即只有主备都写成功&＃xff0c;才向应用返回成功
• Dledger部署&＃xff1a;每个Master配置二个 Slave 组成 Dledger Group&＃xff0c;可以有多个 Dledger Group&＃xff0c;由 Dledger 实现 Master 选举

多 Master 模式

一个 RocketMQ 集群中所有的节点都是 Master 节点&＃xff0c;每个 Master 节点没有 Slave 节点。

这种模式的优缺点如下&＃xff1a;

• 优点&＃xff1a;配置简单&＃xff0c;单个Master宕机或重启维护对应用无影响&＃xff0c;在磁盘配置为RAID10时&＃xff0c;即使机器宕机不可恢复情况下&＃xff0c;由于RAID10磁盘非常可靠&＃xff0c;消息也不会丢&＃xff08;异步刷盘丢失少量消息&＃xff0c;同步刷盘一条不丢&＃xff09;&＃xff0c;性能最高&＃xff1b;
• 缺点&＃xff1a;单台机器宕机期间&＃xff0c;这台机器上未被消费的消息在机器恢复之前不可订阅&＃xff0c;消息实时性会受到影响。

多 Master 多 Salve - 异步复制 模式

每个Master配置一个Slave&＃xff0c;有多对Master-Slave&＃xff0c;HA采用异步复制方式&＃xff0c;主备有短暂消息延迟&＃xff08;毫秒级&＃xff09;

这种模式的优缺点如下&＃xff1a;

• 优点&＃xff1a;即使磁盘损坏&＃xff0c;消息丢失的非常少&＃xff0c;且消息实时性不会受影响&＃xff0c;同时Master宕机后&＃xff0c;消费者仍然可以从Slave消费&＃xff0c;而且此过程对应用透明&＃xff0c;不需要人工干预&＃xff0c;性能同多Master模式几乎一样&＃xff1b;
• 缺点&＃xff1a;Master宕机&＃xff0c;磁盘损坏情况下会丢失少量消息。

多 Master 多 Salve - 同步双写 模式

每个Master配置一个Slave&＃xff0c;有多对Master-Slave&＃xff0c;HA采用同步双写方式&＃xff0c;即只有主备都写成功&＃xff0c;才向应用返回成功

这种模式的优缺点如下&＃xff1a;

• 优点&＃xff1a;数据与服务都无单点故障&＃xff0c;Master宕机情况下&＃xff0c;消息无延迟&＃xff0c;服务可用性与数据可用性都非常高&＃xff1b;
• 缺点&＃xff1a;性能比异步复制模式略低&＃xff08;大约低10%左右&＃xff09;&＃xff0c;发送单个消息的RT会略高&＃xff0c;且目前版本在主节点宕机后&＃xff0c;备机不能自动切换为主机。

Dledger 模式

RocketMQ 4.5 以前的版本大多都是采用 Master-Slave 架构来部署&＃xff0c;能在一定程度上保证数据的不丢失&＃xff0c;也能保证一定的可用性。

但是那种方式 的缺陷很明显&＃xff0c;最大的问题就是当 Master Broker 挂了之后 &＃xff0c;没办法让 Slave Broker 自动 切换为新的 Master Broker&＃xff0c;需要手动更改配置将 Slave Broker 设置为 Master Broker&＃xff0c;以及重启机器&＃xff0c;这个非常麻烦。

在手式运维的期间&＃xff0c;可能会导致系统的不可用。

使用 Dledger 技术要求至少由三个 Broker 组成 &＃xff0c;一个 Master 和两个 Slave&＃xff0c;这样三个 Broker 就可以组成一个 Group &＃xff0c;也就是三个 Broker 可以分组来运行。一但 Master 宕机&＃xff0c;Dledger 就可以从剩下的两个 Broker 中选举一个 Master 继续对外提供服务。

整体架构&＃xff1a;高可用、高并发、可伸缩 、海量消息

经过上面4种集群方案的比较&＃xff0c;最终确定使用 Dledger 方式最终的逻辑部署图如下&＃xff1a;

上图的虚线框表示一个 Dledger Group。

高可用

三个 NameServer 极端情况下&＃xff0c;确保集群的可用性&＃xff0c;任何两个 NameServer 挂掉也不会影响信息的整体使用。

在上图中每个 Master Broker 都有两个 Slave Broker&＃xff0c;这样可以保证可用性&＃xff0c;如在同一个 Dledger Group 中 Master Broker 宕机后&＃xff0c;Dledger 会去行投票将剩下的节点晋升为 Master Broker。

高并发

假设某个Topic的每秒十万消息的写入&＃xff0c; 可以增加 Master Broker 然后十万消息的写入会分别分配到不同的 Master Broker &＃xff0c;如有5台 Master Broker 那每个 Broker 就会承载2万的消息写入。

可伸缩

如果消息数量增大&＃xff0c;需要存储更多的数量和最高的并发&＃xff0c;完全可以增加 Broker &＃xff0c;这样可以线性扩展集群。

海量消息

数据都是分布式存储的&＃xff0c;每个Topic的数据都会分布在不同的 Broker 中&＃xff0c;如果需要存储更多的数据&＃xff0c;只需要增加 Master Broker 就可以了。