Netty的ByteToMessageDecoder/LengthFieldBasedFrameDecoder

是个inbound handler，channelRead方法里面，用一个bytebuf（cumulation）来把下一个数据包和当前这一个拼在一起，以免同一个请求被拆包。然后callDecode，里面调用decode这个方法

decode是被子类重写的方法，像rocketMq的NettyDecoder其实主要的逻辑还是在它继承的LengthFieldBasedFrameDecoder中，而LengthFieldBasedFrameDecoder又继承了ByteToMessageDecoder。

所以LengthFieldBasedFrameDecoder就是一种解决粘包的方案：在报文头中用固定长度字段表示当前报文长度。

super(FRAME_MAX_LENGTH, 0, 4, 0, 4);

/**

     * Creates a new instance.

     *

     * @param maxFrameLength-----------最大帧长，Integer.parseInt(System.getProperty("com.rocketmq.remoting.frameMaxLength", "16777216"));

     *        the maximum length of the frame.  If the length of the frame is

     *        greater than this value, {@link TooLongFrameException} will be

     *        thrown.

     * @param lengthFieldOffset----------描述当前帧长的第一个字节的起始位置，因为有时候信息并不是直接以帧长开头，有可能前面还有别的信息

     *        the offset of the length field

     * @param lengthFieldLength----------描述当前帧长的字节的个数

     *        the length of the length field

     * @param lengthAdjustment----------比如实际帧长是40，描述帧长的字节是4，如果你的lengthFieldLength的值是44（有的人会把描述的数据本身长度也算进去），那么就得有4的调整，才准确

     *        the compensation value to add to the value of the length field

     * @param initialBytesToStrip----------解析时候需要跳过的字节长，这个是干啥？

     *        the number of first bytes to strip out from the decoded frame

     */

callDecode调用decode传入三个参数： context， bytebuf， out，第三个out是一个list，里面放的是解决了拆包粘包问题之后解析出来的完整的一个请求，然后for循环发起channelread，RocktMq server的源码里是封装成一个

command对象，然后发起链式的处理

巴特西

Netty的ByteToMessageDecoder/LengthFieldBasedFrameDecoder

最新文章

热门文章