解读netty3.9的数据处理流程（一）

前言：

Netty是一个异步事件驱动的网络应用程序框架用于快速开发可维护的高性能协议服务器和客户端。

特点：

• 统一的API，适用于不同的协议（阻塞和非阻塞）

• 基于灵活、可扩展的事件驱动模型

• 高度可定制的线程模型

环境准备：

拉取 https://github.com/netty/netty/tree/3.9

命令：

git clone https://github.com/netty/netty.gitGit checkout -b 3.9 origin/3.9
Git checkout -b 3.9 origin/3.9
复制代码

netty概览：

在netty中，Channel是通讯的载体，ChannelHandler是数据处理的执行者，ChannelPipeline是数据处理的通道；

数据流向分析：

以 DefaultChannelPipeline 为例，讲述已注册到管道pipeline的 ChannelHandler 如何处理数据？

downStream方向 ： 业务对象 =》 数据流

从pipeline管道tail对象起依次调用注册的ChannelDownstreamHandler处理器，最终经由 ChannelSink 的 eventSunk 根据事件触发boss或者worker线程池处理任务。

upStream方向 ： 数据流 =》 业务对象

从pipeline管道head对象开始依次调用注册的ChannelUpstreamHandler处理器，最终将数据流转为业务层的业务对象。

这点很重要，会影响到我们注册处理器的逻辑。

对于 ChannelSink 如何真正地触发数据写出去？暂仅考虑MessageEvent,可以看到将消息写到channel所在worker线程的队列中,并调用 writeFromUserCode 触发worker发送数据。

写模型：

对于存在队列中的数据如何依次发送呢？如果不可写了该怎么处理？（写入过快来不及发送，导致缓冲区满了）

可以看到依次处理队列中的消息，如果有消息,则调用 buf.transferTo(ch) 将数据发送出去,如果返回 localWrittenBytes 大于 0 ，跳出本次循环，如为零则循环 writeSpinCount ，如再次期间 localWrittenBytes >0 ,说明再次可写。并调用 fireWriteComplete 触发上游，这里暂时忽略结果处理。

说明：触发写不止这种情况，channel可写的情况下也会触发将队列清空。

读模型分析：

写的流程已经分析完成，读模型相对简单，当监听到读事件时，即会触发worker读取数据装载成 buffer ，调用 handler 处理。

后续：

后续会先对Netty特性基于源码分析，并设计个便捷可配置的压测模型，方便开发中快速针对不同通讯实现压测。

可以点击阅读原文获取 《Nip trick and trip》 ，相信可以使得netty的理解更深入。

喜欢的读者可以关注路上小栈，及时获取最新的技术文章，专注源码分析、技术业务思考等。