标签:逻辑 出现 心跳检测 art 业务 stat time 返回 服务
通过ping-pong双向心跳机制 可以保证无论通信哪一方出现网络故障,都能被及时检测出来 为了防止由于对方短时间内繁忙没有及时返回应答造成的误判,
只有连续N次心跳检测都失败才认定链路已经损害,需要关闭链路并重建链路.
当读或者写心跳消息发生I/O异常的时候,说明链路已经中断,此时需要立即关闭链路,如果是客户端,需要重新发起连接.如果是服务端,需要重新发起连接.
如果是服务端,需要清空缓存的半包信息,等待客户端重连.
如果链路中断,等待interval时间后,由客户端发起重连操作,如果重连失败,间隔周期interval后再次发起重连,直到重连成功.
为了保证服务端能够有充足的事件释放句柄资源,在首次断连时客户端需要等待interval时间后再发起重连,而不是失败后立即重连.
为了保证句柄资源能够及时释放,无论什么场景下的重连失败,客户端都必须保证自身的自选被及时释放,包括但不限于 socketchannel socket
重连失败后, 需要打印异常堆栈信息,方便后续问题定位
参考netty权威指南
1.客户端 发送心跳包
2.服务端 接受心跳包
3.1添加 IdleStateHandler 和 自定义的业务handler 其中 IdleStateHandler 每隔n秒对读写检测 触发相关读写事件
3.2 或者添加 ReadTimeoutHandler 没有read 主动关闭连接 抛异常
3.3建议使用建议使用IdleStateHandler 自己监控并处理(根据自己的需求调整读超时 写超时 空闲事件 是否关闭等自己的业务)
4.业务handler 使用userEventTriggered()方法 判断已被触发的idle_event事件 然后 出相关业务逻辑
5.给客户端通道加上一个断线重连的监听器ChannelFutureListene,该监听器如果监听到与服务端(channelFuture.isSuccess()事件)的连接断开了就会每隔1s触发一次重连操作
参考https://blog.csdn.net/hzf1993/article/details/82841043
https://github.com/njniecong/netty_all
标签:逻辑 出现 心跳检测 art 业务 stat time 返回 服务
原文地址:https://www.cnblogs.com/ericnie11/p/12044216.html