RocketMQ源码解析——Broker部分之Broker启动过程BrokerStartup(2)

最新推荐文章于 2024-01-29 16:07:38 发布
最新推荐文章于 2024-01-29 16:07:38 发布
阅读量326 收藏
点赞数
分类专栏： RocketMq源码 文章标签： 消息队列
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/szhlcy/article/details/118916887
版权

文章目录


 前面说了Broker端的部分启动逻辑中的， 启动前的准备部分。知道了启动类是 BrokerStartup，其中启动前的准备逻辑主要是通过 BrokerController来进行处理的。接下来继续分析，后面的启动部分的逻辑

启动初始化完毕的服务的start

 启动的入口还是在BrokerStartup，然后通过BrokerController来完成。

public static void main(String[] args) {
        //创建createBrokerController然后启动
        start(createBrokerController(args));
    }

    public static BrokerController start(BrokerController controller) {
        try {
        	//启动controller
            controller.start();
           //日志打印相关
        		.......
            return controller;
        } catch (Throwable e) {
            e.printStackTrace();
            System.exit(-1);
        }

        return null;
    }

 主要的逻辑还是在BrokerController中，这里的逻辑其实就是对前面的初始化时候的一些服务类的启动

public void start() throws Exception {
		//启动消息存储相关的线程任务
        if (this.messageStore != null) {
            this.messageStore.start();
        }
        //启动broker服务端
        if (this.remotingServer != null) {
            this.remotingServer.start();
        }
        //启动只给 消息的生产者使用的netty服务端口
        if (this.fastRemotingServer != null) {
            this.fastRemotingServer.start();
        }
        //启动监控SSL连接文件的服务
        if (this.fileWatchService != null) {
            this.fileWatchService.start();
        }
        //启动外部API的客户端
        if (this.brokerOuterAPI != null) {
            this.brokerOuterAPI.start();
        }
        //启动push模式相关的服务
        if (this.pullRequestHoldService != null) {
            this.pullRequestHoldService.start();
        }
        //启动心跳连接的服务
        if (this.clientHousekeepingService != null) {
            this.clientHousekeepingService.start();
        }
        //启动消息过滤服务
        if (this.filterServerManager != null) {
            this.filterServerManager.start();
        }
        //如果没启动DLegerCommitLog ，就对Broker进行注册到NameServer上
        if (!messageStoreConfig.isEnableDLegerCommitLog()) {
        	//如果是Master则启动事务消息检查的线程，对应的类就是TransactionalMessageCheckService
            startProcessorByHa(messageStoreConfig.getBrokerRole());
            handleSlaveSynchronize(messageStoreConfig.getBrokerRole());
            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);
        //状态管理的开启
        if (this.brokerStatsManager != null) {
            this.brokerStatsManager.start();
        }

        if (this.brokerFastFailure != null) {
            this.brokerFastFailure.start();
        }


    }

 这里的逻辑其实还是一目了然的。同时也是比较重要的部分。这里对这几个内部的服务类进行分析。其中messageStore这个变量就是DefaultMessageStore这个类，start方法就是其内的方法，这里不进行分析，前面已经有专门文章分析过了查看可以点击传送门。可以看前面，继续后面的分析。对这几个服务进行说明一下

服务类实现类说明
messageStoreDefaultMessageStore处理消息的存储相关的日志，比如CommitLog，ConsumeQueue等
remotingServerRemotingServerBroker的服务端，处理消费者和生产者的请求
fastRemotingServerRemotingServer只给消息生产者的服务端
fileWatchServiceFileWatchService启动监控服务连接时用到的SSL连接文件的服务
brokerOuterAPIBrokerOuterAPIRocketMQ控制台跟Broker交互时候的客户端
pullRequestHoldServicePullRequestHoldService处理push模式消费，或者延迟消费的服务
clientHousekeepingServiceClientHousekeepingService心跳连接用的服务
filterServerManagerFilterServerManager消息过来用的服务
transactionalMessageCheckServiceTransactionalMessageCheckService定期检查和处理事务消息的服务
slaveSynchronizeSlaveSynchronize主从之间topic，消费便宜等信息同步用的

Broker相关服务的启动

 在介绍这些启动服务之前，先说一下BrokerController内部的一个注册事件到不同服务端口的方法registerProcessor

public void registerProcessor() {
        /**
         * SendMessageProcessor
         */
        SendMessageProcessor sendProcessor = new SendMessageProcessor(this);
        //注册消息发送的钩子方法
        sendProcessor.registerSendMessageHook(sendMessageHookList);
        //注册消费消息的钩子方法
        sendProcessor.registerConsumeMessageHook(consumeMessageHookList);
        //在对应的服务端注册对应的事件。
        this.remotingServer.registerProcessor(RequestCode.SEND_MESSAGE, sendProcessor, this.sendMessageExecutor);
        this.remotingServer.registerProcessor(RequestCode.SEND_MESSAGE_V2, sendProcessor, this.sendMessageExecutor);
        this.remotingServer.registerProcessor(RequestCode.SEND_BATCH_MESSAGE, sendProcessor, this.sendMessageExecutor);
        this.remotingServer.registerProcessor(RequestCode.CONSUMER_SEND_MSG_BACK, sendProcessor, this.sendMessageExecutor);
        this.fastRemotingServer.registerProcessor(RequestCode.SEND_MESSAGE, sendProcessor, this.sendMessageExecutor);
        this.fastRemotingServer.registerProcessor(RequestCode.SEND_MESSAGE_V2, sendProcessor, this.sendMessageExecutor);
        this.fastRemotingServer.registerProcessor(RequestCode.SEND_BATCH_MESSAGE, sendProcessor, this.sendMessageExecutor);
        this.fastRemotingServer.registerProcessor(RequestCode.CONSUMER_SEND_MSG_BACK, sendProcessor, this.sendMessageExecutor);
        /**
         * PullMessageProcessor
         */
        //拉取请求的事件
        this.remotingServer.registerProcessor(RequestCode.PULL_MESSAGE, this.pullMessageProcessor, this.pullMessageExecutor);
		//注册消息的事件
        this.pullMessageProcessor.registerConsumeMessageHook(consumeMessageHookList);

        /**
         * ReplyMessageProcessor
         */
        //再次拉取消息
        ReplyMessageProcessor replyMessageProcessor = new ReplyMessageProcessor(this);
        replyMessageProcessor.registerSendMessageHook(sendMessageHookList);

        this.remotingServer.registerProcessor(RequestCode.SEND_REPLY_MESSAGE, replyMessageProcessor, replyMessageExecutor);
        this.remotingServer.registerProcessor(RequestCode.SEND_REPLY_MESSAGE_V2, replyMessageProcessor, replyMessageExecutor);
        this.fastRemotingServer.registerProcessor(RequestCode.SEND_REPLY_MESSAGE, replyMessageProcessor, replyMessageExecutor);
        this.fastRemotingServer.registerProcessor(RequestCode.SEND_REPLY_MESSAGE_V2, replyMessageProcessor, replyMessageExecutor);
  			....
        //注册其他的事件到不同的端
}

 列举一下不同的端注册的一些事件。这里主要对两个端口的服务进行注册，一个是消费者和生产者都使用的端口10911对应remotingServer,另外一个是消息的生产者专用的10909端口对应fastRemotingServer。

服务端事件code码描述
remotingServerSEND_MESSAGE10生产者发送信息
remotingServerSEND_MESSAGE_V2310生产者发送信息
remotingServerSEND_BATCH_MESSAGE320批量发送消息
remotingServerCONSUMER_SEND_MSG_BACK36消费端消费失败的时候返回的消息
remotingServerPULL_MESSAGE11消费者拉取消息
remotingServerSEND_REPLY_MESSAGE324消费者回包消息，可以用类似RPC调用

其中还有很多别的事件，这里就不列举了。注册的这些事件会被保存到一个Map结构中，并与当前的netty服务绑定。

Broker服务的正式启动

 remotingServer是Broker的对消费者和生产者的一个服务。这个服务的启动就代表Broker的启动。而remotingServer的实例对象是NettyRemotingServer类，这个类的作用就是对netty的进一步的封装处理类。直接看start方法。

public void start() {
    	//创建处理事件的线程组
        this.defaultEventExecutorGroup = new DefaultEventExecutorGroup(
            nettyServerConfig.getServerWorkerThreads(),
            new ThreadFactory() {

                private AtomicInteger threadIndex = new AtomicInteger(0);

                @Override
                public Thread newThread(Runnable r) {
                    return new Thread(r, "NettyServerCodecThread_" + this.threadIndex.incrementAndGet());
                }
            });
		/**
		 *	初始换服务连接相关的处理类，其中有针对握手时候模式（TSL）的一些处理逻辑，连接建立和其他事件的一些监听处理逻辑
		 *  HandshakeHandler 用于处理跟Broker建立连接时候的连接模式
		 * 	NettyConnectManageHandler 用于监听连接的一些事件，比如连接建立，断开等，会触发对应的监听器
		 * 	NettyEncoder 解码用的处理器
		 * 	NettyServerHandler 处理请求到达时候根据不同的请求code，进行分发的逻辑
		 */
        prepareSharableHandlers();
        //创建netty客户端,启动主从线程组是在类创建时候初始化的。
        ServerBootstrap childHandler =
            this.serverBootstrap.group(this.eventLoopGroupBoss, this.eventLoopGroupSelector)
                .channel(useEpoll() ? EpollServerSocketChannel.class : NioServerSocketChannel.class)
                .option(ChannelOption.SO_BACKLOG, 1024)
                .option(ChannelOption.SO_REUSEADDR, true)
                .option(ChannelOption.SO_KEEPALIVE, false)
                .childOption(ChannelOption.TCP_NODELAY, true)
                .childOption(ChannelOption.SO_SNDBUF, nettyServerConfig.getServerSocketSndBufSize())
                .childOption(ChannelOption.SO_RCVBUF, nettyServerConfig.getServerSocketRcvBufSize())
                .localAddress(new InetSocketAddress(this.nettyServerConfig.getListenPort()))
                .childHandler(new ChannelInitializer<SocketChannel>() {
                    @Override
                    public void initChannel(SocketChannel ch) throws Exception {
                    	//把握手的处理器加到netty的pipeline序列中
                        ch.pipeline()
                            .addLast(defaultEventExecutorGroup, HANDSHAKE_HANDLER_NAME, handshakeHandler)
								//把解码处理器，连接监听处理器，请求code处理器加到序列中
                            .addLast(defaultEventExecutorGroup,
                                encoder,
                                new NettyDecoder(),
                                new IdleStateHandler(0, 0, nettyServerConfig.getServerChannelMaxIdleTimeSeconds()),
                                connectionManageHandler,
                                serverHandler
                            );
                    }
                });

      	.......
    }

 可以看到这里的主要的逻辑

  1. 创建netty客户端，
  2. 然后初始化一些处理器
  3. 把处理器加到netty中然后启动

这里对于netty部分的不进行讲解，可以自行在网上查找资料。这里对几个处理器进行说明一下

szhlcy
关注
专栏目录
RocketMq源码解析一：源码结构介绍
money9sun的博客
05-21 210
从本章开始我们对Rocketmq的源码进行解析。使用版本是4.9.8。
RocketMQ源码：Broker启动过程介绍
qq_28834355的博客
11-04 385
1. 简介 Broker 启动入口是 BrokerStartup.java => main() ，跟上一篇讲的 NameSrv 类似，首先会从启动命令判断 -c 参数，读取自定义配置文件。然后创建 BrokerController 对象，负责初始化和启动操作。 Broker 主要配置类有3个： BrokerConfig：Broker相关的配置参数 NettyServerConfig：Netty服务端配置，默认端口号10911。NameSrv 也有这个配置，默认端口9876 NettyClientCo
案例分享——巧用方法排查Broker启动失败原因
kafka_zsxq的博客
12-08 2033
【背景】 业务同学通过公司内部的Kafka管控平台进行Topic创建完成之后,发现Topic命令不规范,再次通过Kafka管控平台进行Topic删除操作,恰好这时负责Kafka集群运维的同学对某台Broker进行了重启操作,这是很常规的运维操作理论上没有问题,但Broker启动失败了并抛出java.lang.StringIndexOutOfBoundsException: String index out of ra...
【问题记录】celery启动报错
tyty2211的博客
01-04 1491
添加配置 ：BROKER_CONNECTION_RETRY_ON_STARTUP=True。
Celery介绍与使用
qq_44623314的博客
06-19 1286
Celery是一个功能完备即插即用的任务队列。它使得我们不需要考虑复杂的问题，使用非常简单。celery看起来似乎很庞大，本章节我们先对其进行简单的了解，然后再去学习其他一些高级特性。celery适用异步处理问题，当发送邮件、或者文件上传, 图像处理等等一些比较耗时的操作，我们可将其异步执行，这样用户不需要等待很久，提高用户体验。celery的特点是：* 简单，易于使用和维护，有丰富的文档。* 高效，单个celery进程每分钟可以处理数百万个任务。
【Celery】异步任务框架入门使用
最新发布
Orangesir的博客
01-29 1224
Celery 是一个强大的分布式任务队列系统，它允许你将工作以异步的方式排队执行，这对于执行耗时的后台作业是非常有用的。它使用分布的消息传递来处理分布式系统之间的通信，并支持多种消息中间件作为传输，比如 RabbitMQ, Redis, Amazon SQS, Kafka 等等。Celery 泛用性很强，它不仅可以用于Web应用程序，也适用于其他各种系统。在Web开发中，Celery 常与Django这样的Web框架一起使用，用于处理后台任务，如发送电子邮件、处理大量数据、定时任务等。
django celery 记录
abc
07-03 1232
django celery 记录。
消息中间件 RocketMQ 源码解析 —— 调试环境搭建
芋艿V
01-26 568
摘要: 原创出处 http://www.iocoder.cn/RocketMQ/build-debugging-environment/ 「芋道源码」欢迎转载，保留摘要，谢谢！ 0. 友情提示 1. 依赖工具 2. 源码拉取 3. 启动 RocketMQ Namesrv 4. 启动 RocketMQ Broker 5. 启动 RocketMQ Producer 6. 启动 RocketMQ Co...
RocketMQ 顺序消息解析——图解、源码级解析
如切如磋，如琢如磨
07-30 3315
优秀的程序员不应该只是CRUD
03 RocketMQ - Broker 源码分析
刘元雄
09-02 791
03 RocketMQ - Broker 源码分析
Pycharm中配置Celery启动
他的博客
09-13 559
执行就行，实际上就是在项目目录FerDemo下执行了 celery - A celery_demo.tasks worker -l INFO。Pycharm中配置Celery启动。
Celery连接rabbitmq出现billiard.exceptions.RestartFreqExceeded: 5 in 1s，解决方案
NQ31
08-04 1966
Celery连接rabbitmq问题ConnectionResetError: [Errno 104] Connection reset by peer解决方法
python celery应用场景_python之celery使用详解一
weixin_39747615的博客
12-11 1083
前言前段时间需要使用rabbitmq做写缓存，一直使用pika+rabbitmq的组合，pika这个模块虽然可以很直观地操作rabbitmq，但是官方给的例子太简单，对其底层原理了解又不是很深，遇到很多坑，尤其是需要自己写连接池管理和channel池管理。虽然也有用过celery，一直也是celery+redis的组合，涉及很浅；目前打算深研一下celery+redis+rabbitmq的使用。c...
RocketMQ源码解析——Broker部分之Broker启动过程BrokerStartup(1)
szhlcy的博客
07-19 628
文章目录从启动脚本到启动类启动类`BrokerStartup`创建前的准备工作`createBrokerController` 从启动脚本到启动类  我们知道RocketMQ的Broker端的启动方式为，进入到RocketMQ的bin目录下，运行对应的mqbroker脚本。  RocketMQ的Linux和Windows脚本内容也就是对应的mqbroker脚本，这里贴出来看看 .......省略部分脚本 export ROCKETMQ_HOME sh ${ROCKETMQ_HOME}/bin/runbro
RocketMq——BrokerStartup启动流程以及注册broker至Namesrv
luoxiaomei999的博客
05-13 724
RocketMq——BrokerStartup启动流程以及注册broker至Namesrv 1、创建controller 2、进入BrokerController构造方法 3、 controller.initialize();
RocketMQ(七)broker接收消息入口源码
djdjdxieuej的博客
01-05 553
本次我们梳理了broker接收消息源码入口的处理逻辑，可以看到最终是通过调用sendMessage方法来处理来自producer发送的消息的。sendMessage方法内部要做的事情就比较多，保罗存储消息、构建索引、分发消费等等，这部分下次再总结。(32条消息) RocketMQ源码(9)—Broker接收消息入口源码_刘Java的博客-CSDN博客_rocketmq registerprocessor。
rocketmq 初探（五）
烤鸭的世界我们不懂的博客
10-11 302
大家好，我是烤鸭：     上一篇简单介绍部分 NettyRequestProcessor (AdminBrokerProcessor、ClientManageProcessor、ConsumerManageProcessor、EndTransactionProcessor)，这一篇介绍其他的。 PullMessageProcessor、QueryMessageProcessor、ReplyMessageProcessor、SendMessageProcessor N
SendMessageProcessor源码分析
cjdjcdj的博客
04-25 946
引用
从源码分析RocketMQ系列-消息拉取PullMessageProcessor详解
初学者
04-09 7634
导语   在之前的分析中分析了关于SendMessageProcessor，并且提供了对应的源码分析分析对于消息持久化的问题，下面来看另外一个PullMessageProcessor，在RocketMQ中比较重要的一个概念就是消息拉取，这个类就是表示消息的拉取操作。也是继承了NettyRequestProcessor 接口并且实现了其中的RemotingCommand processReques...
bat脚本判断rocketmq的namesrv和broker是否启动
06-07
可以使用以下的bat脚本来检查RocketMQ的namesrv和broker是否启动： ``` @echo off set NAMESRV=localhost:9876 set BROKER=localhost:10911 echo Checking RocketMQ Namesrv... netstat -ano | findstr %NAMESRV% | findstr /i "listening" >nul if %errorlevel%==0 ( echo RocketMQ Namesrv is running. ) else ( echo RocketMQ Namesrv is not running. ) echo Checking RocketMQ Broker... netstat -ano | findstr %BROKER% | findstr /i "listening" >nul if %errorlevel%==0 ( echo RocketMQ Broker is running. ) else ( echo RocketMQ Broker is not running. ) ``` 在脚本中，通过netstat命令检查名为%NAMESRV%和%BROKER%的进程是否在监听状态，如果进程在监听状态则代表进程已经启动。如果进程没有在监听状态，则代表进程没有启动。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值