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

1479人阅读 评论(0) 收藏 举报
分类:

尽管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.其他策略.......

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:3502495次
    • 积分:52683
    • 等级:
    • 排名:第57名
    • 原创:1440篇
    • 转载:83篇
    • 译文:1篇
    • 评论:3463条
    博客专栏
    最新评论