[[408364]]

之前寫過一篇文章, 介紹"可靠通信三原則". 對于一個分布式數(shù)據(jù)庫, 如果想實現(xiàn) 100% 高可用(也即客戶端的請求永遠(yuǎn)不會返回失敗), 同樣可以用可靠通信三原則中的重試?yán)碚摵腿ブ乩碚搧斫鉀Q. 但在實踐上, 需要在成功率, 耗時(速度和性能)各方面進行取舍. 本文分享實際經(jīng)驗, 介紹什么樣的選擇是普適的, 各位可以參考.

客戶端訪問數(shù)據(jù)庫服務(wù)器, 發(fā)起大量的請求, 絕對不可能做到每一個請求都是成功的. 因為網(wǎng)絡(luò)原因, 請求可能失敗. 因為服務(wù)器內(nèi)部處理沖突, 或者分布式節(jié)點間協(xié)調(diào)沖突, 都可能導(dǎo)致請求失敗.

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

某些實現(xiàn)了 Basic Paxos + 日志復(fù)制狀態(tài)機模型的系統(tǒng), 因為所謂的"Leaderless", 會產(chǎn)生大量沖突. 即使是使用 Raft, 在某些情況下意外發(fā)生選舉, 也會導(dǎo)致請求沖突.

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

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

replication -> server -> client SDK -> user 

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

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

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

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

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

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

要設(shè)計一個高可靠的系統(tǒng), 可靠傳輸三原則是非常有用的基礎(chǔ)理論, 但不是銀彈. 本質(zhì)上, 軟件開發(fā)就是大量的分析細(xì)化體力活, 以及對系統(tǒng)復(fù)雜度的把控.

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

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