前言

这篇来记录一下RocketMQ是如何实现高可用的。主要是来分析一下NameSrv、Broker的HAService。

前言

最近的时间差不多都围绕着RocketMQ的学习上，一开始从了解RocketMQ的场景到RocketMQ的一个使用，然后到源码的阅读。前面两个过程无需多说，到了读源码的阶段，我时常问自己，读这份源码的意义在于哪？

前言

broker是消息接收处理，消息落地的核心模块。这个模块用于接收producer发送的消息以及consumer消费的消息。 本章从broker的启动类入手分析一下broker启动的过程。

分析broker是为了能够搞明白master和slave之间的关系，以及消息落地的具体过程。

前言

已经写了几篇关于RocketMQ源码的分析，可能对其逻辑处理会多一点认识，但还没深入到RocketMQ精髓中。比如MQ中的通信是如何实现的、如何实现高性能，高可用、最终一致性、MQ 消息存储。这些才是我们阅读源码的一个目标。所以这篇通过分析源码的来了解一下RocketMQ通信机制。

本文很大部分摘录了 匠心独运的博客。

前言

RocketMQ在早期版本使用的是Zookeeper，考虑到Zookeeper不够轻量，后面用namesrv来代替。熟悉Zookeeper的知道它使用心跳检测来判断服务是否正常，那么namesrv肯定也少不了这块功能，那么它是怎么判断一个Broker节点是否Live呢？如果一个Broker断开了namesrv是如何处理的呢？

在前面篇章提到NamesrvController的构造函数中有一个BrokerHousekeepingService，这个就是来处理Broker连接发生变化的服务。

前言

在上一章分析了NamesrvController的构造函数时，会生成一个RouteInfoManager对象，该对象存放着整个消息集群的相关消息，所以这里单独拿出来分析。其实试想一下namesrv的功能不就是一个提供了通信功能的一个队列嘛，而RouteInfoManager保留了所有信息的路由。所以要想弄明白RocketMQ，RouteInfoManager必须要攻下。

前言

上一篇在讲到createNamesrvController方法的时候，根据NamesrvConfig和NettyServerConfig对象生成了一个NamesrvController对象，当时并没有deep到该类中，所以这篇来记录一下NamesrvController构造函数的分析。

前言

上一篇讲到使用命令行启动namesrv时，最终会以NamesrvStartup作为为启动类，所以这篇主要来记录一下NamesrvStartup的源码分析。分析的RocketMQ的版本是4.3.1。

前言

在RocketMQ中，NameServer的目的是为了解耦Broker和Producer、Consumer。官方文档对NameServer有一个概括：NameServer是一个几乎无状态节点,可集群部署,节点之间无任何信息同步。而且在启动MQ的时候，第一个启动必须是NameServer。所以这篇主要来记录一下NameServer启动的源码分析。

前言

主要来记录一下对RocketMQ的一些认识，包括了比较零散的知识点，主要方便以后回顾。