RocketMQ之Broker

1、主从同步机制
master broker 与slave broker的消息同步方式为：
RocketMQ自身的Master-Slave模式采取的是Pull模式拉取消息，所以是Slave Broker不停的发送请求到Master Broker去拉取消息。

2、未实现读写分离
master broker接收系统的消息写入，然后slave broker去master broker拉取数据。
消费者消费消息：有可能从Master Broker获取消息，也有可能从Slave Broker获取消息。

3、消息消费机制
作为消费者的系统在获取消息的时候会先发送请求到Master Broker上去，请求获取一批消息，此时Master Broker是会返回一批消息给消费者系统，然后Master Broker在返回消息给消费者系统的时候，会根据当时Master Broker的负载情况和Slave Broker的同步情况，向消费者系统建议下一次拉取消息的时候是从Master Broker拉取还是从Slave Broker拉取。
所以在写入消息的时候，通常来说肯定是选择Master Broker去写入的，但是在拉取消息的时候，有可能从Master Broker获取，也可能从Slave Broker去获取，一切都根据当时的情况来定。

4、RocketMQ版本说明
在RocketMQ 4.5版本之前，都是用Slave Broker同步数据，尽量保证数据不丢失，但是一旦Master故障了，Slave是没法自动切换成Master的，所以在使用时，尽量选择4.5及之后的版本，因为基于Dledger实现了RocketMQ高可用自动切换，此时建议为1个master对应2个slave，此时master如果宕机了，则会在多个Slave中，通过Dledger技术和Raft协议算法进行leader选举，直接将一个Slave Broker选举为新的Master Broker，然后这个新的Master Broker就可以对外提供服务了。

5、Broker与NameServer通信
Broker会每隔30秒发送心跳到所有的NameServer上去，然后每个NameServer都会每隔10s检查一次有没有哪个Broker超过120s没发送心跳的，如果有，就认为那个Broker已经宕机了，从路由信息里要摘除这个Broker。
Broker会跟每个NameServer都建立一个TCP长连接，然后定时通过TCP长连接发送心跳请求过去。
所以各个NameServer就是通过跟Broker建立好的长连接不断收到心跳包，然后定时检查Broker有没有120s都没发送心跳包，来判定集群里各个Broker到底挂掉了没有。