Dubbo心跳机制
前言
长连接和短连接
- 短连接：每次通信结束后关闭连接，下次通信需要重新创建连接；优点就是无需管理连接，无需保活连接；
- 长连接：每次通信结束不关闭连接，连接可以复用，保证了性能；缺点就是连接需要统一管理，并且需要保活；
主流的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心跳时间heartbeat默认是60s，超过heartbeat时间没有收到消息，就发送心跳消息(provider，consumer一样),如果连着3次(heartbeatTimeout为heartbeat*3)没有收到心跳响应，provider会关闭channel，而consumer会进行重连；不论是provider还是consumer的心跳检测都是通过启动定时任务的方式实现；
目的：维持provider和consumer之间的长连接
客户端如何得知请求失败了？
在失败的场景下，服务端是不会返回响应的，所以只能在客户端自身上设计了。
当客户端发起一个RPC请求时，会设置一个超时时间client_timeout,同时它也会开启一个延迟的client_timeout的定时器。当接收到正常响应时，会移除该定时器；而当计时器倒计时完毕后，还没有被移除，则会认为请求超时，构造一个失败的响应传递给客户端
public HeaderExchangeClient(Client client, boolean needHeartbeat) { if (client == null) { throw new IllegalArgumentException("client == null"); } this.client = client; // 创建信息交换通道 this.channel = new HeaderExchangeChannel(client); // 获得dubbo版本 String dubbo = client.getUrl().getParameter(Constants.DUBBO_VERSION_KEY); // 获得心跳周期配置，如果没有配置，并且dubbo是1.0版本的，则这只为1分钟，否则设置为0 this.heartbeat = client.getUrl().getParameter(Constants.HEARTBEAT_KEY, dubbo != null && dubbo.startsWith("1.0.") ? Constants.DEFAULT_HEARTBEAT : 0); // 获得心跳超时配置，默认是心跳周期的三倍 this.heartbeatTimeout = client.getUrl().getParameter(Constants.HEARTBEAT_TIMEOUT_KEY, heartbeat * 3); if (heartbeatTimeout < heartbeat * 2) { throw new IllegalStateException("heartbeatTimeout < heartbeatInterval * 2"); } // 开启心跳 if (needHeartbeat) { startHeatbeatTimer(); } }
创建了一个HashedWheelTimer开启心跳检测，这是 Netty 所提供的一个经典的时间轮定时器实现。HeaderExchangeServer也同时开启了定时器，代码逻辑和上述差不多
private void startHeatbeatTimer() { stopHeartbeatTimer(); if (heartbeat > 0) { heartbeatTimer = scheduled.scheduleWithFixedDelay( new HeartBeatTask(new HeartBeatTask.ChannelProvider() { public Collection<Channel> getChannels() { return Collections.<Channel>singletonList(HeaderExchangeClient.this); } }, heartbeat, heartbeatTimeout), heartbeat, heartbeat, TimeUnit.MILLISECONDS); } }
final class HeartBeatTask implements Runnable { private static final Logger logger = LoggerFactory.getLogger(HeartBeatTask.class); // 通道管理 private ChannelProvider channelProvider; // 心跳间隔 单位：ms private int heartbeat; // 心跳超时时间 单位：ms private int heartbeatTimeout; HeartBeatTask(ChannelProvider provider, int heartbeat, int heartbeatTimeout) { this.channelProvider = provider; this.heartbeat = heartbeat; this.heartbeatTimeout = heartbeatTimeout; } public void run() { try { long now = System.currentTimeMillis(); // 遍历所有通道 for (Channel channel : channelProvider.getChannels()) { // 如果通道关闭了，则跳过 if (channel.isClosed()) { continue; } try { // 最后一次接收到消息的时间戳 Long lastRead = (Long) channel.getAttribute( HeaderExchangeHandler.KEY_READ_TIMESTAMP); // 最后一次发送消息的时间戳 Long lastWrite = (Long) channel.getAttribute( HeaderExchangeHandler.KEY_WRITE_TIMESTAMP); // 如果最后一次接收或者发送消息到时间到现在的时间间隔超过了心跳间隔时间 if ((lastRead != null && now - lastRead > heartbeat) || (lastWrite != null && now - lastWrite > heartbeat)) { // 创建一个request Request req = new Request(); // 设置版本号 req.setVersion("2.0.0"); // 设置需要得到响应 req.setTwoWay(true); // 设置事件类型，为心跳事件 req.setEvent(Request.HEARTBEAT_EVENT); // 发送心跳请求 channel.send(req); if (logger.isDebugEnabled()) { logger.debug("Send heartbeat to remote channel " + channel.getRemoteAddress() + ", cause: The channel has no data-transmission exceeds a heartbeat period: " + heartbeat + "ms"); } } // 如果最后一次接收消息的时间到现在已经超过了超时时间 if (lastRead != null && now - lastRead > heartbeatTimeout) { logger.warn("Close channel " + channel + ", because heartbeat read idle time out: " + heartbeatTimeout + "ms"); // 如果该通道是客户端，也就是请求的服务器挂掉了，客户端尝试重连服务器 if (channel instanceof Client) { try { // 重新连接服务器 ((Client) channel).reconnect(); } catch (Exception e) { //do nothing } } else { // 如果不是客户端，也就是是服务端返回响应给客户端，但是客户端挂掉了，则服务端关闭客户端连接 channel.close(); } } } catch (Throwable t) { logger.warn("Exception when heartbeat to remote channel " + channel.getRemoteAddress(), t); } } } catch (Throwable t) { logger.warn("Unhandled exception when heartbeat, cause: " + t.getMessage(), t); } } interface ChannelProvider { // 获得所有的通道集合，需要心跳的通道数组 Collection<Channel> getChannels(); } }
它首先遍历所有的Channel,在服务端对用的是所有客户端连接，在客户端对应的是服务端连接，判断当前TCP连接是否空闲，如果空闲就发送心跳报文，判断是否空闲，根据Channel是否有读或写来决定，比如一分钟内没有读或写就发送心跳报文，然后是处理超时的问题，处理客户端超时重新建立TCP连接，目前的策略是检查是否在3分钟内都没有成功接受或发送报文，如果在服务端检测则就会主动关闭远程客户端连接。
