由於鬱白之前寫的關於Multi-Paxos 的文章流傳非常廣, 具體地址: http://oceanbase.org.cn/?p=111 原文提出了一個叫"幽靈復現" 的問題, 認為這個是一個很詭異的問題, 後續和很多人交流關於一致性協議的時候, 也經常會提起這個問題, 但是其實這個問題我認為就是常見的"第三態"問題加了一層包裝而已.
來自鬱白的博客:
使用Paxos協議處理日誌的備份與恢復,可以保證確認形成多數派的日誌不丟失,但是無法避免一種被稱為「幽靈復現」的現象,如下圖所示:
對於將Paxos協議應用在資料庫日誌同步場景的情況,幽靈復現問題是不可接受,一個簡單的例子就是轉賬場景,用戶轉賬時如果返回結果超時,那麼往往會查詢一下轉賬是否成功,來決定是否重試一下。如果第一次查詢轉賬結果時,發現未生效而重試,而轉賬事務日誌作為幽靈復現日誌重新出現的話,就造成了用戶重複轉賬。
為了處理「幽靈復現」問題,我們在每條日誌的內容中保存一個generateID,leader在生成這條日誌時以當前的leader ProposalID作為generateID。按logID順序回放日誌時,因為leader在開始服務之前一定會寫一條StartWorking日誌,所以如果出現generateID相對前一條日誌變小的情況,說明這是一條「幽靈復現」日誌(它的generateID會小於StartWorking日誌),要忽略掉這條日誌。
第三態問題也是我們之前經常講的問題, 其實在網路系統裡面, 對於一個請求都有三種返回結果
前面兩種狀態由於服務端都有明確的返回結果, 所以非常好處理, 但是如果是第三種狀態的返回, 由於是超時狀態, 所以服務端可能對於這個命令是請求是執行成功, 也有可能是執行失敗的, 所以如果這個請求是一個寫入操作, 那麼下一次的讀取請求可能讀到這個結果, 也可能讀到的結果是空的
就像在 raft phd 那個論文裡面說的, 這個問題其實是和 raft/multi-paxos 協議無關的內容, 只要在分散式系統裡面都會存在這個問題, 所以大部分的解決方法是兩個
那麼對應於raft 中的第三態問題是, 當最後log Index 為4 的請求超時的時候, 狀態機中出現的兩種場景都是可能的
對應於幽靈問題, 其實是由於6-10 的操作產生了超時操作, 由於產生了超時操作以後, client 並沒有對這些操作進行確認, 而是接下來去讀取這個結果, 那麼讀取不到這個裡面的內容, 由於後續的寫入和切主操作有重新能夠讀取到這個6-10 的內容了, 造成了幽靈復現, 導致這個問題的原因還是因為沒有進行對超時操作的重確認.
那麼Raft 有沒有可能出現這個幽靈復現問題呢?
其實在早期Raft 沒有引入新的Leader 需要寫入一個包含自己的空的Entry 的時候也一樣會出現這個問題
Log Index 4,5 客戶端超時未給用戶返回, 存在以下日誌場景
其實這個問題的本質是對於一致性協議在recovery 的不同做法產生的. 關於一致性協議在不同階段的做法可以看這個文章 http://baotiao.github.io/2018/01/02/consensus-recovery/
也就是說對於一個在多副本裡面未達成一致的Log entry, 在Recovery 需要如何處理這一部分未達成一致的log entry.
對於這一部分log entry 其實可以是提交, 也可以是不提交, 因為會產生這樣的log entry, 一定是之前對於這個client 的請求超時返回了.
常見的Multi-Paxos 在對這一部分日誌進行重確認的時候, 默認是將這部分的內容提交的, 也就是通過重確認的過程默認去提交這些內容
而Raft 的實現是默認對這部分的內容是不提交的, 也就是增加了一個當前Term 的空的Entry, 來把之前leader 多餘的log 默認不提交了, 幽靈復現裡面其實也是通過增加一個空的當前Leader 的Proposal ID 來把之前的Log Entry 默認不提交
所以這個問題只是對於返回超時, 未達成一致的Log entry 的不同的處理方法造成的.
在默認去提交這些日誌的場景, 在寫入超時以後讀取不到內容, 但是通過recovery 以後又能夠讀取到這個內容, 就產生了幽靈復現的問題
但是其實之所以會出現幽靈復現的問題是因為在有了一個超時的第三態的請求以後, 在沒有處理好這個第三態請求之前, 出現成功和失敗都是有可能的.
所以本質是在Multi-Paxos 實現中, 在recovery 階段, 將未達成一致的Log entry 提交造成的幽靈復現的問題, 本質是沒有處理好這個第三態的請求。
一站式開發者服務,海量學習資源0元起!
阿里熱門開源項目、機器學習乾貨、開發者課程/工具、小微項目、移動研發等海量資源;更有開發者福利Kindle、技術圖書幸運抽獎,100%中--》https://www.aliyun.com/acts/product-section-2019/developer?utm_content=g_1000047140
本文作者:陳宗志
原文鏈接
更多技術乾貨敬請關注云棲社區知乎機構號:阿里云云棲社區 - 知乎
本文為雲棲社區原創內容,未經允許不得轉載。