从 RocketMQ 反对主动故障转移说起
在 RocketMQ 4.5 版本之前，RocketMQ 只有 Master/Slave 一种部署形式，一组 Broker 中有一个 Master，有零到多个 Slave，Slave 通过同步复制或异步复制形式去同步 Master 的数据。Master/Slave 部署模式，提供了肯定的高可用性。
但这样的部署模式有肯定缺点。比方故障转移方面，如果主节点挂了还须要人为手动的进行重启或者切换，无奈主动将一个从节点转换为主节点。因而，咱们心愿能有一个新的多正本架构，去解决这个问题。
Apache RocketMQ – Version 4.5.0 公布详情
RocketMQ 实现高可用多正本架构的要害：基于 Raft 协定的 commitlog 存储库 DLedger
master 宕机后集群失去写音讯的能力
因为 master 反对读写，slave 只反对读，甚至只有 brokerId = 1 的从服务器反对音讯的读负载（rocketmq 依据 brokerId 来确定主从，brokerId 为 0 示意 master，非 0 示意 slave）
作为比照 kafka 的追随者正本不对外提供读写服务，仅仅是作为备胎用来备份数据（长处是不存在从节点音讯提早的状况，毛病是失落读操作的横向扩大）
咱们商城应用的是 RocketMQ 3.2.6 版本，两个节点（broker a 和 broker c）每个 broker 一主一从
除了一主一从，broker 还反对其余多种部署形式：
- 多 master
- 单 master 多 slave 同步复制
- 单 master 多 slave 异步复制
RocketMQ 最佳实际
rocketmq architecture
RocketMQ 的相干概念
说 raft 之前先说 paxos
paxos 本来是一个希腊岛屿的名字（古希腊城邦有民主选举的历史），一个叫 Lamport 的老头因为提出了 paxos 等相干的算法，取得了 2013 年的图灵奖
<br/>
Kafka 也筹备用 Raft 算法
看个动画片了解 Raft 算法
蕴含几个要害模块：领导者选举，日志复制，
演示动画
Raft 算法中文翻译