broker与NameServer

基于 Dledger 实现 RocketMQ 高可用自动切换

broker 会每隔 30 秒向 NameServer 发送一个的心跳 ，NameServer 收到一个心跳
会更新对应 broker 的最近一次心跳事件，然后 NamServer 会每隔十秒运行一个任
务，去检查一下各个 broker 的最近一次心跳的时间，如果超过 120s 没有收到相应
broker 的心跳，则判定对应的 broker 已经挂掉

「RocketMQ 自身的 Master-Slave 模式主采取的是 Slave 主动从 Master 拉取消息。」

MessageQueue与Topic的关系

MessageQueue是 Topic的数据分配机制，创建Topic的时候 需要指定关键的MessageQueue

生产者、消费者 从NameServer获取的信息：

「一个 Topic 有几个 MessageQueue，哪些 MessageQueue 在哪台Broker 机器上，通过对应的规则写入对应的 MessageQueue」
在每个 Broker 机器上都存储一些 MessageQueue。通过这个方法可以实现分布式存储。

生产者、消费者写入读取 消息

发送消息时均匀写入到MessageQueue
生产者在写入消息时，一般写入到 Master
消费者在拉取消息时，可能从 Master 拉取，也可能从 Slave 拉取

「根据Master 的负载情况和 Slave 的同步情况，」 由 Master 给出建议

• Master 负载过高，建议 下次从 Slave 获取消息
• Slave 未同步完全，建议下次从 Master 获取消息

CommitLog

生产者发送一条消息到broker，broker 顺序写入PageCache，然后 由OS的一个线程异步刷盘到磁盘上的CommitLog文件
然后在ConsumerQueue中写入一条消息，写入的消息内容是 消息在CommitLog中的物理offset偏移量 (这条消息的地址)

写入速度接近内存的原因：「磁盘文件顺序写+OS PageCache 写入+OS 异步刷盘的策略」

• CommitLog 限定1G，预先申请好

生产者

Producer 的「自动容错机制开关：sendLatencyFaultEnable」

打开了这个开关，那么他会有一个自动容错机制，比如如果某次访问一个Broker发现网络延迟有500ms，然后还无法访问，那么
就会自动回避访问这个Broker一段时间，比如接下来3000ms内，就不会访问这个Broker了

消费者组

不同的系统 应该设置不同的消费组，如果不同的消费组订阅了同一个Topic，对Topic里的一条消息，每个消费组都会获取到这条消息

一个 Consumer 机 器 可 以 消 费 处 理 多 个 MessageQueue
一个MessageQueue 只能被一个相同 ConsumerGroup 中的同一个 Consumer 消费。(也就是 这条消息 只能被一个机器消费)