全面解析 RocketMQ 神经中枢 NameServer
（给ImportNew加星标，提高Java技能）
RocketMQ 在国内系统中使用还是比较多的，面试中，工作中常常被提及，以前有逐帧阅读过 RocketMQ 的源码，长时间不回顾，也忘得差不多了。这次就再拾起来重新回顾一番，也算加深下印象。
首先呢，RocketMQ 是一款开源的分布式消息中间件，最初由阿里巴巴公司开发并开源。它提供了高可靠、高吞吐量、低延迟的消息传输服务，被广泛应用于大规模分布式系统中的消息通信场景。
RocketMQ 包含以下几个核心组件：
-
Name Server
-
Broker
-
Producer
-
Consumer
-
Topic
-
Message Queue
-
Consumer Group
本文我们就从一个快递中心的角度，一起去看看 Name Server 所包含的功能以及工作原理。
Name Server 负责维护整个 RocketMQ 集群中各个 Broker 的路由信息，客户端通过与 Name Server 交互获取消息发送或者消费的路由信息。
下面详细解释一下 Name Server 的功能：
1、路由注册
当一个 Broker 启动时，它会向 Name Server 注册自己的信息，包括 Broker 的名称、IP 地址、监听端口等。Name Server 会将这些信息记录下来，并在需要时向其他组件提供。
那么路由注册是如何进行的呢？
1.1. Broker 启动时注册
当一个 Broker 启动时，它会向集群中的所有 Name Server 发送注册请求。这个注册请求包含了 Broker 的基本信息，如 Broker 名称、IP地址、监听端口等。
就好比一个快递公司的总部。每个快递员上班打卡，向总部发送自己上班了的信息。发送的信息就包含了自己的名字，工号，以及所在的位置。
1.2 Name Server 接收注册请求
Name Server 接收到 Broker 的注册请求后，会将该 Broker 的信息记录下来，并在自身的路由表中维护该 Broker 的路由信息。
总部接收到信息之后，就把该快递员的信息记录下来。
1.3 路由信息更新
如果一个 Broker 发生了变化，比如新增了一个 Broker 节点、删除了一个 Broker 节点或者修改了 Broker 的配置信息，那么该 Broker 会重新向 Name Server 发送注册请求，告知 Name Server 发生了变化。Name Server 接收到变化后会更新自身的路由表，保证路由信息的实时性和准确性。
总部会不断的更新快递员的信息，若是有新的快递员上班了，会增加信息。若是有快递员下班了，无法继续送货了就取消该快递员的信息，所以，总部的信息一直是实时的和最新的。
1.4 心跳检测
Broker会定期向已注册的 Name Server 发送心跳请求，提交并更新自己的信息，Name Server 可以据此检测 Broker 的状态是否正常。如果某个 Broker 长时间未响应心跳请求，Name Server 会将其标记为不可用，并从路由信息中移除，以保证客户端获取到的路由信息是最新的和可用的。
快递员需要每隔一段时间向总部发信息上报自己的工作状态，若是长时间没发送信息，那么就认为这个快递员偷懒了，或不能继续工作了，处于离线状态，就不会给他安排新的活了。
1.5 路由信息的提供
客户端在需要与 Broker 通信时，通过与 Name Server 交互获取路由信息。Name Server 会根据客户端的请求，提供相应的路由信息，包括 Broker 的地址和端口等。客户端可以根据路由信息选择合适的 Broker 进行通信。
若是有客户想发快递了。会在官网找到总部，然后提交自己想把快递发到哪里，然后总部会找到符合条件的快递员。进行发货。
2、路由查询
客户端（包括生产者和消费者）需要与 Broker 通信时，首先要获取 Broker 的路由信息，以确定消息应该发送到哪个 Broker 或者从哪个 Broker 消费消息。客户端通过与 Name Server 交互，可以获取到所需的 Broker 信息，包括该 Broker 所在的地址和端口等。
那么路由查询具体如何执行的呢？
2.1 客户端发送路由查询请求
客户端在需要与 Broker 通信时，首先向集群中的任意一个 Name Server 发送路由查询请求。查询请求中通常包含了客户端所需操作的主题（Topic）信息。
客户想找快递员时发快递的时候，会在官网找相关信息。同时会提交自己想寄快递的"主题"，可以理解为种类。
2.2 Name Server 接收路由查询请求
当一个 Name Server 接收到路由查询请求后，会根据请求中的主题信息，在自身维护的路由表中查找与该主题相关的 Broker 的路由信息。
这时候，总部的客服会看到客户的请求，根据货物的种类，找相关的快递员。
2.3 路由信息响应
如果 Name Server 找到了与请求主题相关的 Broker 的路由信息，它会将这些路由信息打包成响应，发送给客户端。路由信息中包括了每个 Broker 的名称、地址、端口等信息。
找到相关的快递员之后，会把这个快递员的信息，比电话，名字，现在在哪，如何联系等都给客户发过去。
2.4 客户端获取路由信息
客户端接收到 Name Server 的响应后，获取到了与请求主题相关的 Broker 的路由信息。根据这些路由信息，客户端可以选择合适的 Broker 进行通信。
客户收到快递员的信息之后，就可以主动联系快递员了。
2.5 负载均衡和容错处理
客户端在获取到路由信息后，通常会根据一定的负载均衡策略选择一个Broker进行通信。同时，客户端也会实施一些容错机制，如当选择的 Broker 不可用时，会尝试选择其他可用的 Broker 进行通信。
一般在相同的条件下，会有多个快递员在工作，总部会根据工作情况返回，若是客户挑选的恰好在忙或者没有接电话，进行反馈，那么客户会选择其他的快递员进行投递。
3、心跳检测
Name Server 会定期向已注册的 Broker 发送心跳请求，以检测 Broker 的状态是否正常。如果某个 Broker 长时间未响应心跳请求，Name Server 会将其标记为不可用，并从路由信息中移除，以保证客户端获取到的路由信息是最新的和可用的。
3.1 Broker 注册时发送心跳
当一个 Broker 启动并向 Name Server 注册时，它会定期（通常是每隔一定时间间隔）向所有已知的 Name Server 发送心跳消息。
上面说了，快递员需要每隔一段时间，向总部发送信息，汇报自己的工作情况。
3.2 心跳消息格式
心跳消息通常包含了 Broker 的基本信息，比如 Broker 名称、IP 地址、监听端口等。这些信息用于让 Name Server 确认 Broker 的存在和可用性。
信息一般包含快递员的基本信息、名字、地址、工号等。
3.3 Name Server 接收心跳消息
当一个 Name Server 接收到 Broker 发送的心跳消息后，会更新自己维护的 Broker 信息表，标记该 Broker 为在线状态，并记录下最近收到心跳的时间。
总部接收到信息之后，就维护一下所有上班的快递员表，标记这个快递员是上班了的，并记录了接收到信息的时间。
3.4 超时检测
Name Server 会定期检查维护的 Broker 信息表，判断哪些 Broker 已经超过了一定的时间没有发送心跳消息。如果发现某个 Broker 已经长时间未发送心跳消息，则认为该 Broker 可能已经宕机或者不可用。
总部的员工每隔一段时间，就把所有员工的表检查一遍，看看有没有快递员，很长时间没有汇报自己的信息，若是发现有快递员超过多久（真正的 RocketMQ 中是 15 秒）没有发送信息，那么就认为这个快递员离线了，不干活了。
3.5 处理超时 Broker
当发现某个 Broker 已经超时未发送心跳消息时，Name Server会将其标记为离线状态，并从维护的 Broker 信息表中移除该 Broker 的信息。同时，Name Server会将这一信息广播给集群中的其他 Name Server，以确保整个集群中都能及时更新 Broker 的状态。
总部的员工一旦检查出来哪个快递员不干活了，还会告诉其他总部的员工，这家伙不干活了。别给他派活了。
3.6 更新路由信息
当有 Broker 的状态发生变化时，Name Server 会相应地更新维护的路由信息表。这样，客户端在获取路由信息时可以获得最新的、可用的 Broker 列表。
总部的这张快递员状态表，是实时更新的，确保客户在想寄快递的时候，能拿到最准确的最可靠的快递员的信息。
总结
也就是说通过路由信息的维护和查询，Name Server 实现了 Broker 集群的动态扩展和节点的动态发现，使得 RocketMQ 集群具备了高可用性和灵活性。客户端通过与 Name Server 交互，可以快速地获取到消息发送和消费的路由信息，从而实现消息的可靠传输和高效处理。
转自：奔跑的毛球，
链接：juejin.cn/post/7357006184475312164
– EOF –
推荐阅读 点击标题可跳转
看完本文有收获？请转发分享给更多人
关注「ImportNew」，提升Java技能
点赞和在看就是最大的支持❤️
