1、引言

说道“心跳”这个词大家都不陌生，当然不是指男女之间的心跳，而是和长连接相关的。顾名思义就是证明是否还活着的依据。

什么场景下需要心跳呢？目前我们接触到的大多是一些基于长连接的应用需要心跳来“保活”。

由于在长连接的场景下，客户端和服务端并不是一直处于通信状态，如果双方长期没有沟通则双方都不清楚对方目前的状态，所以需要发送一段很小的报文告诉对方“我还活着”。

同时还有另外几个目的：

1）服务端检测到某个客户端迟迟没有心跳过来可以主动关闭通道，让它下线；

2）客户端检测到某个服务端迟迟没有响应心跳也能重连获取一个新的连接。

本文正好借着在CIM系统中有这样两个需求（CIM是本文作者从零开发的一个学习性质的IM系统，详见《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》），正好来聊一聊我是如何理解IM长连接的心跳及重连机制，以及又是怎么踩坑已及填坑的。

本文配套的CIM源码地址：

主要镜像：https://github.com/crossoverJie/cim

备用镜像：https://github.com/52im/cim

阅读本文需要一定的网络编程以及Netty方面的知识。

2、关于作者

crossoverJie（陈杰）： 90后，毕业于重庆信息工程学院，现供职于重庆猪八戒网络有限公司。

作者的博客：https://crossoverjie.top

作者的Github：https://github.com/crossoverJie

本文作者的其它文章：

《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》

《技术干货：从零开始，教你设计一个百万级的消息推送系统》

3、参考资料

➊ 有关网络心跳保活方面的理论文章：

《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》

《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》

《移动端IM实践：实现Android版微信的智能心跳机制》

《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》

《一文读懂即时通讯应用中的网络心跳包机制：作用、原理、实现思路等》

《融云技术分享：融云安卓端IM产品的网络链路保活技术实践》

➋ 有关网络心跳保活方面的实践文章：

《MobileIMSDK——一套开源的原创移动端即时通讯框架（有完整的心跳保活逻辑和代码实现）》

《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》

《手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制》

《适合新手：从零开发一个IM服务端（基于Netty，有完整源码）》

《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》

《自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》

4、心跳实现方式

心跳其实有两种实现方式：

1）TCP 协议实现（keepalive 机制，详见《TCP/IP详解卷1：协议-第23章 TCP的保活定时器》）；

2）应用层自己实现。

由于 TCP 协议过于底层，对于开发者来说维护性、灵活度都比较差同时还依赖于操作系统（详见：《为何基于TCP协议的移动端IM仍然需要心跳保活机制？》）。

所以我们这里所讨论的都是应用层的实现：

如上图所示，在应用层通常是由客户端发送一个心跳包 ping 到服务端，服务端收到后响应一个 pong 表明双方都活得好好的。一旦其中一端延迟 N 个时间窗口没有收到消息则进行不同的处理。

5、客户端自动重连

先拿客户端来说吧，每隔一段时间客户端向服务端发送一个心跳包，同时收到服务端的响应。

常规的实现应当是：

1）开启一个定时任务，定期发送心跳包；

2）收到服务端响应后更新本地时间；

3）再有一个定时任务定期检测这个“本地时间”是否超过阈值；

4）超过后则认为服务端出现故障，需要重连。

这样确实也能实现心跳，但并不友好。

在正常的客户端和服务端通信的情况下，定时任务依然会发送心跳包；这样就显得没有意义，有些多余。所以理想的情况应当是客户端收到的写消息空闲时才发送这个心跳包去确认服务端是否健在。

好消息是 Netty 已经为我们考虑到了这点，自带了一个开箱即用的 IdleStateHandler 专门用于心跳处理。

来看看 cim 中的实现：

在 pipeline 中加入了一个 10秒没有收到写消息的 IdleStateHandler，到时他会回调 ChannelInboundHandler 中的 userEventTriggered 方法。

所以一旦写超时就立马向服务端发送一个心跳（做的更完善应当在心跳发送失败后有一定的重试次数）。

这样也就只有在空闲时候才会发送心跳包。但一旦间隔许久没有收到服务端响应进行重连的逻辑应当写在哪里呢？

先来看这个示例：

当收到服务端响应的 pong 消息时，就在当前 Channel 上记录一个时间，也就是说后续可以在定时任务中取出这个时间和当前时间的差额来判断是否超过阈值。

超过则重连。

同时在每次心跳时候都用当前时间和之前服务端响应绑定到 Channel 上的时间相减判断是否需要重连即可。

也就是 heartBeatHandler.process(ctx); 的执行逻辑。

伪代码如下：

@Override

public void process(ChannelHandlerContext ctx) throws Exception {

longheartBeatTime = appConfiguration.getHeartBeatTime() * 1000;

Long lastReadTime = NettyAttrUtil.getReaderTime(ctx.channel());

longnow = System.currentTimeMillis();

if(lastReadTime != null&& now - lastReadTime > heartBeatTime){

reconnect();

}

}

6、IdleStateHandler 误区

一切看起来也没毛病，但实际上却没有这样实现重连逻辑。最主要的问题还是对 IdleStateHandler 理解有误。

我们假设下面的场景：

1）客户端通过登录连上了服务端并保持长连接，一切正常的情况下双方各发心跳包保持连接；

2）这时服务端突入出现 down 机，那么理想情况下应当是客户端迟迟没有收到服务端的响应从而 userEventTriggered 执行定时任务；

3）判断当前时间 - UpdateWriteTime > 阈值时进行重连。

但却事与愿违，并不会执行 2、3两步。

因为一旦服务端 down 机、或者是与客户端的网络断开则会回调客户端的 channelInactive 事件。

IdleStateHandler 作为一个 ChannelInbound 也重写了 channelInactive() 方法。

这里的 destroy() 方法会把之前开启的定时任务都给取消掉。所以就不会再有任何的定时任务执行了，也就不会有机会执行这个重连业务。

7、靠谱实现

因此我们得有一个单独的线程来判断是否需要重连，不依赖于 IdleStateHandler。

于是 cim 在客户端感知到网络断开时就会开启一个定时任务：

之所以不在客户端启动就开启，是为了节省一点线程消耗。网络问题虽然不可避免，但在需要的时候开启更能节省资源。

在这个任务重其实就是执行了重连，限于篇幅具体代码就不贴了，感兴趣的可以自行查阅。

同时来验证一下效果：

启动两个服务端，再启动客户端连接上一台并保持长连接。这时突然手动关闭一台服务，客户端可以自动重连到可用的那台服务节点。

启动客户端后服务端也能收到正常的 ping 消息：

利用 :info 命令查看当前客户端的链接状态发现连的是 9000端口。

:info 是一个新增命令，可以查看一些客户端信息。

这时我关掉连接上的这台节点：

1kill-9 2142

这时客户端会自动重连到可用的那台节点。这个节点也收到了上线日志以及心跳包。

8、服务端自动剔除离线客户端

现在来看看服务端，它要实现的效果就是延迟 N 秒没有收到客户端的 ping 包则认为客户端下线了，在 cim 的场景下就需要把他踢掉置于离线状态。

有关消息发送误区：

这里依然有一个误区，在调用 ctx.writeAndFlush() 发送消息获取回调时。

其中是 isSuccess 并不能作为消息发送成功与否的标准：

也就是说即便是客户端直接断网，服务端这里发送消息后拿到的 success 依旧是 true。这是因为这里的 success 只是告知我们消息写入了 TCP 缓冲区成功了而已。

和我之前有着一样错误理解的不在少数，这是 Netty 官方给的回复：

所以我们不能依据此来关闭客户端的连接，而是要像上文一样判断 Channel 上绑定的时间与当前时间只差是否超过了阈值。

以上则是 cim 服务端的实现，逻辑和开头说的一致，也和 Dubbo 的心跳机制有些类似。

于是来做个试验：正常通信的客户端和服务端，当我把客户端直接断网时，服务端会自动剔除客户端。

9、本文小结

这样就实现了文初的两个要求：

1）服务端检测到某个客户端迟迟没有心跳过来可以主动关闭通道，让它下线；

2）客户端检测到某个服务端迟迟没有响应心跳也能重连获取一个新的连接。

同时也踩了两个误区，坑一个人踩就可以了，希望看过本文的都有所收获避免踩坑。

本文所有相关代码都在此处，感兴趣的可以自行查看：