Broker源码层面验证一下这两个点

的结论，分别是：

• Broker在启动时，会将自己注册到所有的NameServer上
• Broker在启动之后，会每隔30S向NameServer发送心跳

之前的文章中，我们知道了RocketMQ中的一些核心概念，例如Broker、NameServer、Topic和Tag等等。Producer从启动到发送消息的整个过程，从源码级别分析了Producer在发送消息到Broker的时候，是如何拿到Broker的数据的，如何从多个MessageQueue中选择对应的Queue发送消息。

但是由于篇幅原因，文章开头提到的两个已知结论在上篇博客里并没没有对其进行验证，这次就从源码层面来验证一下。

一开头就看到Broker主从架构相关的源码

在上篇博客中提到过，Broker为了保证自身的高可用，会采取一主一从的架构。即使Master Broker因为意外原因挂了，Slave Broker上还有一份完整的数据，Broker可以继续提供服务。

ableDLegerCommitLog中提到的DLeger可以先不管，我们目前只需要知道其默认返回的结果是false。所以Broker首次启动的时候，就会执行被If包裹住的逻辑。

RocketMQ本身是有主从架构的，但是功能不够完善，如果Master Broker出现了故障，需要人工的将Slave Broker切换成Master。

就有点类似于手动的将一台Redis设置成另一台Redis的Slave节点，如果此时Redis的Master挂了，还需要手动的进行切换一样。为了解决这个问题，Redis搞出了Sentinel，可以在发生故障的时候自动的实现故障转移。所以RocketMQ在4.5版本之后推出的Dleger差不多也是这么个东西，除此之外，Dleger还可以实现多副本。

不使用Dleger时，主从数据如何进行同步

先给出结论，在RocketMQ的主从架构下，主从同步采取的是Slave主动拉取的方式。

如果当前执行注册的Broker角色是Slave，那就会使用ScheduledExecutorService启动一个周期性的定时任务，每隔10秒就会去Master同步一次，同步的数据包括Topic的相关配置、Consumer的消费偏移量、延迟消息的Offset、订阅组的相关数据和配置。

（编辑：四平站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!