RocketMQ集群模式！
RocketMQ集群模式！
月伴飞鱼在RocketMQ5.0以前，有两种集群部署模式，分别为主从模式（Master-Slave模式）和Dledger模式。
主从模式
主从模式中，
Broker分为Master与Slave，一个Master可对应多个Slave，一个Slave只能对应一个Master。每个
Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。
Master节点负责接收客户端的写入请求，并将消息持久化到磁盘上。
Slave节点则负责从Master节点复制消息数据，并保持与Master节点的同步。消费者可以从
Master节点拉取消息，也可以从Slave节点拉取消息。在
RocketMQ4.5版本之前，如果Master宕机，不支持自动将Slave切换为Master，需要人工介入。
Dledger模式
为了解决主从架构下
Slave不能自动切换为Master的问题，4.5版本之后提供了DLedger模式。使用
Raft算法，如果Master节点出现故障，可以自动从Slave节点中选举出新的Master进行切换。存在问题
根据
Raft算法的多数原则，集群至少有三个节点以上，在消息写入时。
- 需要大多数的
Follower节点响应成功才能认为消息写入成功。
Dledger模式下，进行消息写入的时候，使用的是OpenMessaging包中提供的接口。
- 无法利用
RocketMQ原生的存储和复制能力。存在两套日志复制流程（主从模式下一套、
Dledger模式下一套），不统一。
Controller模式
为了解决如上问题，RocketMQ5.0以后推出了Controller模式，它的特点如下：
在主从部署模式下就具有自动切换
Master的能力，5.0之前需要使用DLedger才可以。可以利用
RocketMQ原生存储复制能力，并统一RocketMQ的存储和复制能力。
RocketMQ5.0对Broker选主相关的功能进行了抽离，放在Controller中。
实现了在主从部署模式下就可以自动切换Master，Controller可以独立部署也可以嵌入在NameServer中部署。
独立部署下的Controller：
嵌入NameServer中的部署图如下：
Controller
一般集群中部署多个
Controller，使用Raft算法选举出一个Active DLedger Controller作为主控制器。它主要用来管理一个
SyncStateSet集合。
- 这个集合中存储的是一组跟上
Master进度的Broker节点集合。如果
Controller发现某个Master Broker下线时，会从集合中选出新的Master Broker并切换。
Controller可以单独部署可以嵌在NameServer中部署。
由于Controller控制每个节点的角色，所以每个Broker也会定时向Controller发送请求获取主备信息。
- 以便在角色发生变化的时候可以及时更新。
同步复制
生产者发送消息后，
Master接收到存储消息请求，将消息数据同步给Slave后，才将存储结果返回给生产者。同步复制模式下，发送消息会有一定延迟，系统吞吐量也会降低。
异步复制
生产者发送消息后，
Master接收到存储消息请求，将消息存储后，直接将存储结果返回给生产者。
Master和Slave再通过异步的方式同步数据，这种复制模式具有较小的延迟，可以实现比较高的吞吐量。若
Master出现故障，有些数据可能未写入Slave，未同步的数据可能丢失。
Proxy代理层
RocketMQ5.0以前使用自定义的Remoting协议底层基于Netty进行网络通信，计算存储是一体的，都在Broker中。
生产者和消费者从NameServer中拉取到路由信息，之后直接与Broker交互进行消息的生产与消费。
5.0以后引入了弹性无状态的代理模式，对
Broker的职责进行了拆分。将客户端协议适配、权限管理、消费管理等计算逻辑进行了抽离，放入
Proxy层，Broker专注数据的存储。
- 以便更好的适应云原生环境，实现资源弹性调度。
并且5.0以后增加了
GRPC协议的支持，它是Protobuf序列化。
从架构上来看，增加
Proxy代理层后，生产者和消费者不再直接与Broker通信，而是与Proxy层通信。
Proxy层再与NameServer和Broker交互进行消息的发送和消费。如果需要提高计算层的能力，只需要增加
Proxy层，如果需要提高存储层的能力，增加Broker的部署即可。
