Netty在RocketMQ中的应用----编解码

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个字节被丢弃了,所以后面的解码逻辑完全正确!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值