前言

說道“心跳”這個詞大家都不陌生，當然不是指男女之間的心跳，而是和長連接相關的。

顧名思義就是證明是否還活着的依據。

什麼場景下需要心跳呢？

目前我們接觸到的大多是一些基於長連接的應用需要心跳來“保活”。

由於在長連接的場景下，客戶端和服務端並不是一直處於通信狀態，如果雙方長期沒有溝通則雙方都不清楚對方目前的狀態；所以需要發送一段很小的報文告訴對方“我還活着”。

同時還有另外幾個目的：

服務端檢測到某個客戶端遲遲沒有心跳過來可以主動關閉通道，讓它下線。
客戶端檢測到某個服務端遲遲沒有響應心跳也能重連獲取一個新的連接。

正好藉着在 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();
    }

}