内容简介:说道“心跳”这个词大家都不陌生,当然不是指男女之间的心跳,而是和长连接相关的。顾名思义就是证明是否还活着的依据。
前言
说道“心跳”这个词大家都不陌生,当然不是指男女之间的心跳,而是和长连接相关的。
顾名思义就是证明是否还活着的依据。
什么场景下需要心跳呢?
目前我们接触到的大多是一些基于长连接的应用需要心跳来“保活”。
由于在长连接的场景下,客户端和服务端并不是一直处于通信状态,如果双方长期没有沟通则双方都不清楚对方目前的状态;所以需要发送一段很小的报文告诉对方 “我还活着”
。
同时还有另外几个目的:
- 服务端检测到某个客户端迟迟没有心跳过来可以主动关闭通道,让它下线。
- 客户端检测到某个服务端迟迟没有响应心跳也能重连获取一个新的连接。
正好借着在 cim 有这样两个需求来聊一聊。
心跳实现方式
心跳其实有两种实现方式:
-
TCP
协议实现(keepalive
机制)。 - 应用层自己实现。
由于 TCP
协议过于底层,对于开发者来说维护性、灵活度都比较差同时还依赖于操作系统。
所以我们这里所讨论的都是应用层的实现。
如上图所示,在应用层通常是由客户端发送一个心跳包 ping
到服务端,服务端收到后响应一个 pong
表明双方都活得好好的。
一旦其中一端延迟 N 个时间窗口没有收到消息则进行不同的处理。
客户端自动重连
先拿客户端来说吧,每隔一段时间客户端向服务端发送一个心跳包,同时收到服务端的响应。
常规的实现应当是:
“本地时间”
这样确实也能实现心跳,但并不友好。
在正常的客户端和服务端通信的情况下,定时任务依然会发送心跳包;这样就显得没有意义,有些多余。
所以理想的情况应当是客户端收到的写消息空闲时才发送这个心跳包去确认服务端是否健在。
好消息是 Netty
已经为我们考虑到了这点,自带了一个开箱即用的 IdleStateHandler
专门用于心跳处理。
来看看 cim
中的实现:
在 pipeline
中加入了一个 10秒没有收到写消息的 IdleStateHandler
,到时他会回调 ChannelInboundHandler
中的 userEventTriggered
方法。
所以一旦写超时就立马向服务端发送一个心跳(做的更完善应当在心跳发送失败后有一定的重试次数);
这样也就只有在空闲时候才会发送心跳包。
但一旦间隔许久没有收到服务端响应进行重连的逻辑应当写在哪里呢?
先来看这个示例:
当收到服务端响应的 pong 消息时,就在当前 Channel 上记录一个时间,也就是说后续可以在定时任务中取出这个时间和当前时间的差额来判断是否超过阈值。
超过则重连。
同时在每次心跳时候都用当前时间和之前服务端响应绑定到 Channel
上的时间相减判断是否需要重连即可。
也就是 heartBeatHandler.process(ctx);
的执行逻辑。
伪代码如下:
@Override public void process(ChannelHandlerContext ctx) throws Exception { long heartBeatTime = appConfiguration.getHeartBeatTime() * 1000; Long lastReadTime = NettyAttrUtil.getReaderTime(ctx.channel()); long now = System.currentTimeMillis(); if (lastReadTime != null && now - lastReadTime > heartBeatTime){ reconnect(); } }
IdleStateHandler 误区
一切看起来也没毛病,但实际上却没有这样实现重连逻辑。
最主要的问题还是对 IdleStateHandler
理解有误。
我们假设下面的场景:
userEventTriggered 当前时间 - UpdateWriteTime > 阈值
但却事与愿违,并不会执行 2、3两步。
因为一旦服务端 down
机、或者是与客户端的网络断开则会回调客户端的 channelInactive
事件。
IdleStateHandler
作为一个 ChannelInbound
也重写了 channelInactive()
方法。
这里的 destroy()
方法会把之前开启的定时任务都给取消掉。
所以就不会再有任何的定时任务执行了,也就不会有机会执行这个重连业务。
靠谱实现
因此我们得有一个单独的线程来判断是否需要重连,不依赖于 IdleStateHandler
。
于是 cim
在客户端感知到网络断开时就会开启一个定时任务:
之所以不在客户端启动就开启,是为了节省一点线程消耗。网络问题虽然不可避免,但在需要的时候开启更能节省资源。
在这个任务重其实就是执行了重连,限于篇幅具体代码就不贴了,感兴趣的可以自行查阅。
同时来验证一下效果。
启动两个服务端,再启动客户端连接上一台并保持长连接。这时突然手动关闭一台服务,客户端可以自动重连到可用的那台服务节点。
启动客户端后服务端也能收到正常的 ping
消息。
利用 :info
命令查看当前客户端的链接状态发现连的是 9000
端口。
:info 是一个新增命令,可以查看一些客户端信息。
这时我关掉连接上的这台节点。
kill -9 2142
这时客户端会自动重连到可用的那台节点。
这个节点也收到了上线日志以及心跳包。
服务端自动剔除离线客户端
现在来看看服务端,它要实现的效果就是延迟 N 秒没有收到客户端的 ping
包则认为客户端下线了,在 cim
的场景下就需要把他踢掉置于离线状态。
消息发送误区
这里依然有一个误区,在调用 ctx.writeAndFlush()
发送消息获取回调时。
其中是 isSuccess
并不能作为消息发送成功与否的标准。
也就是说即便是客户端直接断网,服务端这里发送消息后拿到的 success
依旧是 true
。
这是因为这里的 success
只是告知我们消息写入了 TCP
缓冲区成功了而已。
和我之前有着一样错误理解的不在少数,这是 Netty
官方给的回复。
相关 issue
:
https://github.com/netty/netty/issues/4915
同时感谢 95老徐以及闪电侠的一起排查。
所以我们不能依据此来关闭客户端的连接,而是要像上文一样判断 Channel
上绑定的时间与当前时间只差是否超过了阈值。
以上则是 cim
服务端的实现,逻辑和开头说的一致,也和 Dubbo
的心跳机制有些类似。
于是来做个试验:正常通信的客户端和服务端,当我把客户端直接断网时,服务端会自动剔除客户端。
总结
这样就实现了文初的两个要求。
- 服务端检测到某个客户端迟迟没有心跳过来可以主动关闭通道,让它下线。
- 客户端检测到某个服务端迟迟没有响应心跳也能重连获取一个新的连接。
同时也踩了两个误区,坑一个人踩就可以了,希望看过本文的都有所收获避免踩坑。
本文所有相关代码都在此处,感兴趣的可以自行查看:
https://github.com/crossoverJie/cim
如果本文对你有所帮助还请不吝转发。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Java 8实战
厄马(Raoul-Gabriel Urma)、弗斯科(Mario Fusco)、米克罗夫特(Alan Mycroft) / 陆明刚、劳佳 / 人民邮电出版社 / 2016-4-1 / CNY 79.00
本书全面介绍了Java 8 这个里程碑版本的新特性,包括Lambdas、流和函数式编程。有了函数式的编程特性,可以让代码更简洁,同时也能自动化地利用多核硬件。全书分四个部分:基础知识、函数式数据处理、高效Java 8 编程和超越Java 8,清晰明了地向读者展现了一幅Java 与时俱进的现代化画卷。一起来看看 《Java 8实战》 这本书的介绍吧!