一、概述
前面的两篇文章和大家一起学习了RocketMQ基础概念以及常用的RocketMQ消息类型，如果对其基本概念和简单的使用还不熟悉的小伙伴可以先去学习一下，从本小节开始将对RocketMQ源码做一个简单的了解。我们将从它的各个组件入手，由点到线再到面。
二、NameServer 架构设计
消息中间件的设计思路一般是基于主题订阅发布的机制，消息生产者(Producer)发送某一个主题到消息服务器，消息服务器负责将消息持久化存储，消息消费者(Consumer)订阅感兴趣的主题，消息服务器根据订阅信息(路由信息)将消息推送到消费者(Push模式)或者消费者主动向消息服务器拉取(Pull模式)，从而实现消息生产者与消息消费者解耦。为了避免消息服务器的单点故障导致的整个系统瘫痪，通常会部署多台消息服务器共同承担消息的存储。那消息生产者如何知道消息要发送到哪台消息服务器呢?如果某一台消息服务器宕机了，那么消息生产者如何在不重启服务情况下感知呢? Name服务器就是为了解决以上问题设计的。
上图为我们简单描述了NameServer进行路由发现，路由踢出，路由注册的核心原理。
为了保证我们NameServer的高可用，我们在部署的时候通常会部署多台NameServer，多个NameServer之间不进行通信，每台NameServer都独立保存了Broker注册过来的信息。这种多实例集群部署方案，使其能够避免单点故障，提供高可用性、容错性和负载均衡。
接下来我们将从源码角度更深一步去认识，了解RocketMQ。
三、NameServer启动流程
首先我们先通过一个时序图来对我们启动的整体流程有一个初步的了解。
为了大家更好的理解我们RocketMQ的一个工作流程，我们先去刨析各个组件的，弄清楚各个组件的功能，在去看他的一个流程，会有事半功倍的效果，由点到线再到面，将他们进行串接。
四、KVConfigManager KV配置管理组件
KVConfigManager是一个用于管理和读取 KV 配置的组件，它的主要功能是集中管理一些以键值对（Key-Value）形式存储的配置信息。这些配置信息通常用于 RocketMQ 的配置管理和动态调整。该组件主要加载的是我们Namespace的一些配置信息。
小扩展：使用 namespace 的主要目的是为了隔离不同的系统或者环境。例如，你可以为测试环境创建一个 namespace，为生产环境创建另一个 namespace，这样可以确保测试环境和生产环境之间的资源不会互相干扰。每个 namespace 下可以包含以下内容：生产者，消费者，主题（Topic），标签（Tag）消息队列（Queue）。
在RocketMQ启动的时候他会去加载我们的KV配置。
首先我们先来看一下他的核心属性：
// jdk提供的读写锁
private final ReadWriteLock lock = new ReentrantReadWriteLock();
// 基于内存中的hashmap数据结构来进行kv配置的存放
// 每个namespace命名空间都会有多个kv配置，是这样的一个数据结构
private final HashMap<String/* Namespace */, HashMap<String/* Key */, String/* Value */>> configTable =
new HashMap<String, HashMap<String, String>>();通过他的源代码我们可以看到它的核心属性：包括一把读写锁，一个Map类型的数据结构。在后面我们会陆续看到在RocketMQ内部的一些映射关系实际就在操作Map这样的数据结构。
现在我们通过源码看一下他在添加KV的配置的时候是怎么样的，其他的操作删除，修改，查询等操作，其实就是在操作我们的configTable Map类型的一个数据结构，就不一一展示了，原理都是一样的。
public void putKVConfig(final String namespace, final String key, final String value) {
try {
// 加读写锁
this.lock.writeLock().lockInterruptibly();
try {
HashMap<String, String> kvTable = this.configTable.get(namespace);
if (null == kvTable) {
kvTable = new HashMap<String, String>();
this.configTable.put(namespace, kvTable);
log.info("putKVConfig create new Namespace {}", namespace);
}
final String prev = kvTable.put(key, value);
// 此处删除了一些判断逻辑
}
} finally {
this.lock.writeLock().unlock();
}
} catch (InterruptedException e) {
log.error("putKVConfig InterruptedException", e);
}
// 进行持久化操作
this.persist();
}从上面的代码我们不难看出他在put元素的时候，使用了读写锁，此时如果其他线程过来想要操作我们的configTable是要阻塞的。
现在请大家想两个问题：
- 为什么要在这里使用读写锁，是否可以用其他锁替换呢，比如synchronized？
- 如果自己去设计一个高并发的读写该如何去设计呢？
我们先来揭秘第一个答案，是不行的，首先如果使用synchronized，此时大量请求过来的都是读请求呢，结果可想而知，大量的请求阻塞，每个请求它只是想查看一下自己namespace底下的一下信息，也要进行阻塞，对于我们程序的性能来说大大折损，此时就该我们的读写锁上场了，发挥他的作用了，对写锁他读读是不互斥的，所有读请求拿到的都是读锁，大量读请求拿到自己想要的结果马上返回，不用阻塞，这才是我们想要的结果呀。
通过我们解答第一个问题，可能有同学发现了问题，假设现在有两个请求过来了，一个读请求A，想要读取namespace_1的信息，写请求B，想要修改namespace_2的信息，根据源码我们可以看到此时写请求先拿到锁，此时读请求A就会阻塞，直到请求B释放掉锁，自己才能执行，这就引出了，我们的第二个问题，如果自己去做，该如何设计呢，看到这里大家会不会绝对源码开发者怎么会出现这么严重的错误，其实结合具体的业务场景来看，他这样去做是完全可以的，首先，这并不是高并发的一个点，其次，添加，修改的一个namespace数据量的机会很小很小，他是完全可以承受的。
在回到我们的问题二，如果这是一个高并发的点，这样我们的锁粒度就太粗了，我们可以降低锁的粒度，可以为每一个namespace配一把读写锁，这样一来，并发性能就得到显著提高。
我们在学习源码更主要的是要学习他们在处理问题时候的一些方法，如果我们在工作中遇到了，是不是就可以轻松解决呢。
五、RouteInfoManager 路由数据管理组件
RouteInfoManager作为NameServer模块中最重要的组件，它保存着路由的基础信息，并且能够管理Broker节点，包括路由注册，路由删除等功能。
路由元信息
// 创建topic以后，每个topic是逻辑上的概念，都是有多个queue，这些queue分散在不同的broker组里
// topic->queues
private final HashMap<String/* topic */, List<QueueData>> topicQueueTable;
// 一个broker name -> broker data，代表的是一个broker组，一个broker data应该是包含了一组broker数据
private final HashMap<String/* brokerName */, BrokerData> brokerAddrTable;
// 一个nameserver是可以管理多个broker cluster，通常来说就一个cluster就可以了
// 多业务，对于大型的公司来说，他可能是有多个业务的，每个业务是可以部署独立的broker集群，对应的都是一个nameserver
private final HashMap<String/* clusterName */, Set<String/* brokerName */>> clusterAddrTable;
// 顾名思义，他应该是用于管理跟broker之间的长连接、是否还有心跳、保活
private final HashMap<String/* brokerAddr */, BrokerLiveInfo> brokerLiveTable;TopicQueueTable
Topic消息队列路由信息，消息发送时根据路由表进行负载均衡。具体数据结构如下：
topicQueueTable:{
"topic1": [
{
"brokerName": "broker-a",
"readQueueNums":4,
"writeQueueNums":4,
"perm":6,
"topicSynFlag":0,
},
{
"brokerName": "broker-b",
"readQueueNums":4,
"writeQueueNums":4,
"perm":6,
"topicSynFlag":0,
}
]
}brokerAddrTable
Broker基础信息，包含BrokerName、所属集群名称、主备Broker地址。
数据结构示例：
brokerAddrTable:{
"broker-a": {
"cluster": "c1",
"brokerName": "broker-a",
"brokerAddrs": {
0: "192.168.1.3:10003",
1: "192.168.1.4:10003"
}
},
"broker-b": {
"cluster": "c1",
"brokerName": "broker-b",
"brokerAddrs": {
0: "192.168.1.5:10003",
1: "192.168.1.6:10003"
}
}
}ClusterAddrTable
说明：Broker集群信息，存储集群中所有Broker名称。
数据结构：HashMap结构，key是ClusterName，value是存储BrokerName的Set结构。
数据结构示例：
clusterAddrTable:{
"c1": ["broker-a","broker-b"]
}BrokerLiveTable
说明：Broker状态信息。NameServer每次收到心跳包时会替换该信息
数据结构：HashMap结构，key是Broker的地址，value是BrokerLiveInfo结构的该Broker信息对象。BrokerLiveInfo的数据结构如下：
数据结构示例：
brokerLiveTable:{
"192.168.1.3:10003": {
"lastUpdateTimestamp": 1518270318980,
"dataVersion":versionObj1,
"channel":channelObj,
"haServerAddr":""
},
"192.168.1.4:10003": {
"lastUpdateTimestamp": 1518270318980,
"dataVersion":versionObj1,
"channel":channelObj,
"haServerAddr":"192.168.1.1:10000"
},
"192.168.1.5:10003": {
"lastUpdateTimestamp": 1518270318980,
"dataVersion":versionObj1,
"channel":channelObj,
"haServerAddr":""
},
"192.168.1.6:10003": {
"lastUpdateTimestamp": 1518270318980,
"dataVersion":versionObj1,
"channel":channelObj,
"haServerAddr":"192.168.1.3:10000"
}
}在了解完他的一个路由元的信息之后，我们在看一下他的路由注册功能。
路由注册
通过上面这张图我们我们可以更加清晰的看到Broker注册的一个过程。
针对其中的一些细节我们接下来仔细的看一下：
// broker可以在这里通过netty客户端组件，跟nameserver发起请求，注册broker
public List<RegisterBrokerResult> registerBrokerAll(
// 集群名称
final String clusterName,
// broker地址
final String brokerAddr,
// broker分组名称
final String brokerName,
// brokerid
final long brokerId,
// 高可用服务器地址
final String haServerAddr,
// topic元数据序列化组件
final TopicConfigSerializeWrapper topicConfigWrapper,
// 过滤服务器地址列表
final List<String> filterServerList,
// 是否oneway请求
final boolean oneway,
// 超时时间
final int timeoutMills,
// 是否启用压缩
final boolean compressed) {
// CopyOnWriteArrayList是ArrayList的一个线程安全的变体。读操作可以在不加锁的情况下进行，从而提高了并发性能。
final List<RegisterBrokerResult> registerBrokerResultList = new CopyOnWriteArrayList<>();
List<String> nameServerAddressList = this.remotingClient.getNameServerAddressList();
if (nameServerAddressList != null && nameServerAddressList.size() > 0) {
final RegisterBrokerRequestHeader requestHeader = new RegisterBrokerRequestHeader();
// ...此处删减组装数据的繁琐代码
final CountDownLatch countDownLatch = new CountDownLatch(nameServerAddressList.size());
// 遍历每个nameserver地址，发送一个注册请求
for (final String namesrvAddr : nameServerAddressList) {
brokerOuterExecutor.execute(new Runnable() {
@Override
public void run() {
try {
RegisterBrokerResult result = registerBroker(namesrvAddr, oneway, timeoutMills, requestHeader, body);
if (result != null) {
registerBrokerResultList.add(result);
}
log.info("register broker[{}]to name server {} OK", brokerId, namesrvAddr);
} catch (Exception e) {
log.warn("registerBroker Exception, {}", namesrvAddr, e);
} finally {
countDownLatch.countDown();
}
}
});
}
try {
countDownLatch.await(timeoutMills, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
}
}
return registerBrokerResultList;
}从上面代码可以看到为了提高系统性能，开启多线程到每个NameServer服务器去注册，注册的一个过程他是并行的，每个NameServer都要收到信息，因此这里使用countDownLatch，来保证我们的数据都发送到我们nameserver之后在进行其他的操作。
接着我们来看一下请求到达Broker之后他是如何进行注册的
public RegisterBrokerResult registerBroker(
final String clusterName, // broker所属的cluster集群
final String brokerAddr, // broker机器地址
final String brokerName, // broker所属的组名称
final long brokerId, // broker机器自己的id
final String haServerAddr, // 跟你的这个broker互为HA高可用的一个机器地址
final TopicConfigSerializeWrapper topicConfigWrapper, // 当前的这个broker机器上面包含的topic队列数据
final List<String> filterServerList, // broker机器上面部署的filter server列表
final Channel channel) { // 物理上的netty channel网络长连接
RegisterBrokerResult result = new RegisterBrokerResult();
try {
try {
this.lock.writeLock().lockInterruptibly();
// 拿到一个cluster集群对应的broker组，把我们的这个broker组加入到cluster里去
// 为什么要用set数据结构，一个broker组是有多个broker机器，会注册多次，组加入cluster
// 必须是set，这样可以对组进行
Set<String> brokerNames = this.clusterAddrTable.get(clusterName);
if (null == brokerNames) {
brokerNames = new HashSet<String>();
this.clusterAddrTable.put(clusterName, brokerNames);
}
brokerNames.add(brokerName);
// broker组是不是第一次来注册
boolean registerFirst = false;
// 如果是broker组第一次来注册，给初始化一份broker组数据
BrokerData brokerData = this.brokerAddrTable.get(brokerName);
if (null == brokerData) {
registerFirst = true;
brokerData = new BrokerData(clusterName, brokerName, new HashMap<Long, String>());
this.brokerAddrTable.put(brokerName, brokerData);
}
// 拿到broker组数据里的小map，broker组里的broker机器map
Map<Long, String> brokerAddrsMap = brokerData.getBrokerAddrs();
// Switch slave to master: first remove <1, IP:PORT> in namesrv, then add <0, IP:PORT>
// The same IP:PORT must only have one record in brokerAddrTable
// 这个地方是处理一些异常数据，如果说你注册过来的broker机器地址跟之前注册过的机器地址是一样的
// 但是broker id是不同的，同一台机器，你启动了不同的broker节点（用的是不同的broker.conf），是不对的
Iterator<Entry<Long, String>> it = brokerAddrsMap.entrySet().iterator();
while (it.hasNext()) {
Entry<Long, String> item = it.next();
if (null != brokerAddr && brokerAddr.equals(item.getValue()) && brokerId != item.getKey()) {
it.remove();
}
}
// 把本次要注册broker地址放到了broker组对应的broker机器地址列表里去
String oldAddr = brokerData.getBrokerAddrs().put(brokerId, brokerAddr);
registerFirst = registerFirst || (null == oldAddr);
// 如果说你是一组broker里的master，而且你上报了你管理的topic数据
// 处理broker组管理的topic的队列数据，会更新到内存的map里去
if (null != topicConfigWrapper
&& MixAll.MASTER_ID == brokerId) {
if (this.isBrokerTopicConfigChanged(brokerAddr, topicConfigWrapper.getDataVersion())
|| registerFirst) {
ConcurrentMap<String, TopicConfig> tcTable =
topicConfigWrapper.getTopicConfigTable();
if (tcTable != null) {
for (Map.Entry<String, TopicConfig> entry : tcTable.entrySet()) {
this.createAndUpdateQueueData(brokerName, entry.getValue());
}
}
}
}
// 维护跟broker之间的保活数据
BrokerLiveInfo prevBrokerLiveInfo = this.brokerLiveTable.put(brokerAddr,
new BrokerLiveInfo(
System.currentTimeMillis(),
topicConfigWrapper.getDataVersion(),
channel,
haServerAddr)
);
if (null == prevBrokerLiveInfo) {
log.info("new broker registered, {} HAServer: {}", brokerAddr, haServerAddr);
}
// 维护broker机器上部署的filter server的列表
if (filterServerList != null) {
if (filterServerList.isEmpty()) {
this.filterServerTable.remove(brokerAddr);
} else {
this.filterServerTable.put(brokerAddr, filterServerList);
}
}
// 如果说注册过来的机器是一组broker里的slave
if (MixAll.MASTER_ID != brokerId) {
String masterAddr = brokerData.getBrokerAddrs().get(MixAll.MASTER_ID);
if (masterAddr != null) {
BrokerLiveInfo brokerLiveInfo = this.brokerLiveTable.get(masterAddr);
if (brokerLiveInfo != null) {
// 他会把你的一组broker里的slave broker来注册的时候
// 给你的注册结果里设置进去你的ha server addr，是你的这一组broker里master他的ha server addr
result.setHaServerAddr(brokerLiveInfo.getHaServerAddr());
// 他还会把你这一组的broker里的master地址设置进去返回给你
result.setMasterAddr(masterAddr);
}
}
}
} finally {
this.lock.writeLock().unlock();
}
} catch (Exception e) {
log.error("registerBroker Exception", e);
}
return result;
}通过上面源码分析，我们可以分解出broker注册的一个主要步骤：
- step1：加写锁，防止并发写RouteInfoManager路由信息
- step2：判断Broker集群组是否存在，不存在则需要创建
- step3：判断broker组是不是第一次来注册，如果是broker组第一次来注册，给初始化一份broker组数据
- step4：维护跟broker之间的保活数据
- step5：如果此Broker为从节点，则需要查找Broker Master的节点信息，并更新对应masterAddr属性，并返回给Broker端
小结：通过上面的源码我们不难看出，它注册的一个本质其实就是在操作维护我们的路由元信息里面的那些Map结构，包括我们要说的路由踢出都是如此。
路由剔除
路由剔除的触发条件有两个：
- NameServer每隔10s进行扫描，如果发现某个Broker连续超过120s，没有发送心跳，则关闭broker和我们nameserver的连接
- Broker的正常关闭也会触发路由剔除
两者在NameServer端实现方式是一致的
// broker定时保活扫描，如果说你的broker机器跟nameserver之间超过2分钟没有通信
// 等于说关闭掉跟你的物理网络连接，以及清理掉内存数据结构里关于这个broker机器的数据
public void scanNotActiveBroker() {
Iterator<Entry<String, BrokerLiveInfo>> it = this.brokerLiveTable.entrySet().iterator();
while (it.hasNext()) {
Entry<String, BrokerLiveInfo> next = it.next();
long last = next.getValue().getLastUpdateTimestamp();
if ((last + BROKER_CHANNEL_EXPIRED_TIME) < System.currentTimeMillis()) {
RemotingUtil.closeChannel(next.getValue().getChannel());
it.remove();
log.warn("The broker channel expired, {} {}ms", next.getKey(), BROKER_CHANNEL_EXPIRED_TIME);
this.onChannelDestroy(next.getKey(), next.getValue().getChannel());
}
}
}
public void onChannelDestroy(String remoteAddr, Channel channel) {
String brokerAddrFound = null;
if (channel != null) {
try {
try {
this.lock.readLock().lockInterruptibly();
Iterator<Entry<String, BrokerLiveInfo>> itBrokerLiveTable =
this.brokerLiveTable.entrySet().iterator();
while (itBrokerLiveTable.hasNext()) {
Entry<String, BrokerLiveInfo> entry = itBrokerLiveTable.next();
if (entry.getValue().getChannel() == channel) {
brokerAddrFound = entry.getKey();
break;
}
}
} finally {
this.lock.readLock().unlock();
}
} catch (Exception e) {
log.error("onChannelDestroy Exception", e);
}
}
if (null == brokerAddrFound) {
brokerAddrFound = remoteAddr;
} else {
log.info("the broker's channel destroyed, {}, clean it's data structure at once", brokerAddrFound);
}
if (brokerAddrFound != null && brokerAddrFound.length() > 0) {
try {
try {
this.lock.writeLock().lockInterruptibly();
this.brokerLiveTable.remove(brokerAddrFound);
this.filterServerTable.remove(brokerAddrFound);
String brokerNameFound = null;
boolean removeBrokerName = false;
Iterator<Entry<String, BrokerData>> itBrokerAddrTable =
this.brokerAddrTable.entrySet().iterator();
while (itBrokerAddrTable.hasNext() && (null == brokerNameFound)) {
BrokerData brokerData = itBrokerAddrTable.next().getValue();
Iterator<Entry<Long, String>> it = brokerData.getBrokerAddrs().entrySet().iterator();
while (it.hasNext()) {
Entry<Long, String> entry = it.next();
Long brokerId = entry.getKey();
String brokerAddr = entry.getValue();
if (brokerAddr.equals(brokerAddrFound)) {
brokerNameFound = brokerData.getBrokerName();
it.remove();
log.info("remove brokerAddr[{}, {}] from brokerAddrTable, because channel destroyed",
brokerId, brokerAddr);
break;
}
}
if (brokerData.getBrokerAddrs().isEmpty()) {
removeBrokerName = true;
itBrokerAddrTable.remove();
log.info("remove brokerName[{}] from brokerAddrTable, because channel destroyed",
brokerData.getBrokerName());
}
}
if (brokerNameFound != null && removeBrokerName) {
Iterator<Entry<String, Set<String>>> it = this.clusterAddrTable.entrySet().iterator();
while (it.hasNext()) {
Entry<String, Set<String>> entry = it.next();
String clusterName = entry.getKey();
Set<String> brokerNames = entry.getValue();
boolean removed = brokerNames.remove(brokerNameFound);
if (removed) {
log.info("remove brokerName[{}], clusterName[{}] from clusterAddrTable, because channel destroyed",
brokerNameFound, clusterName);
if (brokerNames.isEmpty()) {
log.info("remove the clusterName[{}] from clusterAddrTable, because channel destroyed and no broker in this cluster",
clusterName);
it.remove();
}
break;
}
}
}
if (removeBrokerName) {
Iterator<Entry<String, List<QueueData>>> itTopicQueueTable =
this.topicQueueTable.entrySet().iterator();
while (itTopicQueueTable.hasNext()) {
Entry<String, List<QueueData>> entry = itTopicQueueTable.next();
String topic = entry.getKey();
List<QueueData> queueDataList = entry.getValue();
Iterator<QueueData> itQueueData = queueDataList.iterator();
while (itQueueData.hasNext()) {
QueueData queueData = itQueueData.next();
if (queueData.getBrokerName().equals(brokerNameFound)) {
itQueueData.remove();
log.info("remove topic[{} {}], from topicQueueTable, because channel destroyed",
topic, queueData);
}
}
if (queueDataList.isEmpty()) {
itTopicQueueTable.remove();
log.info("remove topic[{}] all queue, from topicQueueTable, because channel destroyed",
topic);
}
}
}
} finally {
this.lock.writeLock().unlock();
}
} catch (Exception e) {
log.error("onChannelDestroy Exception", e);
}
}
}从上面可以看出，路由剔除的整体逻辑比较简单，就是单纯地针对路由元信息的数据结构进行操作。主要步骤分解为以下几点：
- step1：加readlock，通过channel从BrokerLiveTable中找出对应的Broker地址，释放readlock，若该Broker已经从存活的Broker地址列表中被清除，则直接使用remoteAddr。
- step2：申请写锁，根据BrokerAddress从BrokerLiveTable、filterServerTable移除。
- Step3：遍历BrokerAddrTable，根据BrokerAddress找到对应的brokerData，并将brokerData中对应的brokerAddress移除，如果移除后，整个brokerData的brokerAddress空了，那么将整个brokerData移除。
- Step4：遍历clusterAddrTable，根据第三步中获取的需要移除的BrokerName，将对应的brokerName移除了。如果移除后，该集合为空，那么将整个集群从clusterAddrTable中移除。
- Step5：遍历TopicQueueTable，根据BrokerName，将Topic下对应的Broker移除掉，如果该Topic下只有一个待移除的Broker，那么该Topic也从table中移除。
六、总结
本篇文章主要是从源码的角度给大家介绍了RocketMQ的NameServer，包括NameServer的启动流程、路由注册、路由剔除。我们不难看出，他的底层操作不管是路由注册、路由剔除都是对我们的一个路由元信息进行一个更新或删除的过程，我们在学习源码的过程中不仅要看明白他的一个整体流程，更重要的是学习它里面的一个思想，我们应该多思考为什么这么用，换一种方式是否可行，多去思考，理解。
扫一扫
2232
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
