由於在長連接的場景下，客戶端和服務端並不是一直處於通信狀態，如果雙方長期沒有溝通則雙方都不清楚對方目前的狀態；所以需要發送一段很小的報文告訴對方“我還活著”。
同時還有另外幾個目的：
- 服務端檢測到某個客戶端遲遲沒有心跳過來可以主動關閉通道，讓它下線。
- 客戶端檢測到某個服務端遲遲沒有響應心跳也能重連獲取一個新的連接。
正好藉著在 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();
}
}
IdleStateHandler 誤區
一切看起來也沒毛病，但實際上卻沒有這樣實現重連邏輯。
最主要的問題還是對 IdleStateHandler 理解有誤。
我們假設下面的場景：
- 客戶端通過登錄連上了服務端並保持長連接，一切正常的情況下雙方各發心跳包保持連接。
- 這時服務端突入出現 down 機，那麼理想情況下應當是客戶端遲遲沒有收到服務端的響應從而 userEventTriggered 執行定時任務。
- 判斷當前時間 - UpdateWriteTime > 閾值 時進行重連。
但卻事與願違，並不會執行 2、3兩步。
因為一旦服務端 down 機、或者是與客戶端的網絡斷開則會回調客戶端的 channelInactive 事件。
IdleStateHandler 作為一個 ChannelInbound 也重寫了 channelInactive() 方法。
這裡的 destroy() 方法會把之前開啟的定時任務都給取消掉。
所以就不會再有任何的定時任務執行了，也就不會有機會執行這個重連業務。
靠譜實現
因此我們得有一個單獨的線程來判斷是否需要重連，不依賴於 IdleStateHandler。
於是 cim 在客戶端感知到網絡斷開時就會開啟一個定時任務：
之所以不在客戶端啟動就開啟，是為了節省一點線程消耗。網絡問題雖然不可避免，但在需要的時候開啟更能節省資源。
在這個任務重其實就是執行了重連，限於篇幅具體代碼就不貼了，感興趣的可以自行查閱。
同時來驗證一下效果。
啟動兩個服務端，再啟動客戶端連接上一臺並保持長連接。這時突然手動關閉一臺服務，客戶端可以自動重連到可用的那臺服務節點。
啟動客戶端後服務端也能收到正常的 ping 消息。
利用 :info 命令查看當前客戶端的鏈接狀態發現連的是 9000端口。
:info 是一個新增命令，可以查看一些客戶端信息。
這時我關掉連接上的這臺節點。
kill -9 2142
這時客戶端會自動重連到可用的那臺節點。 這個節點也收到了上線日誌以及心跳包。
服務端自動剔除離線客戶端
現在來看看服務端，它要實現的效果就是延遲 N 秒沒有收到客戶端的 ping 包則認為客戶端下線了，在 cim 的場景下就需要把他踢掉置於離線狀態。
消息發送誤區
這裡依然有一個誤區，在調用 ctx.writeAndFlush() 發送消息獲取回調時。
其中是 isSuccess 並不能作為消息發送成功與否的標準。
也就是說即便是客戶端直接斷網，服務端這裡發送消息後拿到的 success 依舊是 true。
這是因為這裡的 success 只是告知我們消息寫入了 TCP 緩衝區成功了而已。
和我之前有著一樣錯誤理解的不在少數，這是 Netty 官方給的回覆。
所以我們不能依據此來關閉客戶端的連接，而是要像上文一樣判斷 Channel 上綁定的時間與當前時間只差是否超過了閾值。
以上則是 cim 服務端的實現，邏輯和開頭說的一致，也和 Dubbo 的心跳機制有些類似。
於是來做個試驗：正常通信的客戶端和服務端，當我把客戶端直接斷網時，服務端會自動剔除客戶端。
總結
這樣就實現了文初的兩個要求。
- 服務端檢測到某個客戶端遲遲沒有心跳過來可以主動關閉通道，讓它下線。
- 客戶端檢測到某個服務端遲遲沒有響應心跳也能重連獲取一個新的連接。
同時也踩了兩個誤區，坑一個人踩就可以了，希望看過本文的都有所收穫避免踩坑。
關注我：私信回覆“555”獲取往期Java高級架構資料、源碼、筆記、視頻Dubbo、Redis、Netty、zookeeper、Spring cloud、分佈式、高併發等架構技術往期架構視頻截圖
閱讀更多 來一杯82年的Java 的文章
