[[408364]]

之前寫過一篇文章, 介紹"可靠通信三原則". 對于一個分布式數據庫, 如果想實現 100% 高可用(也即客戶端的請求永遠不會返回失敗), 同樣可以用可靠通信三原則中的重試理論和去重理論來解決. 但在實踐上, 需要在成功率, 耗時(速度和性能)各方面進行取舍. 本文分享實際經驗, 介紹什么樣的選擇是普適的, 各位可以參考.

客戶端訪問數據庫服務器, 發起大量的請求, 絕對不可能做到每一個請求都是成功的. 因為網絡原因, 請求可能失敗. 因為服務器內部處理沖突, 或者分布式節點間協調沖突, 都可能導致請求失敗.

所謂容錯處理, 就是在遇到錯誤的時候進行重試. 因為錯誤必然發生, 只有重試才能消除錯誤的影響, 就好像 IP 層必然會丟包, 但 TCP 協議通過重傳達到某種程度的可靠傳輸.

某些實現了 Basic Paxos + 日志復制狀態機模型的系統, 因為所謂的"Leaderless", 會產生大量沖突. 即使是使用 Raft, 在某些情況下意外發生選舉, 也會導致請求沖突.

面對沖突(失敗)到底應該由誰來重試呢? 這涉及到工程實踐上模塊職責劃分的問題, 模塊職責的劃分, 往往比代碼實現更重要. 一般來說, 發生重試的位置越底層, 性能會越好; 發生重試的位置越上層, 判斷是否應該重試的依據就能更全面.

我們簡單把數據庫系統(生態)劃分為幾個大的模塊, 從底層(左)到上層(右)是:

replication -> server -> client SDK -> user 

最常見的做法是讓 user 自己重試, 例如常見的 Redis SDK, 如果某臺 server 宕機導致請求失敗, 那么要求用戶換一個 IP, 重新創建連接, 再次重復請求.

某些系統會封裝專屬的 client SDK, 例如, 把官方的 Redis SDK 做一下簡單封裝, 攔截每一個請求的結果, 如果發現錯誤, SDK 內部就自動重試. 這樣做, user 就不需要有重試邏輯, 代碼可以簡化. 是這樣的, 多個協作的模塊, 如果某個模塊攬了一些職責, 那它的上層模塊就能省些工夫.

如果 user 既不想重試, client SDK 也不想重試, 那怎么辦呢? 能不能把職責全推給 server 呢? 絕對不可能, 參見這篇文章的總結. 那么, 為什么 SDK 重試之后, user 就不需要重試呢? 因為 SDK 和 user 是在同一個運行空間內, 它們是一個整體, 兩者之間沒有可靠傳輸問題.

那么, 既然 client SDK 必須有重試邏輯, server 是否就不需要有重試邏輯了呢? 理論上可以, 但實踐上, server 自身依然要降低自己的故障率, 降低故障率的必要手段就是 重試 . 例如, server 請求 paxos 模塊同步一條操作日志, 但因為非預期的 multi-master 出現, 導致和其它節點爭搶同一個位置失敗, 這時, server 如果直接報錯給 client, 那么, server 的故障數量就加一. 但是, server 可以重試, 再次調用 paxos 模塊, 去爭搶下一個位置, 直到成功. 這樣, client 就會很少見到 server 報錯.

但是, 無論是 server 還是 client 都不可能無限次重試, 因為每一次重試都會消耗時間, 最極端的情況可能要重試幾個小時直到永遠, 這當然不行, 所以, 需要引入 超時機制 , 重試一定次數之后即使還是失敗, 也必須報錯給上層.

重試會增加總的耗時, 這樣, 給上層帶來的不好效果就是, 上層覺得下層速度慢, 性能差. 所以, 必須有系統思維, 做出判斷, 做綜合的取舍. 從經驗上看, 無論 server 還是 client SDK, 都必須分析細化, 盡可能重試, 以提高成功率. 大部分情況下, 開發者往往過多地放棄重試, 而較少地進行重試, 畢竟, 多一種重試場景, 就多寫一段代碼, 人總是會想偷懶的.

要設計一個高可靠的系統, 可靠傳輸三原則是非常有用的基礎理論, 但不是銀彈. 本質上, 軟件開發就是大量的分析細化體力活, 以及對系統復雜度的把控.

重試帶來的額外問題就是去重, 這也是可靠傳輸三原則里的第二項原則. 你可能聽過"冪等性"這個詞匯, 和去重是一回事. 如果一個操作是非冪等的, 那么, 就不能重試.

但是, 實踐上, 我們可以把冪等性的職責向上推, 盡可能推給上層. 畢竟, 至少對于 user 來說, 100% 的成功率, 優先級比對冪等性的疑慮要高得多. 用戶同意下層不考慮冪等性, 而大膽地去重試, 但是, 對下層偶然的失敗會非常敏感. 簡單說就是: 別管什么冪等性, 在超時時間限制以內, 大膽重試!