万字超详细解析——RocketMQ

前言

工作中很多种场景下会用到消息队列，消息队列简单来说就是 消息的传输过程中保存消息的容器。消息队列主要解决了应用耦合、异步处理、流量削峰等问题。今天我们来了解一下阿里开源的一款产品 RocketMQ。

RocketMQ简介

RocketMQ 是一款低延迟、高并发、高可用、高可靠的分布式消息中间件。具备异步通信的优势，系统拓扑简单、上下游耦合较弱，主要应用于异步解耦，流量削峰填谷等场景。

NameServer

NameServer 是整个 RocketMQ 的“大脑”，是 RocketMQ 的 路由中心。NameServer 的主要作用是为消息生产者和消息消费者提供有关 Topic 的路由信息，所以 NameServer 就需要存储路由信息，并且能够管理 Broker 节点，包括路由注册、路由删除等功能。

路由中心高可用

“大脑”一旦故障，那可不是闹着玩的，那么必然要有对策来解决。NameServer 的 高可用可以通过部署多台 NameServer 服务器来实现，但彼此之间互不通信。虽然 NameServer 服务器之间在某一时刻的数据并不会完全相同，但对消息发送不会在成重大影响，无非就是短暂造成消息发送不均衡（是不是有很熟悉的味道呢？没错CAP理论，这不就是AP嘛）。RocketMQ 在 NameServer 这个模块的设计上选择了 AP。

元数据存储

既然是路由中心，那么路由信息是如何存储的呢？我们来看一下RouteInfoManager这个类。

java

复制代码

public class RouteInfoManager { // Topic消息队列的路由信息 private final HashMap<String/* topic */, List<QueueData>> topicQueueTable; // Broker的基础信息 private final HashMap<String/* brokerName */, BrokerData> brokerAddrTable; // Broker的集群信息 private final HashMap<String/* clusterName */, Set<String/* brokerName */>> clusterAddrTable; // Broker的状态信息，NameServer每次收到心跳包时会替换该信息 private final HashMap<String/* brokerAddr */, BrokerLiveInfo> brokerLiveTable; // Broker对应的FilterServer列表，用于类模式消息过滤。类模式过滤机制在4.4及以后版本被废弃 private final HashMap<String/* brokerAddr */, List<String>/* Filter Server */> filterServerTable; }

NameServer 存储的信息，就在RouteInfoManager这个类里。

路由注册

RockerMQ 路由注册是通过 Broker 与 NameServer 的心跳功能实现的。Broker 启动时向集群中所有的 NameServer 发送心跳语句，每隔 30s 向集群中所有的 NameServer 发送心跳包，NameServer收到心跳包会先更新 RouteInfoManager 类中 brokerLiveTable 中 BrokerLiveInfo的 lastUpdateTimestamp，然后每隔 10s 扫描一次 brokerLiveTable，如果连续 120s 没有收到心跳包，NameServer 将移除该 Broker 的路由信息，同时关闭 Socket 连接。

路由删除

上边提到了 NameServer 如果连续 120s 没有收到 Broker 的心跳包，将移除该 Broker 的路由信息。还有一点就是 Broker 在 正常关闭的情况下，会执行 unregisterBroker 命令。

路由发现

RockerMQ 路由发现是非实时的，当 Topic 路由出现变化后，NameServer 不会主动推送给客户端，而是由客户端定时拉取主题最新的路由。

NameServer架构设计

Broker

上文多次提到了 Broker，Broker 是 RocketMQ 的一个核心组件，大部分重量级工作都是通过 Broker 来完成的。Borker 处理各种请求和存储消息，决定整个 RocketMQ 体系的