Rocketmq源码解析-Broker部分之消息接收

最新推荐文章于 2024-05-31 14:06:13 发布
最新推荐文章于 2024-05-31 14:06:13 发布
阅读量2.5k 收藏 1
点赞数 1
分类专栏： RocketMq源码 文章标签： 消息队列 中间件 后端 java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u014161463/article/details/122866287
版权

目录

问题点

1.Producer发送消息之后Broker是如何接收？
2.Broker接收消息之后是如何处理的？

broker接收流程图

在这里插入图片描述

消息接收

我们在之前的RocketMQ源码解析-Broker部分之Broker启动过程文章中分析过，broker的启动会调用BrokerStartup.start(),另外rocketmq是采用netty进行底层通信，所以broker也是通过netty接收消息，并进行消息处理。

1.启动入口NettyRemotingServer.start()

其实NettyRemotingServer.start的启动是在BrokerStartup.start()进行调用的。

 public void start() throws Exception {
        if (this.messageStore != null) {
            this.messageStore.start();
        }
	
        if (this.remotingServer != null) {
        	//NettyRemotingServer.start()
            this.remotingServer.start();
        }
}

2.创建NettyServer通信通道

 @Override
    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());
                }
            });

        prepareSharableHandlers();

        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 {
                        ch.pipeline()
                            .addLast(defaultEventExecutorGroup, HANDSHAKE_HANDLER_NAME, handshakeHandler)
                            .addLast(defaultEventExecutorGroup,
                                encoder,
                                new NettyDecoder(),
                                new IdleStateHandler(0, 0, nettyServerConfig.getServerChannelMaxIdleTimeSeconds()),
                                connectionManageHandler,
                                serverHandler
                            );
                    }
                });

        if (nettyServerConfig.isServerPooledByteBufAllocatorEnable()) {
            childHandler.childOption(ChannelOption.ALLOCATOR, PooledByteBufAllocator.DEFAULT);
        }

        try {
            ChannelFuture sync = this.serverBootstrap.bind().sync();
            InetSocketAddress addr = (InetSocketAddress) sync.channel().localAddress();
            this.port = addr.getPort();
        } catch (InterruptedException e1) {
            throw new RuntimeException("this.serverBootstrap.bind().sync() InterruptedException", e1);
        }

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

        this.timer.scheduleAtFixedRate(new TimerTask() {

            @Override
            public void run() {
                try {
                    NettyRemotingServer.this.scanResponseTable();
                } catch (Throwable e) {
                    log.error("scanResponseTable exception", e);
                }
            }
        }, 1000 * 3, 1000);
    }

prepareSharableHandlers

    private void prepareSharableHandlers() {
        handshakeHandler = new HandshakeHandler(TlsSystemConfig.tlsMode);
        encoder = new NettyEncoder();
        connectionManageHandler = new NettyConnectManageHandler();
        serverHandler = new NettyServerHandler();
    }

3.Netty接收核心处理类NettyServerHandler

NettyServerHandler底层实现了Netty框架的ChannelHandler,针对producer端发送过来的消息进行了拦截处理，想深入了解可以自学一下Netty框架，下面我们重点分析一下NettyServerHandler的处理流程。

    @ChannelHandler.Sharable
    class NettyServerHandler extends SimpleChannelInboundHandler<RemotingCommand> {

        @Override
        protected void channelRead0(ChannelHandlerContext ctx, RemotingCommand msg) throws Exception {
        	//处理消息接收
            processMessageReceived(ctx, msg);
        }
    }
    public void processMessageReceived(ChannelHandlerContext ctx, RemotingCommand msg) throws Exception {
        final RemotingCommand cmd = msg;
        if (cmd != null) {
            switch (cmd.getType()) {
            	//处理请求的命令
                case REQUEST_COMMAND:
                    processRequestCommand(ctx, cmd);
                    break;
                case RESPONSE_COMMAND:
                    processResponseCommand(ctx, cmd);
                    break;
                default:
                    break;
            }
        }
    }
3.1 请求处理processRequestCommand

该方法主要是对brokerController.start()时通过registerProcessor注册的事件管理映射对象processTable对应事件的事件处理逻辑

    public void processRequestCommand(final ChannelHandlerContext ctx, final RemotingCommand cmd) {
    	//根据请求code获取事件处理器、线程执行器，这里主要获取SendMessageProcessor
        final Pair<NettyRequestProcessor, ExecutorService> matched = this.processorTable.get(cmd.getCode());
        final Pair<NettyRequestProcessor, ExecutorService> pair = null == matched ? this.defaultRequestProcessor : matched;
        final int opaque = cmd.getOpaque();

        if (pair != null) {
            Runnable run = new Runnable() {
                @Override
                public void run() {
                    try {
                    	//获取远程地址
                        String remoteAddr = RemotingHelper.parseChannelRemoteAddr(ctx.channel());
                        //事前钩子
                        doBeforeRpcHooks(remoteAddr, cmd);
                        final RemotingResponseCallback callback = response -> {
                            doAfterRpcHooks(remoteAddr, cmd, response);
                            if (!cmd.isOnewayRPC()) {
                                if (response != null) {
                                    response.setOpaque(opaque);
                                    response.markResponseType();
                                    try {
                                        ctx.writeAndFlush(response);
                                    } catch (Throwable e) {
                                        log.error("process request over, but response failed", e);
                                        log.error(cmd.toString());
                                        log.error(response.toString());
                                    }
                                } else {
                                }
                            }
                        };
                        if (pair.getObject1() instanceof AsyncNettyRequestProcessor) {
                            AsyncNettyRequestProcessor processor = (AsyncNettyRequestProcessor)pair.getObject1();
                            //异步处理请求
                            processor.asyncProcessRequest(ctx, cmd, callback);
                        } else {
                            NettyRequestProcessor processor = pair.getObject1();
                            //同步处理请求，SendMessageProcessor
                            RemotingCommand response = processor.processRequest(ctx, cmd);
                            callback.callback(response);
                        }
                    } catch (Throwable e) {
                    }
                }
    }
3.2 消息请求处理器SendMessageProcessor
public class SendMessageProcessor extends AbstractSendMessageProcessor implements NettyRequestProcessor {

    @Override
    public RemotingCommand processRequest(ChannelHandlerContext ctx,
                                          RemotingCommand request) throws RemotingCommandException {
        RemotingCommand response = null;
        try {
            response = asyncProcessRequest(ctx, request).get();
        } catch (InterruptedException | ExecutionException e) {
            log.error("process SendMessage error, request : " + request.toString(), e);
        }
        return response;
    }

    public CompletableFuture<RemotingCommand> asyncProcessRequest(ChannelHandlerContext ctx,
                                                                  RemotingCommand request) throws RemotingCommandException {
        final SendMessageContext mqtraceContext;
        switch (request.getCode()) {
            // 消费者发送的重试消息
            case RequestCode.CONSUMER_SEND_MSG_BACK:
                return this.asyncConsumerSendMsgBack(ctx, request);
            // 生产者发送的普通消息
            default:
            	//根据请求组装RequestHeader对象
                SendMessageRequestHeader requestHeader = parseRequestHeader(request);
                if (requestHeader == null) {
                    return CompletableFuture.completedFuture(null);
                }
                mqtraceContext = buildMsgContext(ctx, requestHeader);
                this.executeSendMessageHookBefore(ctx, request, mqtraceContext);
                if (requestHeader.isBatch()) {
               		// 处理批量消息
                    return this.asyncSendBatchMessage(ctx, request, mqtraceContext, requestHeader);
                } else {
                	// 处理单个消息请求
                    return this.asyncSendMessage(ctx, request, mqtraceContext, requestHeader);
                }
        }
    }

我们重点分析一下单条消息的处理逻辑

       private CompletableFuture<RemotingCommand> asyncSendMessage(ChannelHandlerContext ctx, RemotingCommand request,
                                                                SendMessageContext mqtraceContext,
                                                                SendMessageRequestHeader requestHeader) {
		//初始化响应数据
        final RemotingCommand response = preSend(ctx, request, requestHeader);
        final SendMessageResponseHeader responseHeader = (SendMessageResponseHeader)response.readCustomHeader();

        if (response.getCode() != -1) {
            return CompletableFuture.completedFuture(response);
        }
        //获取消息内容body
        final byte[] body = request.getBody();
        //消息发送的队列id
        int queueIdInt = requestHeader.getQueueId();
        //消息发送的topic信息
        TopicConfig topicConfig = this.brokerController.getTopicConfigManager().selectTopicConfig(requestHeader.getTopic());
        //如果队列id<0,随机一个queueId
        if (queueIdInt < 0) {
            queueIdInt = randomQueueId(topicConfig.getWriteQueueNums());
        }
        //封装信息到MessageExtBrokerInner中
        MessageExtBrokerInner msgInner = new MessageExtBrokerInner();
        msgInner.setTopic(requestHeader.getTopic());
        msgInner.setQueueId(queueIdInt);
        //处理重试和死信队列
        if (!handleRetryAndDLQ(requestHeader, response, request, msgInner, topicConfig)) {
            return CompletableFuture.completedFuture(response);
        }

        msgInner.setBody(body);
        msgInner.setFlag(requestHeader.getFlag());
        Map<String, String> origProps = MessageDecoder.string2messageProperties(requestHeader.getProperties());
        MessageAccessor.setProperties(msgInner, origProps);
        msgInner.setBornTimestamp(requestHeader.getBornTimestamp());
        msgInner.setBornHost(ctx.channel().remoteAddress());
        msgInner.setStoreHost(this.getStoreHost());
        msgInner.setReconsumeTimes(requestHeader.getReconsumeTimes() == null ? 0 : requestHeader.getReconsumeTimes());
        String clusterName = this.brokerController.getBrokerConfig().getBrokerClusterName();
        MessageAccessor.putProperty(msgInner, MessageConst.PROPERTY_CLUSTER, clusterName);
        if (origProps.containsKey(MessageConst.PROPERTY_WAIT_STORE_MSG_OK)) {
            // There is no need to store "WAIT=true", remove it from propertiesString to save 9 bytes for each message.
            // It works for most case. In some cases msgInner.setPropertiesString invoked later and replace it.
            String waitStoreMsgOKValue = origProps.remove(MessageConst.PROPERTY_WAIT_STORE_MSG_OK);
            msgInner.setPropertiesString(MessageDecoder.messageProperties2String(msgInner.getProperties()));
            // Reput to properties, since msgInner.isWaitStoreMsgOK() will be invoked later
            origProps.put(MessageConst.PROPERTY_WAIT_STORE_MSG_OK, waitStoreMsgOKValue);
        } else {
            msgInner.setPropertiesString(MessageDecoder.messageProperties2String(msgInner.getProperties()));
        }

        CompletableFuture<PutMessageResult> putMessageResult = null;
        String transFlag = origProps.get(MessageConst.PROPERTY_TRANSACTION_PREPARED);
        //如果是事务消息走事务处理逻辑
        if (transFlag != null && Boolean.parseBoolean(transFlag)) {
        	//是否可以走事务流程
            if (this.brokerController.getBrokerConfig().isRejectTransactionMessage()) {
                response.setCode(ResponseCode.NO_PERMISSION);
                response.setRemark(
                        "the broker[" + this.brokerController.getBrokerConfig().getBrokerIP1()
                                + "] sending transaction message is forbidden");
                return CompletableFuture.completedFuture(response);
            }
            putMessageResult = this.brokerController.getTransactionalMessageService().asyncPrepareMessage(msgInner);
        } else {
            //普通消息则使用MessageStore将消息进行存储
            putMessageResult = this.brokerController.getMessageStore().asyncPutMessage(msgInner);
        }
        return handlePutMessageResultFuture(putMessageResult, response, request, msgInner, responseHeader, mqtraceContext, ctx, queueIdInt);
    }
3.3 消息存储DefaultMessageStore

这里我们简单了解一下消息最终会通过commitLog进行存在，后面将会对消息存储模块进行学习和讲解。

   @Override
    public CompletableFuture<PutMessageResult> asyncPutMessage(MessageExtBrokerInner msg) {
        CompletableFuture<PutMessageResult> putResultFuture = this.commitLog.asyncPutMessage(msg);
        return putResultFuture;
    }

大致总结一下：

  1. 初始化响应数据;
  2. 获取要发送的队列和topic配置，如果queueId<0，则随机选择一个;
  3. 构建消息类；
  4. 处理重试和死信，对RETRY类型的消息处理。如果超过最大消费次数，则topic修改成"%DLQ%" + 分组名，即加入死信队列；
  5. 如果是事务消息，则需要校验是否不允许发送事务消息；
  6. 使用MessageStore组件将消息存储在本地文件，只存储CommitLog文件，ConsumerQueue文件和IndexFile文件会由后台线程异步存储；
  7. 处理消息存储结果
geekolaf
关注
专栏目录
RocketMq源码解析二：NameService篇（启动流程）
money9sun的博客
05-21 255
首先来看一章总体的技术架构图消息中间件的设计思路一般是基于主题订阅发布的机制，消息生产者(Producer)发送某一个主题到消息服务器，消息服务器负责将消息持久化存储，消息消费者(Consumer)订阅该兴趣的主题，消息服务器根据订阅信息(路由信息)将消息推送到消费者(Push模式)或者消费者主动向消息服务器拉去(Pu模式)，从而实现消息生产者与消息消费者解耦。为了避免消息服务器的单点故障导致的整个系统瘫痪，通常会部署多台消息服务器共同承担消息的存储。那消息生产者如何知道消息要发送到哪台消息服务器呢?
03 RocketMQ - Broker 源码分析
刘元雄
09-02 781
03 RocketMQ - Broker 源码分析
RocketMQ(七)broker接收消息入口源码
djdjdxieuej的博客
01-05 538
本次我们梳理了broker接收消息源码入口的处理逻辑，可以看到最终是通过调用sendMessage方法来处理来自producer发送的消息的。sendMessage方法内部要做的事情就比较多，保罗存储消息、构建索引、分发消费等等，这部分下次再总结。(32条消息) RocketMQ源码(9)—Broker接收消息入口源码_刘Java的博客-CSDN博客_rocketmq registerprocessor。
RocketMq broker源码解析
最新发布
anglybaby的博客
05-31 241
broker 集群工作流程 NameSrv启动成功后，等待broker、Consumer和producer启动后也与NameSrv保持长连接, NameSrv相当于是路由控制中心。 启动broker, broker与所有的NameSrv建立长连接, broker，通过定时线程定时向NameSrv发送心跳，broker信息注册到所有的NameSrv上, 包含brokerName、brokerAddr、clusterName等由nameSrv去保存。 producer启动时，先随机选择Namesrv集群中的某
rocketmq-broker源码分析
weixin_40455124的博客
06-07 518
Rocketmq broker： master之间没有任何数据同步 启动时候会读取定时保存的信息，包括topicconfig、message等 数据保存主要由属性storePathRootDir及storePathCommitLog指定 4.5 增加了一个fastserver，用途还没有发现 可以通过使用已经存在的broker配置为基础、进行少量调整启动新broker topic config保...
源码解析-RocketMQ-broker
weixin_43924484的博客
05-11 214
源码解析-RocketMQ-broker
rocketmq-externals-master.zip
12-04
- 生产者将消息发送到指定的Broker，Broker接收到消息后存储到Message Store。 - 消费者向NameServer请求主题和队列的 Broker 地址。 - 消费者从Broker拉取或接收消息，处理后确认消费。 4. **源码解析关键点** ...
rocketmq源码解析-nameserver和broker的启动
cblstc的博客
06-27 660
文章目录准备创建rocketmq工作目录编译运行NameServer运行brokerNameServer启动流程创建NameServer Controller开启NameServer初始化NamesrvController定期移除不活跃的broker重新维护路由表调用NamesrvController#startbroker启动流程创建BrokerControllerBrokerConfigMessageStoreConfigBrokerController#initializeBroker开启broker
RocketMQ源码9- broker 启动流程
BASK2311的博客
03-23 588
本文主要分析了broker解析配置文件，这一步会解析各种配置，并将其赋值到对应的对象中创建及初始化：创建了对象，并进行初始化操作，所谓的初始化，就是加载配置文件中配置、创建线程池、注册请求处理器、启动定时任务等启动：这一步是启动broker的核心组件，如(消息存储)、netty服务，用来处理producer与consumer请求)、netty服务，用来向nameServer上报当前broker信息)等。在分析启动过程中，重点分析了两类消息的发送：在中，broker会向nameServer。
rocketmq-broker接受消息流程
chenglang4020的博客
06-30 339
MessageExtBrokerInner 要存入commitLog的数据 转载于:https://my.oschina.net/penghaozhong/blog/3067802...
RocketMQ源码解析四（Broker接收以及存储消息）
指尖凉的博客
09-28 324
接收请求的入口已经在上篇分析过了，所以这里直接看处理器如何处理请求。
RocketMq源码分析-Broker
孤海岛主
03-23 2303
Broker源码解析： 启动流程: BrokerStartup main(): start(BrokerController controller=createBrokerController(args)): createBrokerController: 1:是否指定了netty通信时缓冲区的大小，若未指定初始化为128K 2：解析命令行参数，加载-C参数文件中指定的配置信息，防止丢失这里记录.
RocketMQ 消息接受流程
CoderChronicle的博客
12-29 1326
基于 RocketMQ 4.2.0 版本进行的源码分析。本篇讲述 RocketMQ 消息接受流程。
RocketMQ集群
qq_45181415的博客
03-28 473
RocketMQ 1. 集群 单机 一个broker提供服务（宕机后瘫痪） 集群 多个broker提供服务（单机宕机后消息无法及时被消费） 多个master多个slave master到slave消息同步方式为同步（较异步方式性能略低，消息无延迟） master到slave消息同步方式为异步（较同步方式性能略高，数据略有延迟） 1.1 集群特征 NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。 Broker部署相对复杂，Broker分为Master与Sl
RocketMQ：深入理解Broker如何接收Producer生产消息请求？
健身变秃，coding变强
11-04 752
一、前言 今天原打算写一篇关于消息在Broker端如何存储的文档，刚梳理好整体文章脉络，想到一个问题：Broker端是如何接收生产消息请求的？印象中是通过Netty接收的，由于对具体的实现比较好奇，也就有了今天的故事。 二、源码分析 以下所有分析相关的源码注释请见GitHub中的release-4.8.0分支：https://github.com/Saint9768/rocketmq/tree/rocketmq-all-4.8.0 1、RemotingServer消息生产/消费服务启动 又要开始快乐的找入
7、RocketMQ 源码解析之 Broker 启动(下)
carl.zhao的专栏
04-03 818
在前面的一篇文章 -- [6、RocketMQ 源码解析之 Broker 启动(上)，分析了一下 Broker 在启动的时候他自身做了哪些事，以及把 Broker 相关的信息注册到 NameServer 中去，下面我们就通过 Broker 把元信息注册到 NameServer 来了解一下 RocketMQ 是如何进行网络间通信的。
RocketMQ事务消息
04-07 733
Apache RocketMQ在4.3.0版中已经支持分布式事务消息，这里RocketMQ采用了2PC的思想来实现了提交事务消息，同时增加一个补偿逻辑来处理二阶段超时或者失败的消息，如下图所示。 RocketMQ事务消息流程概要 上图说明了事务消息的大致方案，其中分为两个流程：正常事务消息的发送及提交、事务消息的补偿流程。 事务消息发送及提交： (1) 发...
rocketmq学习笔记 ---- NettyRemotingServer和NettyRemotingClient
wenyuan65的博客
03-17 2428
Netty是目前java最流行的网络框架，RocketMQ也使用Netty作为网络通讯底层框架。 NettyRemotingServer实现Netty服务器端功能，接受数据包，在服务器端处理后发送给客户端。NettyRemotingClient实现Netty客户端功能。 NettyRemotingServer 1.start() 方法 start方法主要启动Netty服务器，并在绑定端...
无微不至之RocketMq源码深度讲解(2)-架构分析
小青蛙课堂
09-18 427
源码地址:https://github.com/apache/rocketmq 基于版本讲解：4.7.1 此内容引用官方介绍 RocketMQ架构上主要分为四部分，如上图所示: Producer：消息发布的角色，支持分布式集群方式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。 Consumer：消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费
RocketMQ Broker接收入站消息处理深度解析
"RocketMQ Broker接收到生产者发送消息的过程主要涉及网络通信、请求处理、存储和同步机制。以下是对这一流程的详细说明： 在RocketMQ中，生产者向Broker发送消息时，整个流程大致分为以下几个步骤： 1. **网络...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值