长链接的心跳及重连设计

前言

说道“心跳”这个词你们都不陌生，固然不是指男女之间的心跳，而是和长链接相关的。

顾名思义就是证实是否还活着的依据。

什么场景下须要心跳呢？

目前咱们接触到的大可能是一些基于长链接的应用须要心跳来“保活”。

因为在长链接的场景下，客户端和服务端并非一直处于通讯状态，若是双方长期没有沟通则双方都不清楚对方目前的状态；因此须要发送一段很小的报文告诉对方“我还活着”。

同时还有另外几个目的：

• 服务端检测到某个客户端迟迟没有心跳过来能够主动关闭通道，让它下线。
• 客户端检测到某个服务端迟迟没有响应心跳也能重连获取一个新的链接。

正好借着在 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 理解有误。

咱们假设下面的场景：

1. 客户端经过登陆连上了服务端并保持长链接，一切正常的状况下双方各发心跳包保持链接。
2. 这时服务端突入出现 down 机，那么理想状况下应当是客户端迟迟没有收到服务端的响应从而 userEventTriggered 执行定时任务。
3. 判断当前时间 - UpdateWriteTime > 阈值 时进行重连。

但却事与愿违，并不会执行 二、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

若是本文对你有所帮助还请不吝转发。