rocketmq源码分析2-broker的消息接收

broker消息接收,假设接收的是一个普通消息(即没有事务),此处分析也只分析master上动作逻辑,不涉及ha。

1. 如何找到消息接收处理入口

可以通过broker的监听端口10911顺藤摸瓜式的找到 NettyClientConfig.setListenPort-->BrokerStartup-->BrokerController-->NettyRemotingServer
com.alibaba.rocketmq.remoting.netty.NettyDecoder com.alibaba.rocketmq.remoting.netty.NettyRemotingServer.NettyServerHandler.channelRead0(ChannelHandlerContext, RemotingCommand)

也可以顺着broker的启动脚本找到
BrokerStartup-->BrokerController-->NettyRemotingServer

因为rocketmq连接层默认使用netty开发,如果熟悉netty的话,
可以直接查找ChannelInitializer或者pipeline().addLast等

2. 调试NettyDecoder

com.alibaba.rocketmq.remoting.netty.NettyDecoder.decode(ChannelHandlerContext, ByteBuf)
会调用RemotingCommand.decode(byteBuffer)组装RemotingCommand
在com.alibaba.rocketmq.remoting.protocol.RemotingCommand.decode(ByteBuffer) 中断点 排除如下code

 cmd.getCode() != 0 && cmd.getCode() != 34 && cmd.getCode() != 15
&& cmd.getCode() != 38 && cmd.getCode() != 11

用producer的client发一条消息到broker
发现RemotingCommand.decode解析出来的RemotingCommand的code为310 310对应RequestCode.SEND_MESSAGE_V2 发送消息

此时处理线程是:Thread [NettyServerWorkerThread_2]
RemotingCommand主要描述了操作code、opaque号、body即消息体。

3. 调试NettyServerHandler

对com.alibaba.rocketmq.remoting.netty.NettyRemotingServer.NettyServerHandler.channelRead0(ChannelHandlerContext, RemotingCommand)断点
断点条件属性是msg.getCode() == 310
此时处理线程是:Thread [NettyServerWorkerThread_2]

4. NettyRemotingAbstract

com.alibaba.rocketmq.remoting.netty.NettyRemotingAbstract.processRequestCommand(ChannelHandlerContext, RemotingCommand)
方法负责分发给相应的NettyRequestProcessor实例
负责处理的是com.alibaba.rocketmq.broker.processor.SendMessageProcessor@17fb0278
处理线程是:Thread [SendMessageThread_1],跟上面的处理已经不在一个线程上了,异步

5. SendMessageProcessor

SendMessageProcessor.processRequest(ChannelHandlerContext, RemotingCommand)介入处理
构建SendMessageRequestHeader
进入SendMessageProcessor.sendMessage(ChannelHandlerContext, RemotingCommand, SendMessageContext, SendMessageRequestHeader)
int queueIdInt = requestHeader.getQueueId(); 作用是什么 什么时候确定的id
构建MessageExtBrokerInner实例 tags转tagsCode 就是tags的String的hashcode

PutMessageResult putMessageResult = this.brokerController.getMessageStore().putMessage(msgInner);

交给MessageStore进行put(store,进行存放)

6. DefaultMessageStore

com.alibaba.rocketmq.store.DefaultMessageStore.putMessage(MessageExtBrokerInner) 消息topic的长度校验 不能超过127
消息properties转成字符串后,长度不能超过32767
下面交个CommitLog进行putMessage

7. CommitLog

com.alibaba.rocketmq.store.CommitLog.putMessage(MessageExtBrokerInner)
设置存储时间
设置消息体CRC校验值
交给MapedFile进行存储mapedFile.appendMessage(msg, this.appendMessageCallback)

8. MapedFile

mapedFile.appendMessage(msg, this.appendMessageCallback)
获取当前文件已经写到什么位置了
文件已经做了map map到mappedByteBuffer 讲当前的mappedByteBuffer 割出来并设置position为当前写位置
交由callback做append
callback是CommitLog$DefaultAppendMessageCallback
传给callback的参数有

  • 1. 这个文件的offset,意思是:一个broker要存储很多消息,那么一个文件肯定不够存,当存到第二个文件的时候,这个文件里的第一条消息相对于整个broker中的消息有个offset,此值是文件名。
  • 2. 从store文件映射的buffer中割出来的byteBuffer
  • 3. 文件的剩余空间
  • 4. 消息体

8.1 callback中append逻辑:

计算wroteOffset 即整个broker中的offset, 代码注释中称之为物理offset,计算逻辑也很简单即上面参数1+这条消息在这个文件中的position
计算消息id,逻辑使用主机物理IP加上一步的wroteOffset计算,用了ByteBuffer处理,比较高效,待完善验证用例。
获取这个topic的这个队列的offset(一个topic写多个队列),这个offset有啥用?估计是用于快速查找
将消息bean对象用msgStoreItemMemory进行以约定消息体的形式进行byte的put
将msgStoreItemMemory put到上面传进来的参数2的buffer 即写入磁盘
构建append结果,没啥逻辑,主要是一些信息 AppendMessageResult
将消息在这个队列中的offset加1
更新MapedFile的wrotePostion,就是将原来的wrotePostion加上这次写入的字节数
此时订阅断已经收到消息,(应该更早,待确认,待分析消息如何送到consume的)

8.2 回CommitLog--:

构建 PutMessageResult对象。

8.3 处理同异步刷盘逻辑

同步刷盘 用GroupCommitService, 其中使用了多条消息一起刷的设计,并且设计了刷盘如果超时的异常场景的反馈
异步刷盘 用CommitLog$FlushRealTimeService(是一个线程,此时会叫醒他)

8.4 处理主从双机同异步同步逻辑

同步形式同步从节点 交由HAService 实时同步,并等待同步结果。
异步不用管。

9. 收集统计数据

耗时等等

10. 对非oneway的消息做response处理

上一篇:RocketMQ 源码学习笔记————Producer 是怎么将消息发送至 Broker 的?


下一篇:Centos搭建Python+Nginx+Tornado+Mysql环境