chudaxiakkk的专栏

这只是启动过程中的内容。预计运行过程中，还会有其他任务。根据上面的分析，可以清晰看到rocketmq。

默认情况下：eventLoopGroupBoss线程池1个线程，负责channel的链接eventLoopGroupSelector线程池3个线程，负责IO处理defaultEventExecutorGroup线程池8个线程，负责请求的RemotingCommand编解码NettyRequestProcessor绑定的ExecutorService，默认8个线程，负责处理RemotingCommand的业务处理证据如下。以下是nameServer的启动线程截图。

查看上图，关键点，在于rocketmq.client.name的配置。默认是DEFAULT，会导致倍数增长。修改后，所有group会共用同一个MQClientInstance。当一个client，订阅多个consumergroup、多个productgroup时。事实上，rocketmq的client端，默认就是倍数增长的。如果没去关注，那么可能就出现程序响应迟钝了。假设订阅2个consumergroup， 线程数量是2倍增加吗？订阅多个，那线程增长就恐怖了。消费者组，是有多个线程去共同协作的。

1、将producerGroup注册到org.apache.rocketmq.client.impl.factory.MQClientInstance#producerTable变量上。3、启动定时器任务RequestHouseKeepingService1处理响应超时的消息。2、启动定时器任务现成MQClientFactoryScheduledThread。比较简单，不做详细分析了。使用arthas如下。

往topicQueueTable，将注册的brokerName，master节点的topic信息上报到nameserver。前一篇文章，介绍nameserver启动流程，会谈到。包含的brokerName，没有的话，就添加上去。第二步，是检查brokerName的主从节点。第三步，当brokerName的主节点(brokerId = 0)注册时，请求体包含topic信息，更新。前面的步骤没有说，是因为暂时不清楚作用。往brokerAddrTable，相同brokerName情况下，添加主从的信息。

RouteInfoManager内存中，有几个成员变量map，管理topic、broker、心跳等。product、consumer、broker的rpc请求，都会进入该方法。我用的版本是4.9.8，namesrv模块，只有6个文件。这张图，描述了启动的执行流程和定时任务。功能也就意味着比较少。启动流程比较简单，不做详细分析了。使用arthas分析。

代码如下。

后续有空再总结。主要是比较push和pull模式。

初始的拉取请求，来源于重平衡线程RebalanceService创建的PullRequest。这里解析下PullRequest的业务含义。比如有一个topic叫TopicAAA,它在3个broker上分别有4个读队列，意味着这个topic下有12个队列。保存在RebalanceImpl的成员变量ConcurrentMap> topicSubscribeInfoTable。假设消费者组有4个client组成。

首先启动时，会从nameserver获取topic的所有queue。这些queue分布在多个broker上。构建了mqSet。再随机从一个broker上，获取当前消费者组，包含的所有消费者List cidAll。将两者排序，根据分配策略，分配当前消费者负责的队列。（比如总共12个队列，4个消费者。当前消费者，负责 4,5,6队列）。如此看，是客户端重平衡。通过排序然后策略分配的方式，实现消费者互不通信的条件下协同合作。启动时，内存都是空，所以会触发构建PullRequest请求体。

我是从github上fork后下载到本地。使用idea启动nameSrv和broker。注意使用spring-boot 3.x版本后，jdk必须要17以上。所以本地需要安装jdk17。rocketMq我用的是最新的4.X版本4.9.8。版本信息是如何选择的呢？看rocketMq官网。新增application.yml文件。启动就可以看到如下，正常的生产和消费。使用spring-boot的初始化。创建工程并下载放到父工程子目录下。