如何设计一个优雅的心跳机制

来源：Fate/stay night [Heaven's Feel] lost butterfly

1 前言

在前一篇文章《聊聊 TCP 长连接和心跳那些事》中，我们已经聊过了 TCP 中的 KeepAlive，以及在应用层设计心跳的意义，但却对长连接心跳的设计方案没有做详细地介绍。事实上，设计一个好的心跳机制并不是一件容易的事，就我所熟知的几个 RPC 框架，它们的心跳机制可以说大相径庭，这篇文章我将探讨一下如何设计一个优雅的心跳机制，主要从 Dubbo 的现有方案以及一个改进方案来做分析。

2 预备知识

因为后续我们将从源码层面来进行介绍，所以一些服务治理框架的细节还需要提前交代一下，方便大家理解。

2.1 客户端如何得知请求失败了？

高性能的 RPC 框架几乎都会选择使用 Netty 来作为通信层的组件，非阻塞式通信的高效不需要我做过多的介绍。但也由于非阻塞的特性，导致其发送数据和接收数据是一个异步的过程，所以当存在服务端异常、网络问题时，客户端接是接收不到响应的，那我们如何判断一次 RPC 调用是失败的呢？

误区一：Dubbo 调用不是默认同步的吗？

Dubbo 在通信层是异步的，呈现给使用者同步的错觉是因为内部做了阻塞等待，实现了异步转同步。

误区二： Channel.writeAndFlush 会返回一个 channelFuture，我只需要判断 channelFuture.isSuccess 就可以判断请求是否成功了。

注意，writeAndFlush 成功并不代表对端接受到了请求，返回值为 true 只能保证写入网络缓冲区成功，并不代表发送成功。

避开上述两个误区，我们再来回到本小节的标题：客户端如何得知请求失败？正确的逻辑应当是以客户端接收到失败响应为判断依据。等等，前面不还在说在失败的场景中，服务端是不会返回响应的吗？没错，既然服务端不会返回，那就只能客户端自己造了。

一个常见的设计是：客户端发起一个 RPC 请求，会设置一个超时时间 client_timeout，发起调用的同时，客户端会开启一个延迟 client_timeout 的定时器

• 接收到正常响应时，移除该定时器。

• 定时器倒计时完毕，还没有被移除，则认为请求超时，构造一个失败的响应传递给客户端。

Dubbo 中的超时判定逻辑：

public static DefaultFuture newFuture(Channel channel, Request request, int timeout) {
    final DefaultFuture future = new DefaultFuture(channel, request, timeout);
    // timeout check
    timeoutCheck(future);
    return future;
}
private static void timeoutCheck(DefaultFuture future) {
    TimeoutCheckTask task = new TimeoutCheckTask(future);
    TIME_OUT_TIMER.newTimeout(task, future.getTimeout(), TimeUnit.MILLISECONDS);
}
private static class TimeoutCheckTask implements TimerTask {
    private DefaultFuture future;
    TimeoutCheckTask(DefaultFuture future) {
        this.future = future;
    }
    @Override
    public void run(Timeout timeout) {
        if (future == null || future.isDone()) {
            return;
        }
        // create exception response.
        Response timeoutResponse = new Response(future.getId());
        // set timeout status.
        timeoutResponse.setStatus(future.isSent() ? Response.SERVER_TIMEOUT : Response.CLIENT_TIMEOUT);
        timeoutResponse.setErrorMessage(future.getTimeoutMessage(true));
        // handle response.
        DefaultFuture.received(future.getChannel(), timeoutResponse);
    }
}

主要逻辑涉及的类： DubboInvoker， HeaderExchangeChannel， DefaultFuture ，通过上述代码，我们可以得知一个细节，无论是何种调用，都会经过这个定时器的检测，超时即调用失败，一次 RPC 调用的失败，必须以客户端收到失败响应为准。

2.2 心跳检测需要容错

网络通信永远要考虑到最坏的情况，一次心跳失败，不能认定为连接不通，多次心跳失败，才能采取相应的措施。

2.3 心跳检测不需要忙检测

忙检测的对立面是空闲检测，我们做心跳的初衷，是为了保证连接的可用性，以保证及时采取断连，重连等措施。如果一条通道上有频繁的 RPC 调用正在进行，我们不应该为通道增加负担去发送心跳包。心跳扮演的角色应当是晴天收伞，雨天送伞。

3 Dubbo 现有方案

本文的源码对应 Dubbo 2.7.x 版本，在 apache 孵化的该版本中，心跳机制得到了增强。

介绍完了一些基础的概念，我们便来看看 Dubbo 是如何设计应用层心跳的。Dubbo 的心跳是双向心跳，客户端会给服务端发送心跳，反之，服务端也会向客户端发送心跳。

3.1 连接建立时创建定时器

public class HeaderExchangeClient implements ExchangeClient {
    private int heartbeat;
    private int heartbeatTimeout;
    privat