防止发送队列积压

在项目中，考虑的性能参数

在实际项目中，根据业务QPS 规划、客户端处理性能、网络带宽、链路数、消息平

均码流大小等综合因素计算并设置高水位（ WriteBufferHigh Water Mark ）值， 利用高水位

做消息发送速度的流控， 既可以保护自身，同时又能减轻服务端的压力，防止服务端被压

挂。

在日常监控中， 需要将Netty 的链

路数、网络读写速度等指标纳入监控系统， 发现问题之后需要及时告警。

https://www.infoq.cn/article/netty-reliability/ 

（Netty 系列之 Netty 可靠性分析）

Netty流控小技巧

客户端高并发，服务器正常响应

    单独的一个客户端，但是发送频繁,直接进行循环发送

客户端发送过于频繁，直接采用循环，在循环体内没有任何业务处理。直接进行全负荷测试

调用Channel 的write 方法时，如果发送方为业务线程， 则将发送操作封装成WriteTask ， 放到Netty 的NioEventLoop中执行。

显然Netty 的I/O 线程NioEventLoop 无法完成如此多消息的发送，因此发送任务队列积压，进而导致内存泄漏。

为了防止在高并发场景下，由于服务端处理慢导致客户端消息积压，除了服务端做流控，客户端也需要做并发保护，防止自身发生消息积压。

利用Netty 提供的高低水位机制，可以实现客户端更精准的流控，

    Netty 的NioEventLoop 线程内部维护了一个Queue taskQueue， 除了处理网

络I/O 读写操作，同时还负责执行网络读写相关的Task （ 包含用户自定义Task ）。

    积压点：这个Queue这个值会积压，问题，如何取得这个值进行监控？

现象：统计GC数据，发现老生代已经满

客户端高并发，服务器响应慢，客户端发送队列积压    

    取得发送队列的值。

     ctx.channel().unsafe().outboundBuffer().nioBufferSize()

channelActive 当Channel 处于活动状态时被调用；Channel 已经连接/绑定并且已经就绪

channelInactive 当Channel 离开活动状态并且不再连接它的远程节点时被调用

如果客户端异常关闭，chanelactive是感知不到的。