文章目录
前面说了 消息在Producer端的发送逻辑。这里结合 Broker端启动过程来说一下。消息在Broker端接收的逻辑。
Broker启动时的准备
之前说的Broker启动逻辑讲到过，Broker启动的时候会创建一个netty服务端NettyRemotingServer。现在在这个的基础上继续说。
Broker启动前初始化时候注册事件
在BrokerController的初始化方法initialize中有一个步骤是注册一些请求事件到创建的NettyRemotingServer中。这个逻辑在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);
/.....省略剩下逻辑...../
}
这里进一步看看对应的registerProcessor方法。其中注册的请求事件就包括了发送消息事件。SEND_MESSAGE（没有经过压缩的消息），SEND_MESSAGE_V2（经过压缩的消息）等，这些消息code的处理器就是SendMessageProcessor
public void registerProcessor(int requestCode, NettyRequestProcessor processor, ExecutorService executor) {
//处理请求的线程池
ExecutorService executorThis = executor;
if (null == executor) {
executorThis = this.publicExecutor;
}
//将请求处理类和对应的请求code放到缓存中
Pair<NettyRequestProcessor, ExecutorService> pair = new Pair<NettyRequestProcessor, ExecutorService>(processor, executorThis);
this.processorTable.put(requestCode, pair);
}
这个方法会把请求code处理器和对应请求code放到processorTable中。而这个processorTable保存在了NettyRemotingServer的父类NettyRemotingAbstract中。这个在后面会用到。
请求接收逻辑
netty请求事件触发
对于netty了解的会知道，netty在外部请求到达的时候都会触发一系列的事件。其中有一个方法就是channelRead0这个方法会在netty的channel收到请求的时候触发。而在NettyRemotingServer中继承了netty内部的指定类型消息触发器SimpleChannelInboundHandler指定了是RemotingCommand类型的请求才会触发。
class NettyServerHandler extends SimpleChannelInboundHandler<RemotingCommand> {
@Override
protected void channelRead0(ChannelHandlerContext ctx, RemotingCommand msg) throws Exception {
//调用父类的实现，其实是一个模板模式
processMessageReceived(ctx, msg);
}
}
可以看到这个会调用父类的processMessageReceived方法。进一步看看父类的这个方法
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;
}
}
}
这里逻辑就是根据请求的命令类型进行不同的处理。有请求和返回类型的处理逻辑。这里要看的是请求类型的。进入processRequestCommand方法。这个方法的逻辑比较长
public void processRequestCommand(final ChannelHandlerContext ctx, final RemotingCommand cmd) {
//根据消息的code，从前面注册的时间码处理器中拿到对应的处理类和线程池
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());
//执行前调用实现了 RPCHook 接口的扩展实现逻辑
doBeforeRpcHooks(remoteAddr, cmd);
//这里是定义处理完请求之后返回处理逻辑
final RemotingResponseCallback callback = new RemotingResponseCallback() {
@Override
public void callback(RemotingCommand 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 {
}
}
}
};
//如果是异步的请求的处理逻辑，使用的是CompletableFuture 来实现的
if (pair.getObject1() instanceof AsyncNettyRequestProcessor) {
AsyncNettyRequestProcessor processor = (AsyncNettyRequestProcessor)pair.getObject1();
processor.asyncProcessRequest(ctx, cmd, callback);
} else {
//同步处理的逻辑
NettyRequestProcessor processor = pair.getObject1();
//调用对应的请求处理器进行处理
RemotingCommand response = processor.processRequest(ctx, cmd);
callback.callback(response);
}
} catch (Throwable e) {
log.error("process request exception", e);
log.error(cmd.toString());
if (!cmd.isOnewayRPC()) {
final RemotingCommand response = RemotingCommand.createResponseCommand(RemotingSysResponseCode.SYSTEM_ERROR,
RemotingHelper.exceptionSimpleDesc(e));
response.setOpaque(opaque);
ctx.writeAndFlush(response);
}
}
}
};
//如果对应的处理逻辑是拒绝，则直接返回系统繁忙
if (pair.getObject1().rejectRequest()) {
final RemotingCommand response = RemotingCommand.createResponseCommand(RemotingSysResponseCode.SYSTEM_BUSY,
"[REJECTREQUEST]system busy, start flow control for a while");
response.setOpaque(opaque);
ctx.writeAndFlush(response);
return;
}
try {
//创建线程任务对象RequestTask实现的是Runnable
final RequestTask requestTask = new RequestTask(run, ctx.channel(), cmd);
//丢到对应的线程池处理
pair.getObject2().submit(requestTask);
} catch (RejectedExecutionException e) {
if ((System.currentTimeMillis() % 10000) == 0) {
log.warn(RemotingHelper.parseChannelRemoteAddr(ctx.channel())
+ ", too many requests and system thread pool busy, RejectedExecutionException "
+ pair.getObject2().toString()
+ " request code: " + cmd.getCode());
}
if (!cmd.isOnewayRPC()) {
final RemotingCommand response = RemotingCommand.createResponseCommand(RemotingSysResponseCode.SYSTEM_BUSY,
"[OVERLOAD]system busy, start flow control for a while");
response.setOpaque(opaque);
ctx.writeAndFlush(response);
}
}
} else {
//如果请求的code码不存在对应的处理逻辑，则直接返回请求码不支持的错误
String error = " request type " + cmd.getCode() + " not supported";
final RemotingCommand response =
RemotingCommand.createResponseCommand(RemotingSysResponseCode.REQUEST_CODE_NOT_SUPPORTED, error);
response.setOpaque(opaque);
ctx.writeAndFlush(response);
log.error(RemotingHelper.parseChannelRemoteAddr(ctx.channel()) + error);
}
}
可以看到，对于外部请求的处理，会使用线程池的方式来进行处理。而处理逻辑会被封装到一个线程中，其中我们关键的点就是这个线程内定义的逻辑，这里分析一下：
- 获取请求来源的服务器地址
- 定义请求处理完毕之后返回信息的回调处理逻辑
- 使用前面根据请求code，从
processorTable（这个在最开始提到过）中获取到的请求处理类，对请求进行处理 - 处理完毕之后调用步骤2定义的回调处理逻辑
而今天要说的消息接收处理逻辑就在上面说的步骤3当中。我们之前说到了在Broker启动之前初始化的时候注册了一些时间，而发送消息的请求事件的处理器是SendMessageProcessor。所以直接进入这个类就是消息接收的处理逻辑。
内部处理逻辑
SendMessageProcessor接收消息的主流程processRequest和asyncProcessRequest
这里直接把内部的主要流程贴出来
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;
}
@Override
public void asyncProcessRequest(ChannelHandlerContext ctx, RemotingCommand request, RemotingResponseCallback responseCallback) throws Exception {
asyncProcessRequest(ctx, request).thenAcceptAsync(responseCallback::callback, this.brokerController.getSendMessageExecutor());
}
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:
//解析请求头
SendMessageRequestHeader requestHeader = parseRequestHeader(request);
if (requestHeader == null) {
return CompletableFuture.completedFuture(null);
}
//根据消息构建消息上下文，消息的各种属性，可以看 SendMessageContext中的属性，这里主要是生产者和broker相关信息
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);
}
}
}
可以看到消息接收处理逻辑是异步化的，这里个人感觉是因为消息量大的时候可能同步逻辑处理会比较慢影响性能所以使用异步的方式。对于整个方法的步骤这里说一下（针对普通消息）。
- 根据消息的类型看是RPC类型的回调消息，还是普通的消息（默认的）
- 解析请求头
- 构建消息上下文，处理消息保存前的回调逻辑
- 根据是否是批量消息，对消息进行处理
请求头的处理parseRequestHeader
parseRequestHeader的方法处理定义在了AbstractSendMessageProcessor中是SendMessageProcessor的父类，主要就是针对Rpc类型和普通消息类型请求的解析，钩子方法处理，返回信息的处理逻辑。这里分析请求头的处理逻辑
protected SendMessageRequestHeader parseRequestHeader(RemotingCommand request)
throws RemotingCommandException {
SendMessageRequestHeaderV2 requestHeaderV2 = null;
SendMessageRequestHeader requestHeader = null;
switch (request.getCode()) {
//发送批量信息的处理逻辑和简短消息的逻辑以及普通消息的最终处理逻辑是一样的
case RequestCode.SEND_BATCH_MESSAGE:
case RequestCode.SEND_MESSAGE_V2:
//对压缩消息进行解码
requestHeaderV2 = decodeSendMessageHeaderV2(request);
case RequestCode.SEND_MESSAGE:
//不是压缩类型消息的处理
if (null == requestHeaderV2) {
requestHeader =
(SendMessageRequestHeader) request
.decodeCommandCustomHeader(SendMessageRequestHeader.class);
} else {
//压缩类型转换为正常类型
requestHeader = SendMessageRequestHeaderV2.createSendMessageRequestHeaderV1(requestHeaderV2);
}
default:
break;
}
return requestHeader;
}
这里对于解码的过程不进行分析，主要说明一说有消息发送请求的解码处理逻辑是一样的，不过对于经过精简的SEND_MESSAGE_V2类型请求会先对精简的信息进行恢复，然后在处理。
最终的接收消息处理逻辑asyncSendMessage
对于批量消息和普通消息，大致的逻辑都是一样的，这里主要对单个消息的处理逻辑来进行分析处理。
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);
}
//获取请求体
final byte[] body = request.getBody();
//消息发送的queueId
int queueIdInt = requestHeader.getQueueId();
//根据Topic获取对应的Topic配置信息
TopicConfig topicConfig = this.brokerController.getTopicConfigManager().selectTopicConfig(requestHeader.getTopic());
if (queueIdInt < 0) {
queueIdInt = randomQueueId(topicConfig.getWriteQueueNums());
}
//消息
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());
//转换请求头重消息的属性到封装的对象中，包含消息的产生时间产生的机器，保存的Broker和重试的时间
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 {
putMessageResult = this.brokerController.getMessageStore().asyncPutMessage(msgInner);
}
//消息保存完的后续处理
return handlePutMessageResultFuture(putMessageResult, response, request, msgInner, responseHeader, mqtraceContext, ctx, queueIdInt);
}
大致的逻辑步骤是这样的
- 先准备返回消息，并获取请求头
- 获取请求体，队列id，从Broker中获取对应topic的配置信息
- 创建Broker端存储消息时候的结构体
- 检查是否是重试消息以及是否进入死信队列的处理逻辑
- 组装其他的消息
- 检查是否是事务消息，如果是交给处理事务消息的逻，如果不是则交给普通的消息保存逻辑
- 保存完消息的后续逻辑
对于整个消息接收的逻辑到这里其实就已经结束了，对于消息的保存逻辑。调用的是前面讲过的DefaultMessageStore的保存方法逻辑和CommitLog的保存逻辑。这些都是串起来的。关于事务消息，和重试消息后面会有博文来进行分析的。
扫一扫
3454
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
