Netty高可靠性设计：优化建议

尽管Netty的可靠性已经做得非常出色，但是在生产实践中还是发现了一些待优化点，本小节将进行简单说明。希望后续的版本中可以解决，当然用户也可以根据自己的实际需要决定自行优化。

1 发送队列容量上限控制

Netty的NIO消息发送队列ChannelOutboundBuffer并没有容量上限控制，它会随着消息的积压自动扩展，直到达到0x7fffffff。

如果网络对方处理速度比较慢，导致TCP滑窗长时间为0；或者消息发送方发送速度过快，或者一次批量发送消息量过大，都可能会导致ChannelOutboundBuffer的内存膨胀，这可能会导致系统的内存溢出。

建议优化方式如下：在启动客户端或者服务端的时候，通过启动项的ChannelOption设置发送队列的长度，或者通过-D启动参数配置该长度。

2 回推发送失败的消息

当网络发生故障的时候，Netty会关闭链路，然后循环释放待未发送的消息，最后通知监听listener。

这样的处理策略值得商榷，对于大多数用户而言，并不关心底层的网络I/O异常，他们希望链路恢复之后可以自动将尚未发送的消息重新发送给对方，而不是简单的销毁。

Netty销毁尚未发送的消息，用户可以通过监听器来得到消息发送异常通知，但是却无法获取原始待发送的消息。如果要实现重发，需要自己缓存消息，如果发送成功，自己删除，如果发送失败，重新发送。这对于大多数用户而言，非常麻烦，用户在开发业务代码的同时，还需要考虑网络I/O层的异常并为之做特殊的业务逻辑处理。

下面我们看下Mina的实现，当发生链路异常之后，Mina会将尚未发送的整包消息队列封装到异常对象中，然后推送给用户Handler，由用户来决定后续的处理策略。相比于Netty的“野蛮”销毁策略，Mina的策略更灵活和合理，由用户自己决定发送失败消息的后续处理策略。

大多数场景下，业务用户会使用RPC框架，他们通常不需要直接针对Netty编程，如果Netty提供了发送失败消息的回推功能，RPC框架就可以进行封装，提供不同的策略给业务用户使用，例如：

1．缓存重发策略：当链路发生异常之后，尚未发送成功的消息自动缓存，待链路恢复正常之后重发失败的消息；

2．失败删除策略：当链路发生异常之后，尚未发送成功的消息自动销毁，它可能是非重要消息，例如日志消息，也可能是由业务直接监听异常并做特殊处理；

3．其他策略.......