Dubbo 的心跳设计，值得学习！

前言

 

谈到RPC肯定绕不开TCP通信，而主流的RPC框架都依赖于Netty等通信框架，这时候我们还要考虑是使用长连接还是短连接：

 

• 短连接：每次通信结束后关闭连接，下次通信需要重新创建连接；优点就是无需管理连接，无需保活连接；

• 长连接：每次通信结束不关闭连接，连接可以复用，保证了性能；缺点就是连接需要统一管理，并且需要保活；

 

主流的RPC框架都会追求性能选择使用长连接，所以如何保活连接就是一个重要的话题，也是本文的主题，下面会重点介绍一些保活策略；

 

为什么需要保活

 

上面介绍的长连接、短连接并不是TCP提供的功能，所以长连接是需要应用端自己来实现的，包括：连接的统一管理，如何保活等；如何保活之前我们了解一下为什么需要保活？

 

主要原因是网络不是100%可靠的，我们创建好的连接可能由于网络原因导致连接已经不可用了，如果连接一直有消息往来，那么系统马上可以感知到连接断开；

 

但是我们系统可能长时间没有消息来往，导致系统不能及时感知到连接不可用，也就是不能及时处理重连或者释放连接；常见的保活策略使用心跳机制由应用层来实现，还有网络层提供的TCP Keepalive保活探测机制；

 

TCP Keepalive机制

 

TCP Keepalive是操作系统实现的功能，并不是TCP协议的一部分，需要在操作系统下进行相关配置，开启此功能后，如果连接在一段时间内没有数据往来，TCP将发送Keepalive探针来确认连接的可用性，Keepalive几个内核参数配置：

 

• tcp_keepalive_time：连接多长时间没有数据往来发送探针请求，默认为7200s（2h）；

• tcp_keepalive_probes：探测失败重试的次数默认为10次；

• tcp_keepalive_intvl：重试的间隔时间默认75s；

 

以上参数可以修改到/etc/sysctl.conf文件中；是否使用Keepalive用来保活就够了，其实还不够，Keepalive只是在网络层就行保活，如果网络本身没有问题，但是系统由于其他原因已经不可用了，这时候Keepalive并不能发现；所以往往还需要结合心跳机制来一起使用；

 

心跳机制

 

何为心跳机制，简单来讲就是客户端启动一个定时器用来定时发送请求，服务端接到请求进行响应，如果多次没有接受到响应，那么客户端认为连接已经断开，可以断开半打开的连接或者进行重连处理；下面以Dubbo为例来看看是如何具体实施的；

 

Dubbo2.6.X

 

在HeaderExchangeClient中启动了定时器

 

ScheduledThreadPoolExecutor来定期执行心跳请求：

 

ScheduledThreadPoolExecutor scheduled = new ScheduledThreadPoolExecutor(2, 
    new NamedThreadFactory("dubbo-remoting-client-heartbeat", true));

 

在实例化HeaderExchangeClient时启动心跳定时器：

 

private void startHe