从用户的视角来感受一个开源项目的成长，是我们推出「开发者说」专栏的初衷，即在开发者进行开源项目选型时，提供更为立体的项目信息。本文是「开发者说」的第7篇，作者张乘辉，GitHub ID @objcoding，Java开发工程师， 对分布式中间件有浓厚兴趣，「后端进阶」公众号作者。
- 正文开始 -
?
我还记得第一次使用 RocketMQ 的时候，需要去控制台预先创建 Topic，我当时就想为什么要这么设计，于是我决定撸一波源码，带大家从根源上吃透 RocketMQ Topic 的创建机制。
Topic 在 RocketMQ 的设计思想里，是作为同一个业务逻辑消息的组织形式，它仅仅是一个逻辑上的概念，而在一个 Topic 下又包含若干个逻辑队列，即消息队列，消息内容实际是存放在队列中，而队列又存储在 Broker中，下面我用一张图来说明 Topic 的存储模型：
其实 RocketMQ 中存在两种不同的 Topic 创建方式，一种是我刚刚说的预先创建，另一种是自动创建，下面我开车带大家从源码的角度来详细地解读这两种创建机制。
自动创建
默认情况下，Topic 不用手动创建，当 Producer 进行消息发送时，会从 Nameserver 拉取 Topic 的路由信息，如果 Topic 的路由信息不存在，那么会默认拉取 Broker 启动时默认创建好名为“TBW102”的Topic：
org.apache.rocketmq.common.MixAll：
// Will be created at broker when isAutoCreateTopicEnable
public static final String AUTO_CREATE_TOPIC_KEY_TOPIC = "TBW102";
自动创建的开关配置在BrokerConfig中，通过autoCreateTopicEnable字段进行控制，
org.apache.rocketmq.common.BrokerConfig：
@ImportantField
private boolean autoCreateTopicEnable = true;
在 Broker 启动时，会调用TopicConfigManager的构造方法，autoCreateTopicEnable打开后，会将“TBW102”保存到topicConfigTable中：
org.apache.rocketmq.broker.topic.TopicConfigManager#TopicConfigManager：
// MixAll.AUTO_CREATE_TOPIC_KEY_TOPIC
if (this.brokerController.getBrokerConfig().isAutoCreateTopicEnable()) {
String topic = MixAll.AUTO_CREATE_TOPIC_KEY_TOPIC;
TopicConfig topicConfig = new TopicConfig(topic);
this.systemTopicList.add(topic);
topicConfig.setReadQueueNums(this.brokerController.getBrokerConfig()
.getDefaultTopicQueueNums());
topicConfig.setWriteQueueNums(this.brokerController.getBrokerConfig()
.getDefaultTopicQueueNums());
int perm = PermName.PERM_INHERIT | PermName.PERM_READ | PermName.PERM_WRITE;
topicConfig.setPerm(perm);
this.topicConfigTable.put(topicConfig.getTopicName(), topicConfig);
}
Broker 会通过发送心跳包将topicConfigTable的 Topic 信息发送给 Nameserver，Nameserver将 Topic 信息注册到RouteInfoManager中。
继续看消息发送时是如何从 Nameserver 获取 Topic 的路由信息：
org.apache.rocketmq.client.impl.producer.DefaultMQProducerImpl#tryToFindTopicPublishInfo：
private TopicPublishInfo tryToFindTopicPublishInfo(final String topic) {
TopicPublishInfo topicPublishInfo = this.topicPublishInfoTable.get(topic);
if (null == topicPublishInfo || !topicPublishInfo.ok()) {
this.topicPublishInfoTable.putIfAbsent(topic, new TopicPublishInfo());
// 生产者第一次发送消息，topic在nameserver中并不存在
this.mQClientFactory.updateTopicRouteInfoFromNameServer(topic);
topicPublishInfo = this.topicPublishInfoTable.get(topic);
}
if (topicPublishInfo.isHaveTopicRouterInfo() || topicPublishInfo.ok()) {
return topicPublishInfo;
} else {
// 第二次请求会将isDefault=true，开启默认“TBW102”从namerserver获取路由信息
this.mQClientFactory.updateTopicRouteInfoFromNameServer(topic, true, this.defaultMQProducer);
topicPublishInfo = this.topicPublishInfoTable.get(topic);
return topicPublishInfo;
}
}
如上方法，Topic 首次发送消息，此时并不能从 Namserver 获取 Topic 的路由信息，那么接下来会进行第二次请求 Namserver，这时会将isDefault=true，开启默认“TBW102”从 Namerserver 获取路由信息，此时的“TBW102”topic已经被broker默认注册到 Nameserver 了：
org.apache.rocketmq.client.impl.factory.MQClientInstance#updateTopicRouteInfoFromNameServer：
if (isDefault && defaultMQProducer != null) {
// 使用默认的“TBW102”topic获取路由信息
topicRouteData = this.mQClientAPIImpl.getDefaultTopicRouteInfoFromNameServer(defaultMQProducer.getCreateTopicKey(),1000 * 3);
if (topicRouteData != null) {
for (QueueData data : topicRouteData.getQueueDatas()) {
int queueNums = Math.min(defaultMQProducer.getDefaultTopicQueueNums(), data.getReadQueueNums());
data.setReadQueueNums(queueNums);
data.setWriteQueueNums(queueNums);
}
}
}
如果isDefault=true并且defaultMQProducer不为空，从 Nameserver 中获取默认路由信息，此时会获取所有已开启自动创建开关的 Broker 的默认“TBW102”topic路由信息，并保存默认的Topic消息队列数量。
org.apache.rocketmq.client.impl.factory.MQClientInstance#updateTopicRouteInfoFromNameServer：
TopicRouteData old = this.topicRouteTable.get(topic);
boolean changed = topicRouteDataIsChange(old, topicRouteData);
if (!changed) {
changed = this.isNeedUpdateTopicRouteInfo(topic);
} else {
log.info("the topic[{}] route info changed, old[{}] ,new[{}]", topic, old, topicRouteData);
}
从本地缓存中取出 Topic 的路由信息，由于 Topic 是第一次发送消息，这时本地并没有该 Topic 的路由信息，所以对比该 Topic 路由信息对比“TBW102”时changed为true，即有变化，进入以下逻辑：
org.apache.rocketmq.client.impl.factory.MQClientInstance#updateTopicRouteInfoFromNameServer：
// Update sub info
{
Set<MessageQueue> subscribeInfo = topicRouteData2TopicSubscribeInfo(topic, topicRouteData);
Iterator<Entry<String, MQConsumerInner>> it = this.consumerTable.entrySet().iterator();
while (it.hasNext()) {
Entry<String, MQConsumerInner> entry = it.next();
MQConsumerInner impl = entry.getValue();
if (impl != null) {
impl.updateTopicSubscribeInfo(topic, subscribeInfo);
}
}
}
将“TBW102”topic路由信息构建TopicPublishInfo，并将用 Topic 为key，TopicPublishInfo为value更新本地缓存，到这里就明白了，原来 Broker 们千辛万苦创建“TBW102” Topic 并将其路由信息注册到 Nameserver，被新来的 Topic 获取后立即用“TBW102”Topic的路由信息构建出一个TopicPublishInfo并且据为己有，由于TopicPublishInfo的路由信息时默认“TBW102”Topic，因此真正要发送消息的 Topic 也会被负载发送到“TBW102”topic所在的 Broker 中，这里我们可以将其称之为偷梁换柱的做法。
当 Broker 接收到消息后，会在msgCheck方法中调用createTopicInSendMessageMethod方法，将 Topic 的信息塞进topicConfigTable缓存中，并且 Broker 会定时发送心跳将topicConfigTable发送给 Nameserver 进行注册。
自动创建与消息发送时获取 Topic 信息的时序图：
预先创建
其实这个叫预先创建似乎更加适合，即预先在 Broker 中创建好 Topic 的相关信息并注册到Nameserver 中，然后 client 端发送消息时直接从 Nameserver 中获取 Topic 的路由信息，但是手动创建从动作上来将更加形象通俗易懂，直接告诉你，你的 Topic 信息需要在控制台上自己手动创建。
预先创建需要通过mqadmin提供的 Topic 相关命令进行创建，执行：
./mqadmin updateTopic
官方给出的各项参数如下：
usage: mqadmin updateTopic [-b <arg>] [-c <arg>] [-h] [-n <arg>] [-o <arg>] [-p <arg>] [-r <arg>] [-s <arg>]
-t <arg> [-u <arg>] [-w <arg>]
-b,--brokerAddr <arg> create topic to which broker
-c,--clusterName <arg> create topic to which cluster
-h,--help Print help
-n,--namesrvAddr <arg> Name server address list, eg: 192.168.0.1:9876;192.168.0.2:9876
-o,--order <arg> set topic's order(true|false
-p,--perm <arg> set topic's permission(2|4|6), intro[2:W 4:R; 6:RW]
-r,--readQueueNums <arg> set read queue nums
-s,--hasUnitSub <arg> has unit sub (true|false
-t,--topic <arg> topic name
-u,--unit <arg> is unit topic (true|false
-w,--writeQueueNums <arg> set write queue nums
我们直接定位到其实现类执行命令的方法：
通过broker模式创建：
org.apache.rocketmq.tools.command.topic.UpdateTopicSubCommand#execute：
// -b,--brokerAddr <arg> create topic to which broker
if (commandLine.hasOption('b')) {
String addr = commandLine.getOptionValue('b').trim();
defaultMQAdminExt.start();
defaultMQAdminExt.createAndUpdateTopicConfig(addr, topicConfig);
return;
}
从commandLine命令行工具获取运行时-b参数中的 Broker 的地址，defaultMQAdminExt是默认的 RocketMQ 控制台执行的API，此时调用start方法，该方法创建了一个mqClientInstance，它封装了netty通信的细节，接着就是最重要的一步，调用createAndUpdateTopicConfig将 Topic 配置信息发送到指定的 Broker 上，完成 Topic 的创建。
通过集群模式创建：
org.apache.rocketmq.tools.command.topic.UpdateTopicSubCommand#execute：
// -c,--clusterName <arg> create topic to which cluster
else if (commandLine.hasOption('c')) {
String clusterName = commandLine.getOptionValue('c').trim();
defaultMQAdminExt.start();
Set<String> masterSet =
CommandUtil.fetchMasterAddrByClusterName(defaultMQAdminExt, clusterName);
for (String addr : masterSet) {
defaultMQAdminExt.createAndUpdateTopicConfig(addr, topicConfig);
System.out.printf("create topic to %s success.%n", addr);
}
return;
}
通过集群模式创建与通过 Broker 模式创建的逻辑大致相同，多了根据集群从 Nameserver 获取集群下所有 Broker 的 master 地址这个步骤，然后在循环发送 Topic 信息到集群中的每个 Broker 中，这个逻辑跟指定单个 Broker 是一致的。
这也说明了当用集群模式去创建 Topic 时，集群里面每个 Broker 的 Queue 的数量相同，当用单个Broker 模式去创建 Topic 时，每个 Broker 的 Queue 数量可以不一致。
预先创建时序图：
何时需要预先创建 Topic？
建议线下开启，线上关闭，不是我说的，是官方给出的建议：
RocketMQ 为什么要这么设计呢？
经过一波源码深度解析后，我得到了我想要的答案：
根据上面的源码分析，我们得出，RocketMQ 在发送消息时，会先去获取 Topic 的路由信息，如果 Topic 是第一次发送消息，由于 Nameserver 没有 Topic 的路由信息，所以会再次以“TBW102”这个默认 Topic 获取路由信息，假设 Broker 都开启了自动创建开关，那么此时会获取所有 Broker 的路由信息，消息的发送会根据负载算法选择其中一台Broker 发送消息，消息到达 Broker 后，发现本地没有该 Topic，会在创建该 Topic 的信息塞进本地缓存中，同时会将 Topic 路由信息注册到 Nameserver 中，那么这样就会造成一个后果：以后所有该 Topic 的消息，都将发送到这台 Broker 上，如果该 Topic 消息量非常大，会造成某个 Broker 上负载过大，这样的消息存储就达不到负载均衡的效果了。
本文缩略图：icon by 阿猫阿箫
©每周一推
第一时间获得下期分享
☟☟☟
Tips：
# 点下“在看”❤️
# 然后，公众号对话框内发送“草席”，试试手气？?
# 本期奖品是来自淘宝心选的天然草席枕片。
扫一扫
141
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
