共计 2454 个字符，预计需要花费 7 分钟才能阅读完成。
背景
笔者所在的业务线，最后化分为三个服务，因为业务初期业务复杂度绝对简略，三个业务服务都能很好的独立实现业务性能。
随着产品迭代，业务性能越来越多后缓缓也要面对高并发、业务解耦、分布式事务等问题，所以通过团队外部探讨，引入 RocketMQ 消息中间件来更好的解决业务。
因为公司外部业务线部署互相独立，咱们业务线对引入 RocketMQ 的需要也比拟急迫，所以打算本人搭建一套高可用的 RocketMQ 集群，同时对于自建的 RocketMQ 集群须要如下个性：
- 高可用
- 高并发
- 可伸缩
- 海量音讯
命名服务（NameServer）
首先第一步要让 NameServer 高可用，后期布局了三台机器部署 NamseServer 这样能够充分保证可用性，即便两台机器挂掉也能保障集群的失常应用，只有有一个 NamseServer 还在运行，就能保障 RocketMQ 零碎的稳定性。
NameServer 的设计是互相的独立的，任何一台 NameServer 都能够的独立运行，跟其余机器没有任何通信 。
每台 NameServer 都会有残缺的集群路由信息，包含所有的 Broker 节点的信息，咱们的数据信息等等。所以只有任何一台 NamseServer 存活下来，就能够保留 RocketMQ 信息的失常运行，不会呈现故障。
Broker 集群部署架构
开始部署 RocketMQ 之前，咱们也做过一些功课，对当初 RocketMQ 反对的集群计划做了一些整顿，目前 RocketMQ 反对的集群部署计划有以下 4 种：
- 多 Master 模式：一个集群无 Slave，全是 Master，例如 2 个 Master 或者 3 个 Master
- 多 Master 多 Slave 模式 - 异步复制：每个 Master 配置一个 Slave，有多对 Master-Slave，HA 采纳异步复制形式，主备有短暂音讯提早（毫秒级）
- 多 Master 多 Slave 模式 - 同步双写：每个 Master 配置一个 Slave，有多对 Master-Slave，HA 采纳同步双写形式，即只有主备都写胜利，才向利用返回胜利
- Dledger 部署：每个 Master 配置二个 Slave 组成 Dledger Group，能够有多个 Dledger Group，由 Dledger 实现 Master 选举
多 Master 模式
一个 RocketMQ 集群中所有的节点都是 Master 节点，每个 Master 节点没有 Slave 节点。
这种模式的优缺点如下：
- 长处：配置简略，单个 Master 宕机或重启保护对利用无影响，在磁盘配置为 RAID10 时，即便机器宕机不可复原状况下，因为 RAID10 磁盘十分牢靠，音讯也不会丢（异步刷盘失落大量音讯，同步刷盘一条不丢），性能最高；
- 毛病：单台机器宕机期间，这台机器上未被生产的音讯在机器复原之前不可订阅，音讯实时性会受到影响。
多 Master 多 Salve – 异步复制 模式
每个 Master 配置一个 Slave，有多对 Master-Slave，HA 采纳异步复制形式，主备有短暂音讯提早（毫秒级）
这种模式的优缺点如下：
- 长处：即便磁盘损坏，音讯失落的非常少，且音讯实时性不会受影响，同时 Master 宕机后，消费者依然能够从 Slave 生产，而且此过程对利用通明，不须要人工干预，性能同多 Master 模式简直一样；
- 毛病：Master 宕机，磁盘损坏状况下会失落大量音讯。
多 Master 多 Salve – 同步双写 模式
每个 Master 配置一个 Slave，有多对 Master-Slave，HA 采纳同步双写形式，即只有主备都写胜利，才向利用返回胜利
这种模式的优缺点如下：
- 长处：数据与服务都无单点故障，Master 宕机状况下，音讯无提早，服务可用性与数据可用性都十分高；
- 毛病：性能比异步复制模式略低（大概低 10% 左右），发送单个音讯的 RT 会略高，且目前版本在主节点宕机后，备机不能主动切换为主机。
Dledger 模式
RocketMQ 4.5 以前的版本大多都是采纳 Master-Slave 架构来部署，能在肯定水平上保证数据的不失落，也能保障肯定的可用性。
然而那种形式 的缺点很显著，最大的问题就是当 Master Broker 挂了之后，没方法让 Slave Broker 主动 切换为新的 Master Broker，须要手动更改配置将 Slave Broker 设置为 Master Broker，以及重启机器，这个十分麻烦。
在手式运维的期间，可能会导致系统的不可用。
应用 Dledger 技术要求至多由三个 Broker 组成，一个 Master 和两个 Slave，这样三个 Broker 就能够组成一个 Group，也就是三个 Broker 能够分组来运行。一但 Master 宕机，Dledger 就能够从剩下的两个 Broker 中选举一个 Master 持续对外提供服务。
整体架构：高可用、高并发、可伸缩、海量音讯
通过下面 4 种集群计划的比拟，最终确定应用 Dledger 形式最终的逻辑部署图如下：
上图的虚线框示意一个 Dledger Group。
高可用
三个 NameServer 极其状况下，确保集群的可用性，任何两个 NameServer 挂掉也不会影响信息的整体应用。
在上图中每个 Master Broker 都有两个 Slave Broker，这样能够保障可用性，如在同一个 Dledger Group 中 Master Broker 宕机后，Dledger 会去行投票将剩下的节点晋升为 Master Broker。
高并发
假如某个 Topic 的每秒十万音讯的写入，能够减少 Master Broker 而后十万音讯的写入会别离调配到不同的 Master Broker，如有 5 台 Master Broker 那每个 Broker 就会承载 2 万的音讯写入。
可伸缩
如果音讯数量增大，须要存储更多的数量和最高的并发，齐全能够减少 Broker，这样能够线性扩大集群。
海量音讯
数据都是分布式存储的，每个 Topic 的数据都会散布在不同的 Broker 中，如果须要存储更多的数据，只须要减少 Master Broker 就能够了。
欢送关注公众号：架构文摘，取得独家整顿 120G 的收费学习资源助力你的架构师学习之路！
公众号后盾回复
arch028获取材料：
