RocketMQ中角色有Producer、Comsumer、Broker和NameServer，它们之间的通讯是通过Netty实现的。在之前的文章RocketMQ是如何通讯的?中，对RocketMQt通讯进行了一些介绍，但是底层Netty的细节涉及的比较少，这一篇将作为其中的一个补充。
编码
在RocketMQ中，消息的编解码都在NettyEncoder和NettyDecoder中处理了，如下所示：
编码的操作很简单，返回报文中，body本身已经在业务处理过程中转成了byte数组(例如json.getBytes())，不需要做额外处理。因此仅仅需要对报文头进行编码即可。
public void encode(ChannelHandlerContext ctx, RemotingCommand remotingCommand, ByteBuf out)
throws Exception {
try {
ByteBuffer header = remotingCommand.encodeHeader(); // 编码报文头
out.writeBytes(header); // 写报文头
byte[] body = remotingCommand.getBody();
if (body != null) {
out.writeBytes(body); // 写body
}
} catch (Exception e) {
log.error("encode exception, " + RemotingHelper.parseChannelRemoteAddr(ctx.channel()), e);
if (remotingCommand != null) {
log.error(remotingCommand.toString());
}
RemotingUtil.closeChannel(ctx.channel());
}
}
接下来我们就看看报文头是什么。CustomerHeader是个接口，如下所示:
public interface CommandCustomHeader {
void checkFields() throws RemotingCommandException;
}
接口中只有一个checkFields的方法，用于检查报文头字段。不同的请求，有不同的CustomerHeader。例如，发送消息的CustomerHeader是：
public class SendMessageRequestHeader implements CommandCustomHeader {
@CFNotNull
private String producerGroup;
@CFNotNull
private String topic;
@CFNotNull
private String defaultTopic;
@CFNotNull
private Integer defaultTopicQueueNums;
@CFNotNull
private Integer queueId;
@CFNotNull
private Integer sysFlag;
@CFNotNull
private Long bornTimestamp;
@CFNotNull
private Integer flag;
@CFNullable
private String properties;
@CFNullable
private Integer reconsumeTimes;
@CFNullable
private boolean unitMode = false;
@CFNullable
private boolean batch = false;
private Integer maxReconsumeTimes;
@Override
public void checkFields() throws RemotingCommandException {
}
}
对报文头编码就包含了对CommandCustomerHeader的编码，但最终携带的信息不仅仅是它。下面我们就看看 remotingCommand.encodeHeader()做了些什么？
public ByteBuffer encodeHeader(final int bodyLength) {
// 1> header length size
int length = 4;// header数据长度域
// 2> header data length
byte[] headerData;
headerData = this.headerEncode(); // 对customerHeader编码
length += headerData.length; // 报文头长度域+header数据的长度
// 3> body data length
length += bodyLength;// 报文体如果有则加上长度
// 分配的长度目前包括:总长度域（4） + 报文头长度域（4） + 报文头内容
ByteBuffer result = ByteBuffer.allocate(4 + length - bodyLength);
// length
result.putInt(length); // 保存总长度
// header length
result.put(markProtocolType(headerData.length, serializeTypeCurrentRPC)); // 保存数据头长度，这里进行了进制转换
// header data
result.put(headerData);// 保存报文头数据
result.flip();
return result;
}
在这个方法钟，对CommandCustomerHead编码重点有2个：
1-header编码
2-数据长度计算
下面分别展开：
1-header编码
在RemotingCommand中，cumstomerHead是被标注为transient的，也就是不会被序列化。
实际上customerHeader的信息真正存放的地方是这里：
对！你没有猜错，customerHeader最终会被转换成map存放在extFields里面。然后将整个RemotingCommand进行JSON序列化(根据序列化配置来，一般是JSON)。这个才是真正的headerData部分。
2-数据长度计算
从encodeHeader方法中，我们可以看到header的数据包括了总长度域，处理了的数据头长度域和headerData三部分。它们组成如下：
总长度域（4）+ 数据头长度域（4）+ headerData。
其中数据头长度域做了一点点处理，把序列化类型也保存进来了。
public static byte[] markProtocolType(int source, SerializeType type) {
byte[] result = new byte[4];
result[0] = type.getCode(); // 序列化类型，JSON或者RocketMQ
result[1] = (byte) ((source >> 16) & 0xFF); // 2的16次方
result[2] = (byte) ((source >> 8) & 0xFF); // 2的8次方
result[3] = (byte) (source & 0xFF); // 256以下
return result;
}
实际上上面所做就是把长度域进制换一下，好腾出一个字节存序列化类型。
这样转换后，真正的长度就是len = result[1] * 2的16次方 + result[2] * 2的8次方 + rsult[3]。
解码
编码说完了，我们再来说说解码。解码的代码如下所示：
public static RemotingCommand decode(final ByteBuffer byteBuffer) {
int length = byteBuffer.limit();
int oriHeaderLen = byteBuffer.getInt();
int headerLength = getHeaderLength(oriHeaderLen);
byte[] headerData = new byte[headerLength];
byteBuffer.get(headerData);
RemotingCommand cmd = headerDecode(headerData, getProtocolType(oriHeaderLen));
int bodyLength = length - 4 - headerLength;
byte[] bodyData = null;
if (bodyLength > 0) {
bodyData = new byte[bodyLength];
byteBuffer.get(bodyData);
}
cmd.body = bodyData;
return cmd;
}
解码的代码，说实话刚开始我没有看懂，根据编码，总长度应该就在前面四个字节里面。但是！但是！它通过byteBuffer.limit()拿到了总长度！然后byteBuffer.getInt()，这个应该也是总长度，但是它却直接当作了我们的header长度域的数据，然后获取数据头长度和编码类型了。
总长度-4(数据长度域)-数据头长度拿到了报文体长度，然后直接获取bodyData。
然后我翻了下Remoting里的测试代码：
@Test
public void testEncodeAndDecode_FilledBody() {
System.setProperty(RemotingCommand.REMOTING_VERSION_KEY, "2333");
int code = 103; //org.apache.rocketmq.common.protocol.RequestCode.REGISTER_BROKER
CommandCustomHeader header = new SampleCommandCustomHeader();
RemotingCommand cmd = RemotingCommand.createRequestCommand(code, header);
cmd.setBody(new byte[] { 0, 1, 2, 3, 4});
ByteBuffer buffer = cmd.encode();
//Simulate buffer being read in NettyDecoder
buffer.getInt();
byte[] bytes = new byte[buffer.limit() - 4];
buffer.get(bytes, 0, buffer.limit() - 4);
buffer = ByteBuffer.wrap(bytes);
RemotingCommand decodedCommand = RemotingCommand.decode(buffer);
assertThat(decodedCommand.getSerializeTypeCurrentRPC()).isEqualTo(SerializeType.JSON);
assertThat(decodedCommand.getBody()).isEqualTo(new byte[]{ 0, 1, 2, 3, 4});
}
测试代码的中的cmd.encode()并不是Encoder的原方法，但是逻辑是一样的。重点是，模拟解码的时候，通过buffer.getInt()把前面四个字节给忽略了！这刚好就是编码中的总长度域的数据。这样，再调用 RemotingCommand.decode(buffer)的时候，就符合解码逻辑了！
这说明，在解码器的哪里，把前面的4个字节已经忽略了！是的，你没有猜错，在NettyDecoder的初始化方法里面，已经申明了丢弃前面4个字节！
public NettyDecoder() {
super(FRAME_MAX_LENGTH, 0, 4, 0, 4);
}
我们的NettyDecoder继承的LengthFieldBasedFrameDecoder，这是一种基于灵活长度的解码器。在数据包中，加了一个长度字段（长度域），保存上层包的长度。解码的时候，会按照这个长度，进行上层ByteBuf应用包的提取。
自定义长度解码器LengthFieldBasedFrameDecoder构造器，涉及5个参数，都与长度域（数据包中的长度字段）相关，具体介绍如下：
（1） maxFrameLength - 发送的数据包最大长度；
（2） lengthFieldOffset - 长度域偏移量，指的是长度域位于整个数据包字节数组中的下标；
（3） lengthFieldLength - 长度域的自己的字节数长度。
（4） lengthAdjustment – 长度域的偏移量矫正。 如果长度域的值，除了包含有效数据域的长度外，还包含了其他域（如长度域自身）长度，那么，就需要进行矫正。矫正的值为：包长 - 长度域的值 – 长度域偏移 – 长度域长。
（5） initialBytesToStrip – 丢弃的起始字节数。丢弃处于有效数据前面的字节数量。比如前面有4个节点的长度域，则它的值为4。
我们的NettyDecoder的构造函数中，initialBytesToStrip=4，因此头部的前4个字节被丢弃了，所以后面的解码逻辑完全正确！
