分佈式系統心跳協議的設計

分佈式系統心跳協議的設計

應用層心跳必不可少：
一、操做系統崩潰致使機器重啓, 沒有機會發送 FIN 分節
二、服務器硬件故障致使機器重啓, 也沒有機會發送 FIN 分節
三、併發鏈接數很高時, 操做系統或進程若是重啓, 可能沒有機會斷開所有鏈接, 即 FIN 分節可能出現丟包, 但沒有機會重試
四、網絡故障, 鏈接雙方能得知這一狀況的惟一方案是檢測心跳超時

爲何 TCP keepalive 不能代替應用層心跳?
心跳除了說明進程還在、網絡通暢, 更重要的是代表應用程還能正常工做;
而 TCP keepalive 由操做系統負責探查, 即便進程死鎖或阻塞, 操做系統也會如常收發 TCP keepalive 消息, 對方沒法得知這一異常.

進程 C 依賴於 S, 則通常 S 爲 sender, C 爲 receiver.

心跳設計關鍵：（高置信度與低反應時間不可兼得）
一、一般 sender 的發送週期和 receiver 的檢查週期相同, 爲 T; timeout 時間通常爲 2T
二、T 越小, 開銷越大; T 越大, receiver 檢測到故障的延遲也就越大
三、心跳信息應該包含發送方的標識符; 建議也包含當前負載, 便於客戶端作負載均衡
四、若是 sender 和 receiver 之間有其餘消息中轉進程, 那麼還應該加上 sender 的發送時間, 防止消息在傳輸過程當中堆積而致使假心跳
五、要在工做線程中發送, 不要單獨起一個」心跳線程」, 防止僞心跳（防止工做線程死鎖或阻塞時還在發送心跳）
六、與業務信息用同一個鏈接, 不要單獨用」心跳鏈接」, 防止僞心跳（若是驗證的不是收發業務數據的 TCP 鏈接暢通則意義不大）