一、NameServer简介
NameServer 是一个注册中心，提供服务注册和服务发现的功能。NameServer 可以集群部署，集群中每个节点都是对等的关系，节点之间互不通信。
服务注册
Broker 启动的时候会向所有的 NameServer 节点进行注册，注意这里是向集群中所有的 NameServer 节点注册，而不是只向其中的某些节点注册，因为 NameServer 每个节点都是对等的，所以 Broker 需要向每一个节点进行注册，这样每一个节点都会有一份 Broker 的注册信息。
服务发现
Broker 向 NameServer 注册以后，生产者 Producer 和消费者 Consumer 就可以从 NameServer 中获取所有注册的 Broker 信息，不过由于 NameServer 每个节点是对等的，所以生产者和消费者需要感知所有的 NameServer, 之后选取一个 NameServer 从中获取 Topic 的路由信息，再向对应的 Broker 进行消息的发送和消费。
以生产者为例，在 NameServer 集群部署模式下，生产者会从多个 NameServer 中随机选取一个进行通信，从中拉取所有 Broker 的注册信息，并将拉取到的信息进行缓存，生产者知道了 Broker 的信息后，就可以得知 Topic 的分布情况，然后选取一个消息队列，与其所在的 Broker 通信进行消息的发送。如果通信的 NameServer 宕机，消费者会轮询选择下一个 NameServer。
为什么需要 NameServer ?
在使用 RocketMQ 的时候，为了提升性能以及应对高并发的情况，一般都会使用多个 Broker 进行集群部署，假设没有注册中心，对于 Broker 来说，如果想获取到集群中所有的 Broker 信息（生产者和消费者需要通过某个 Broker 获取整个集群的信息，从而得到Topic 的分布情况），每个 Broker 都需要与其他 Broker 通信来交换信息，以此来得到集群内所有 Broker 的信息，在 Broker 数量比较大的情况下，会造成非常大的通信压力。
Broker 注册
Broker 启动后开启定时向 NameServer 进行注册（发送心跳包）的任务，发送心跳包的时间间隔可以在配置文件中进行设置，但是最长不能超过10s ,也就是说 Broker 最长10秒钟会向 NameServer 发送一次心跳包。
NameServer 收到 Broker 的注册请求（心跳包）后，会判断 Broker 之前是否已经注册过，如果未注册过将其加入到注册的 Broker 集合 brokerAddrTable 中，同时也会记录收到注册请求的时间，将其加入到 brokerLiveTable 中，里面记录了 NameServer 收到每个 Broker 发送心跳包的时间，在进行心跳检测的时候根据这个时间戳来判断是否在规定时间内未收到该 Broker 发送的心跳包。
读写锁
由于 NameServer 可能同时收到多个 Broker 的注册以及生产者或者消费者的拉取请求，为了保证数据的一致性（因为有读写请求同时发生或者写与写请求同时发生），在处理相关请求的时候需要加锁，为了提高性能，使用了 ReadWriteLock 读写锁，处理注册请求时会先添加写锁，外理拉取请求时添加读锁，这样如果某一时刻都是读的请求可以同时进行，互不影响，如果有写请求，其他请求就需要等锁释放才可以进行往下进行。如果不使用读写锁，直接对所有的请求加锁，会影响性能，实际上读与读之间并不需要加锁。
心跳检测
NameServer 在启动的时候会开启一个用于心跳检测的定时任务（每10s执行一次），定时扫描处于不活跃状态的 Broker, 如果在规定时间内未收到某个 Broker 的心跳包，会认为此 Broker 不可用，需要将其进行剔除。
brokerLiveTable 保存了当前 NameServer 收到的心跳数据，里面记录了每一个 Broker 最近进行注册/发送心跳的时间戳，所以只需遍历 brokerLiveTable, 获取每一个 Broker 最近一次发送心跳的时间进行判断，如果上一次发送心跳的时间 + 过期时间（120s）小于当前时间，也就是超过 120s 没有收到某个 Broker 的心跳包，则认为此 Broker 已下线，将 Broker 移除。
Broker 下线
正常下线
当 Broker 下线的时候会向 NameServer 发起取消注册的请求，NameServer 收到请求后会将 Broker 剔除。
异常下线
如果 Broker 异常宕机，或者发送给 NameServer 的取消注册请求由于某些原因并未发送成功，NameServer 可能并未感知到 Broker 的下线，由于心跳机制定时检测的功能，会在一段时间后发现未收到 Broker 的心跳请求，主动将 Broker 剔除。
生产者和消费者
生产者和消费者都会定时从 NameServer 中更新 Broker 的注册信息，默认是30s 进行一次更新。
二、Controller 模式简介
在RocketMQ 5.0 以前，有两种集群部署模式，分别为主从模式（Master-Slave模式）和 Dledger 模式。
主从模式
主从模式中分为 Master 和 Slave 两个角色，集群中可以有多个 Master 节点，一个 Master 节点可以有多个 Slave 节点。Master 节点负责接收生产者发送的写入请求，将消息写入 CommitLog 文件，Slave 节点会与 Master 节点建立连接，从 Master 节点同步消息数据（有同步复制和异步复制两种方式）。
消费者可以从 Master 节点拉取消息，也可以从 Slave 节点拉取消息。
在 RocketMQ 4.5 版本之前，如果 Master 宕机，不支持将 Slave 切换为 Master, 需要人工介入。
Dledger 模式
为了解决主从架构下 Slave 不能自动切换为 Master 的问题，4.5 版本之后提供了 DLedger 模式，使用 Raft 算法，如果 Master 节点出现故障，可以自动从 Slave 节点中选举出新的 Master 进行切换。
存在问题
（1）根据 Raft 算法的多数原则，集群至少有三个节点以上，在消息写入时，也需要大多数的 Follower 节点响应成功才能认为消息写入成功；
（2）Dledger 模式下，进行消息写入的时候，使用的是 openmessaging 包中提供的接口，无法利用 RocketMQ 原生的存储和复制能力（比如非 Dledger 模式下使用暂存池方式写入）；
（3）存在两套日志复制流程（主从模式下一套，Dledger 模式一套），不统一；
Controller 模式
为了解决如上问题，RocketMQ 5.0 以后推出了 Controller 模式，它的特点如下：
（1）在主从部署模式下具备自动切换 Master 的能力;
（2）可以利用 RocketMQ 原生存储复制能力，并统一 RocketMQ 的存储和复制能力；
RocketMQ 5.0 对Broker 选主相关的功能进行了抽离，放在 Controller 中，实现了在主从部署模式下就可以自动切换 Master, Controller 可以独立部署也可以嵌入在 NameServer 中部署。
独立部署下的 Controller如下所示：
嵌入 NameServer 中的部署图如下所示：
Controller
也称为 Controller 控制器，一般集群中部署多个 Controller, 使用 Raft 算法选举出一个 Active DLedger Controller 作为主控制器，它主要用来管理一个 SyncStateSet集合，这个集合中存储的是一组跟上 Master 进度的 Broker 节点集合，如果 Controller 发现某个 Master Broker 下线时，会从集合中选出新的 Master Broker 并切换，Controller 可以单独部署也可以嵌在 NameServer 中部署。
SyncStateSet
SyncStateSet 中维护了一个 Broker 副本组集合，包含当前 Master Broker 和它的 Slave Broker, 需要注意在集合内的节点都是跟上 Master 进度的节点，在节点变更时，由 Master Broker 向 Controller 控制器发起变更请求，更新 Controller 中的 SyncStateSet 数据，在选举 Master 的时候，Controller 只需从这个列表中选出一个节点成为新的 Master 即可。
节点变更分为 Shrink 操作和 Expand 操作，需要 Master Broker 发起，它会通过定时任务以及在数据同步过程中判断是否需要进行 Shrink 或 Expand。
Shrink
Shrink 指的是将 SyncStateSet 副本集合中与 Master 节点差距过大的副本移除，差距的判断条件如下：
1. 节点是否与 Master Broker 的连接已断，如果断开需要将该节点从 SyncStateSet 移除；
2．节点的复制进度是否过大，新增了 haMaxTimeSlaveNotCatchup 参数，Master Broker 会通过定时任务扫描每一个 Slave 节点的复制信息，里面有每个节点上一次跟上 Master 进度的时间戳 lastCaughtUpTimeMs, 如果当前时间减去这个 lastCaughtUpTimeMs 超过了 haMaxTimeSlaveNotCatchup 的值，会认为该 Slave 节点的复制进度过后；
| haMaxTimeSlaveNotCatchup：表示Slave没有跟上 Master 的最大时间间隔，若在 SyncStateSet 中的 slave 超过该时间间隔会将其从 SyncStateSet 移除。默认为 15000（15s）。 |
Expand
如果 Master Broker 发现某个 Slave 节点赶上了 Master 节点的进度，需要将其重新加入到 SyncStateSet 。
需要注意以上两个操作，都需要 Master Broker 向 Controller 节点发送通知，请求更新 SyncStateSet 中的数据。
选举 Master
不管是 Controller 独立部署，还是嵌入到 NameServer 中部署，Controller 都会监听每个 Broker 的连接，Broker 会定期向 Controller 发送心跳包，Controller 会定时扫描，如果某个 Broker 心跳包发送超时，会认为这个 Broker 已经失效，此时会判断 Broker 是否是 Master 角色，如果是 Master 角色就需要从该组的 SyncStateSet 中重新选出一个节点作为 Master。
选举 Master 的方式比较简单，从该组的 SyncStateSet 中，挑选一个心跳包发送正常的 Slave 成为新的 Master 节点即可，并将结果通知到该组所有的 Broker, 每个Broker 也会定时向 Controller 发送请求获取主备信息。
Broker 端设计
主从架构部署模式下，需要配置 brokerRole 和 brokerId,也就是手动分配 Master 和 Slave,在 Controller 模式下，这两个参数会失效，不需要再进行配置，角色和 ID 由 Controller 来分配。
Controller 模式下增加了 controllerAddr 参数，Broker 在启动时，需要配置这个参数，设置每个controller 的地址：
| controllerAddr：controller的地址，多个controller中间用分号隔开。例如controllerAddr = 127.0.0.1:9877;127.0.0.1:9878;127.0.0.1:9879 |
Broker 上线
Broker 配置了每个 Controller 的地址，Broker 启动时，会先向 Controller 注册，并获取角色关系和 brokerId, 通过角色关系可以知道自己是 Master 还是 Slave,之后再向 NameServer 注册。
Broker 可以通过任意一个 Controller 获取 Active Controller 节点的 IP，后台也会有一个定时任务，定时更新 Active Controller 节点的 IP。
主备关系确定
初始化时，第一个 Broker 在向 Controller 注册的时候，此时并没有该 Broker 组的 SyncStateSet, 所以 Active Controller 会将第一个向其发送请求共识的 Broker 设置为 Master , 之后该组的其他节点会设置为 Slave, Master 节点的 brokerId 为 0，Slave 节点从1 开始编写，往后递增。
由于 Controller 控制每个节点的角色，所以每个 Broker 也会定时向 Controller 发送请求获取主备信息，以便在角色发生变化的时候可以及时更新。
日志复制
- MasterEpoch (Epoch): Master 的任期号，与 Term 类似，每一任 Master 都会有一个对应的 MasterEpoch 任期号，这个任期号的值由 controller