RocketMQ：深入理解路由中心（NameServer）

一、架构设计

        我们知道，消息中间件的设计思路一般基于主题的订阅发布机制，消息生产者（Produer）发送某一主题的消息到服务器，消息服务器负责该消息的持久化存储，消息消费者（Consumer）订阅感兴趣的主题，消息服务器根据订阅消息（路由消息）将消息推送到消费者（Push模式）或者消息消费者主动向消息服务器拉取消息（Pull模式），从而实现消息生产者与消息消费者解耦。

        那么，

• 消息生产者如何知道消息要发送哪台消息服务器呢？
• 消息消费者如何知道要从哪台消息服务器消费消费呢？
• 若某一太消息服务器宕机了，生产者/消费者如何在不重启服务器的情况下感知呢？

        NameServer就是为解决这些问题而设计的，看RocketMQ的逻辑部署图：

        NameServer的设计追求简单高效，摒弃了业界常使用的Zookeeper充当信息管理的“注册中心”。

        从实际需求出发，自身实现元数据的路由管理（Topic路由信息等）。

        Broker在启动时，向所有NameServer注册，生产者/消费者在发送/消费消息时，先从NameServer获取Broker服务器地址列表。

        NameServer与Broker保持长连接，并间隔30s检测Broker是否存活，若检测到Broker宕机，则从路由注册表中将其移除，且路由变化不会马上通知消息生产者。

        NameServer彼此之间互不通信，Topic路由信息无需在集群之间保持强一致性，追求最终一致性，并且能容忍分钟级的不一致。

二、源码实现

1. NameServer启动流程

        从源码的角度窥探一下 Names巳rver 启动流程，重点关注 NameServer 相关启动参数。

        NameServer 启动类 ： org.apache.rocketmq.namesrv.NamesrvStartup。

        1) 首先解析配置文件，需要填充NameServerConfig、NettyServerConfig属性值。

org.apache.rocketmq.namesrv.NamesrvStartup#createNamesrvController代码片段

//创建NameServer的业务参数配置
final NamesrvConfig namesrvConfig = new NamesrvConfig();
 
//创建NameServer的网络参数配置
final NettyServerConfig nettyServerConfig = new NettyServerConfig(); 
nettyServerConfig.setListenPort(9876); //网络监听端口
if (commandLine.hasOption('c')) { //有指定配置文件路径
    String file = commandLine.getOptionValue('c');
    if (file != null) {
        InputStream in = new BufferedInputStream(new FileInputStream(file));
        properties = new Properties();
        //加载配置参数文件
        properties.load(in);
        MixAll.properties2Object(properties, namesrvConfig);
        MixAll.properties2Object(properties, nettyServerConfig);

        namesrvConfig.setConfigStorePath(file);

        System.out.printf("load config properties file OK, %s%n", file);
        in.close();
    }
}

if (commandLine.hasOption('p')) {
    InternalLogger console = InternalLoggerFactory.getLogger(LoggerName.NAMESRV_CONSOLE_NAME);
    MixAll.printObjectProperties(console, namesrvConfig);
    MixAll.printObjectProperties(console, nettyServerConfig);
    System.exit(0);
}

MixAll.properties2Object(ServerUtil.commandLine2Properties(commandLine), namesrvConfig);

        从代码我们可以知道先创建NameServerConfig（NameServer业务参数）、NettyServerConfig（NameServer网络参数），然后解析启动时把指定的配置文件或启动命令中的选项值，填充到nameServerConfig、nettyServerConfig对象。参数来源有如下两种方式：

• -c configFile 通过 -c 命令指定配置文件的路径；
• 使用“–属性名 属性值”，例如 --listPort 9876；

        2) 根据启动属性创建NameServer核心控制器实例，并初始化

org.apache.rocketmq.namesrv.NamesrvController#initialize代码片段

//加载KV配置
this.kvConfigManager.load();
//创建NettyServer网络处理对象
this.remotingServer = new NettyRemotingServer(this.nettyServerConfig, this.brokerHousekeepingService);

this.remotingExecutor =
    Executors.newFixedThreadPool(nettyServerConfig.getServerWorkerThreads(), new ThreadFactoryImpl("RemotingExecutorThread_"));
//注册NameServer接收、响应请求的处理器
this.registerProcessor();
//启动定时任务，扫描、移除失效的Broker（10s/次）
this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {

    @Override
    public void run() {
        NamesrvController.this.routeInfoManager.scanNotActiveBroker();
    }
}, 5, 10, TimeUnit.SECONDS);
//启动定时任务，打印KV配置信息（10m/次）
this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {

    @Override
    public void run() {
        NamesrvController.this.kvConfigManager.printAllPeriodically();
    }
}, 1, 10, TimeUnit.MINUTES);

        加载KV配置，创建NettyServer网络处理对象，然后开启两个定时任务，在RocketMQ中此类定时任务统称为心跳检测。

• 定时任务1：NameServer每个10s扫描一次Broker，移除处于不激活状态的Broker；
• 定时任务2：NameServer每个10分钟打印一次KV配置；

2. NameServer核心业务逻辑处理

        当NameServer的网络通信服务模块收到请求后，就调用这个 Processor 来处理。

org.apache.rocketmq.namesrv.processor.DefaultRequestProcessor#processRequest代码片段

public RemotingCommand processRequest(ChannelHandlerContext ctx,
    RemotingCommand request) throws RemotingCommandException {

    if (ctx != null) {
        log.debug("receive request, {} {} {}",
            request.getCode(),
            RemotingHelper.parseChannelRemoteAddr(ctx.channel()),
            request);
    }

    switch (request.getCode()) {
        case RequestCode.PUT_KV_CONFIG:
            return this.putKVConfig(ctx, request);
        case RequestCode.GET_KV_CONFIG:
            return this.getKVConfig(ctx, request);
        case RequestCode.DELETE_KV_CONFIG:
            return this.deleteKVConfig(ctx, request);
        case RequestCode.QUERY_DATA_VERSION:
            return queryBrokerTopicConfig(ctx, request);
        case RequestCode.REGISTER_BROKER: //broker注册请求
            Version brokerVersion = MQVersion.value2Version(request.getVersion());
            if (brokerVersion.ordinal() >= MQVersion.Version.V3_0_11.ordinal()) {
                return this.registerBrokerWithFilterServer(ctx, request);
            } else {
                return this.registerBroker(ctx, request);
            }
        case RequestCode.UNREGISTER_BROKER:
            return this.unregisterBroker(ctx, request);
        case RequestCode.GET_ROUTEINTO_BY_TOPIC: //客户端路由发现
            return this.getRouteInfoByTopic(ctx, request);
        case RequestCode.GET_BROKER_CLUSTER_INFO:
            return this.getBrokerClusterInfo(ctx, request);
        case RequestCode.WIPE_WRITE_PERM_OF_BROKER:
            return this.wipeWritePermOfBroker(ctx, request);
        case RequestCode.GET_ALL_TOPIC_LIST_FROM_NAMESERVER:
            return getAllTopicListFromNameserver(ctx, request);
        case RequestCode.DELETE_TOPIC_IN_NAMESRV:
            return deleteTopicInNamesrv(ctx, request);
        case RequestCode.GET_KVLIST_BY_NAMESPACE:
            return this.getKVListByNamespace(ctx, request);
        case RequestCode.GET_TOPICS_BY_CLUSTER:
            return this.getTopicsByCluster(ctx, request);
        case RequestCode.GET_SYSTEM_TOPIC_LIST_FROM_NS:
            return this.getSystemTopicListFromNs(ctx, request);
        case RequestCode.GET_UNIT_TOPIC_LIST:
            return this.getUnitTopicList(ctx, request);
        case RequestCode.GET_HAS_UNIT_SUB_TOPIC_LIST:
            return this.getHasUnitSubTopicList(ctx, request);
        case RequestCode.GET_HAS_UNIT_SUB_UNUNIT_TOPIC_LIST:
            return this.getHasUnitSubUnUnitTopicList(ctx, request);
        case RequestCode.UPDATE_NAMESRV_CONFIG:
            return this.updateConfig(ctx, request);
        case RequestCode.GET_NAMESRV_CONFIG:
            return this.getConfig(ctx, request);
        default:
            break;
    }
    return null;
}

3. NameServer路由注册、故障剔除

        我们知道，NameServer的设计目的主要是提供Broker注册，为消息生产者/消费者提供关于Topic的路由信息。

        那么NameServer需要存储路由的基础信息，还要能够管理Broker节点，包括路由注册、路由剔除等功能。

        1) 路由元信息

        在了解路由注册之前，我们首先看一下 NameServer 到底存储哪些信息 。

org.apache.rocketmq.namesrv.routeinfo.RouteInfoManager代码片段

private final HashMap<String/* topic */, List<QueueData>> topicQueueTable; //topic消息队列路由
private final HashMap<String/* brokerName */, BrokerData> brokerAddrTable; //broker基础信息
private final HashMap<String/* clusterName */, Set<String/* brokerName */>> clusterAddrTable; //broker集群信息
private final HashMap<String/* brokerAddr */, BrokerLiveInfo> brokerLiveTable; //broker状态信息
private final HashMap<String/* brokerAddr */, List<String>/* Filter Server */> filterServerTable; //broker，FilterServer列表

• topicQueueTable: Topic 消息队列路由信息，消息发送时根据路由表进行负载均衡 。
• brokerAddrTable : Broker 基础信息，包含 brokerName 、 所属集群名称 、 主备 Broker地址 。
• clusterAddrTable: Broker 集群信息，存储集群中所有 Broker 名称 。
• brokerLiveTable: Broker 状态信息 ，NameServer 每次收到心跳包时会替换该信息 。
• filterServerTable : Broker 上的 FilterServer 列表。

        2) 路由注册处理

        RocketMQ路由注册是通过Broker与NameServer的心跳功能实现的。

        Broker启动时，向集群中所有NameServer发送心跳，每个30s向集群中所有NameServer发送心跳包，NameServer收到Broker心跳包时会更新brokerLiveTable缓存中BrokerLiveInfo的lastUpdateTimestamp，然后NameServer每隔10s扫描brokerLiveTable，如果连续120s没有收到心跳包，NameServer将剔除该Broker的路由信息同时关闭Socket连接。

org.apache.rocketmq.broker.BrokerController#start代码片段

//先注册一次broker，后续开启任务定时注册
this.registerBrokerAll(true, false, true);

//开启定时任务，注册broker
this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {

    @Override
    public void run() {
        try {
            BrokerController.this.registerBrokerAll(true, false, brokerConfig.isForceRegister());
        } catch (Throwable e) {
            log.error("registerBrokerAll Exception", e);
        }
    }
}, 1000 * 10, Math.max(10000, Math.min(brokerConfig.getRegisterNameServerPeriod(), 60000)), TimeUnit.MILLISECONDS);

        Broker定时发送心跳包，上报NameServer自身的存活状态。

org.apache.rocketmq.broker.out.BrokerOuterAPI#registerBrokerAll代码片段

//获取namesrv地址列表
List<String> nameServerAddressList = this.remotingClient.getNameServerAddressList(); 

for (final String namesrvAddr : nameServerAddressList) {
    brokerOuterExecutor.execute(new Runnable() {
        @Override
        public void run() {
            try {
            	//注册broker
                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();
            }
        }
    });
}

        遍历NameServer列表，Broker消息服务器依次向NameServer发送心跳包。

org.apache.rocketmq.namesrv.routeinfo.RouteInfoManager#registerBroker代码片段

//2. 维护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);
}
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
Iterator<Entry<Long, String>> it = brokerAddrsMap.entrySet().iterator();
while (it.hasNext()) {
    Entry<Long, String> item = it.next();
    //新注册的broker与旧的不一致，则删除旧的broker信息
    if (null != brokerAddr && brokerAddr.equals(item.getValue()) && brokerId != item.getKey()) {
        it.remove();
    }
}

String oldAddr = brokerData.getBrokerAddrs().put(brokerId, brokerAddr); //缓存broker地址
registerFirst = registerFirst || (null == oldAddr); //判断是否第一次注册
//3. broker为master，且初次注册或者topic配置信息发生变化，则创建或更新topic的路由元数据
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());
            }
        }
    }
}
//4. 更新broker存活信息
BrokerLiveInfo prevBrokerLiveInfo = this.brokerLiveTable.put(brokerAddr,
    new BrokerLiveInfo(
        System.currentTimeMillis(), //Broker存活的最新更新时间
        topicConfigWrapper.getDataVersion(),
        channel,
        haServerAddr));
if (null == prevBrokerLiveInfo) {
    log.info("new broker registered, {} HAServer: {}", brokerAddr, haServerAddr);
}
//5. 注册broker的过滤器
if (filterServerList != null) {
    if (filterServerList.isEmpty()) {
        this.filterServerTable.remove(brokerAddr);
    } else {
        this.filterServerTable.put(brokerAddr, filterServerList);
    }
}
//6. broker非master，获取master的broker地址返回
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) {
            result.setHaServerAddr(brokerLiveInfo.getHaServerAddr());
            result.setMasterAddr(masterAddr);
        }
    }
}

        3) 路由剔除

        根据前面的分析，我们知道Broker每隔30s向NameServer发送一个心跳包，上报自己的存活信息。

        那么如果Broker宕机，NameServer无法收到心跳包，此时NameServer如何来剔除这些失效的Broker呢？

        NamerServer会每隔10s扫描brokerLiveTable状态表，如果BrokerLive的lastUpdateTimestamp的时间戳距当前时间超过120s，则认为Broker失效，移除该Broker，关闭与Broker的连接，并同时更新topicQueueTable、brokerAddrTable、brokerLiveTable、filterServerTable。

        RocktMQ 有两个触发点来触发路由删除：

• NameServer 定 时扫描 brokerLiveTable 检测上次心跳包与 当前系统时间的时间 差，如果时间戳大于 120s ，则需要移除该 Broker 信息 。
• Broker 在正常被关闭的情况下，会执行 unregisterBroker 指令。

org.apache.rocketmq.namesrv.routeinfo.RouteInfoManager#scanNotActiveBroker代码片段

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();
        //判断broker更新的最近时间戳，距当前事件超过120s
        //则认为broker失效，移除该broker，关闭与broker的连接
        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());
        }
    }
}

        4) 路由发现

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

org.apache.rocketmq.client.impl.factory.MQClientInstance#startScheduledTask代码片段

private void startScheduledTask() {
    this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {

        @Override
        public void run() {
            try {
                MQClientInstance.this.updateTopicRouteInfoFromNameServer();
            } catch (Exception e) {
                log.error("ScheduledTask updateTopicRouteInfoFromNameServer exception", e);
            }
        }
    }, 10, this.clientConfig.getPollNameServerInterval(), TimeUnit.MILLISECONDS);

    this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {

        @Override
        public void run() {
            try {
                MQClientInstance.this.cleanOfflineBroker();
                MQClientInstance.this.sendHeartbeatToAllBrokerWithLock();
            } catch (Exception e) {
                log.error("ScheduledTask sendHeartbeatToAllBroker exception", e);
            }
        }
    }, 1000, this.clientConfig.getHeartbeatBrokerInterval(), TimeUnit.MILLISECONDS);
}

        Producer/Consumer启动后，开启定时任务从NameServer更新Topic路由信息。

org.apache.rocketmq.namesrv.processor.DefaultRequestProcessor#getRouteInfoByTopic代码片段

public RemotingCommand getRouteInfoByTopic(ChannelHandlerContext ctx,
    RemotingCommand request) throws RemotingCommandException {
    final RemotingCommand response = RemotingCommand.createResponseCommand(null);
    final GetRouteInfoRequestHeader requestHeader =
        (GetRouteInfoRequestHeader) request.decodeCommandCustomHeader(GetRouteInfoRequestHeader.class);
    //1. 获取topic的路由信息
    TopicRouteData topicRouteData = this.namesrvController.getRouteInfoManager().pickupTopicRouteData(requestHeader.getTopic());

    if (topicRouteData != null) {
        //2. 若topic为顺序消息，则从KV中获取顺序消息填充路由
        if (this.namesrvController.getNamesrvConfig().isOrderMessageEnable()) {
            String orderTopicConf =
                this.namesrvController.getKvConfigManager().getKVConfig(NamesrvUtil.NAMESPACE_ORDER_TOPIC_CONFIG,
                    requestHeader.getTopic());
            topicRouteData.setOrderTopicConf(orderTopicConf);
        }

        byte[] content = topicRouteData.encode();
        response.setBody(content);
        response.setCode(ResponseCode.SUCCESS);
        response.setRemark(null);
        return response;
    }

    response.setCode(ResponseCode.TOPIC_NOT_EXIST);
    response.setRemark("No topic route info in name server for the topic: " + requestHeader.getTopic()
        + FAQUrl.suggestTodo(FAQUrl.APPLY_TOPIC_URL));
    return response;
}

        通过上述分析，NameServer其核心在于Broker路由注册及路由查询，但有一个关键点，Broker失效后，NameServer是定时查询失效Broker并删除路由信息的，也就是说，在某一个时刻，Broker已经宕机了，但是NameServer中还维持有该Broker路由信息，这样Producer在查询路由信息时，就可能从NameServer查询到一个已经失效的路由信息，这不是违背了高可用的原则了？

        实际上MQ在消息发送/消费时，针对这种情况做了容错处理。

---

引用

《RocketMQ技术内幕》