im即时通讯开发之用Netty实现心跳机制断线重连机制

Posted 2022-06-23 wecloud1314

早些年，做IM或推送系统需要面临很多问题，比如：资料少（众所周之的某互联网巨头几乎不分离这方面的资料）、轮子少（Netty这种牛逼的框架出现的有点晚）、难度高（高并发怎么实现？C10K问题呢？）。

现在好了，技术轮子越来越丰富，资料也越来越全（光即时通讯网都整理了IM和推送系统相关的上千篇相关文章）。Netty作为Java语言中的服务端高性能网络编程框架中的佼佼者，应用范围也越来越广，反正我知道不少人用它来撸IM或推送系统（说的就是你~~）。

 

为何需要心跳机制？

所谓心跳, 即在 TCP 长连接中, 客户端和服务器之间定期发送的一种特殊的数据包, 通知对方自己还在线, 以确保 TCP 连接的有效性。

注：心跳包还有另一个作用，经常被忽略，即：一个连接如果长时间不用，防火墙或者路由器就会断开该连接（PS：术语叫“端口老化”）。

先理解一下核心Handler：IdleStateHandler

在 Netty 中, 实现心跳机制的关键是 IdleStateHandler, 那么这个 Handler 如何使用呢?

先看下它的构造器：

public IdleStateHandler(int readerIdleTimeSeconds, int writerIdleTimeSeconds, int allIdleTimeSeconds)

    this((long)readerIdleTimeSeconds, (long)writerIdleTimeSeconds, (long)allIdleTimeSeconds, TimeUnit.SECONDS);

这里解释下三个参数的含义：

    readerIdleTimeSeconds: 读超时. 即当在指定的时间间隔内没有从 Channel 读取到数据时, 会触发一个 READER_IDLE 的 IdleStateEvent 事件.

    writerIdleTimeSeconds: 写超时. 即当在指定的时间间隔内没有数据写入到 Channel 时, 会触发一个 WRITER_IDLE 的 IdleStateEvent 事件.

    allIdleTimeSeconds: 读/写超时. 即当在指定的时间间隔内没有读或写操作时, 会触发一个 ALL_IDLE 的 IdleStateEvent 事件.

注：这三个参数默认的时间单位是秒。若需要指定其他时间单位，可以使用另一个构造方法：IdleStateHandler(boolean observeOutput, long readerIdleTime, long writerIdleTime, long allIdleTime, TimeUnit unit)

使用IdleStateHandler实现心跳（客户端篇）

下面将使用IdleStateHandler来实现心跳，Client端连接到Server端后，会循环执行一个任务：随机等待几秒，然后ping一下Server端，即发送一个心跳包。

当等待的时间超过规定时间，将会发送失败，以为Server端在此之前已经主动断开连接了。

实现代码如下。

ClientIdleStateTrigger —— 心跳触发器：

类ClientIdleStateTrigger也是一个Handler，只是重写了userEventTriggered方法，用于捕获IdleState.WRITER_IDLE事件（未在指定时间内向服务器发送数据），然后向Server端发送一个心跳包。

运行测试

首先启动客户端，再启动服务器端。

启动完成后，在客户端的控制台上，可以看到打印如下类似日志：

在服务器端可以看到控制台输出了类似如下的日志：

可以看到，客户端在发送4个心跳包后，第5个包因为等待时间较长，等到真正发送的时候，发现连接已断开了；而服务器端收到客户端的4个心跳数据包后，迟迟等不到下一个数据包，所以果断断开该连接。即时通讯开发

 

在测试过程中，有可能会出现如下异常情况：

出现这种情况的原因是：在连接已断开的情况下，仍然向服务器端发送心跳包。虽然在发送心跳包之前会使用 channel.isActive() 判断连接是否可用，但也有可能上一刻判断结果为可用，但下一刻发送数据包之前，连接就断了。

目前尚未找到优雅处理这种情况的方案，各位看官如果有好的解决方案，还望不吝赐教。拜谢！

如何用Netty实现网络断线重连机制？

断线重连对于复杂网络非常有用（没有这个，一旦断网，通信就无法自动恢复了），这里就不过多介绍，相信各位都知道是怎么回事。这里只说大致思路，然后直接上代码。

实现思路

客户端在监测到与服务器端的连接断开后，或者一开始就无法连接的情况下，使用指定的重连策略进行重连操作，直到重新建立连接或重试次数耗尽。

对于如何监测连接是否断开，则是通过重写ChannelInboundHandler#channelInactive来实现，但连接不可用，该方法会被触发，所以只需要在该方法做好重连工作即可。

1）启动客户端：

先只启动客户端，观察控制台输出，可以看到类似如下日志：

可以看到，当客户端发现无法连接到服务器端，所以一直尝试重连。随着重试次数增加，重试时间间隔越大，但又不想无限增大下去，所以需要定一个阈值，比如60s。如上图所示，当下一次重试时间超过60s时，会打印Sleep extension too large(*). Pinning to 60000，单位为ms。出现这句话的意思是，计算出来的时间超过阈值（60s），所以把真正睡眠的时间重置为阈值（60s）。

2）启动服务器端：

接着启动服务器端，然后继续观察客户端控制台输出。

可以看到，在第9次重试失败后，第10次重试之前，启动的服务器，所以第10次重连的结果为Successfully established a connection to the server.，即成功连接到服务器。接下来因为还是不定时ping服务器，所以出现断线重连、断线重连的循环。

3）扩展：

在不同环境，可能会有不同的重连需求。有不同的重连需求的，只需自己实现RetryPolicy接口，然后在创建TcpClient的时候覆盖默认的重连策略即可。