--插一句, 在寫這個東東的時候, 發現我發的那個 dynamo 簡介中, 關於 w n r 模型的一致性說明是有錯誤的, 在那個文章裡加了個注釋. 因為沒有原始碼可看, 很多東西只能靠自己的理解來寫了, 請發現問題的同學不吝指出, 謝謝.
最近聊天時, 有些同學提出用兩階段提交來實現分布式系統中的一致性. 下面以 dynamo 為例子, 說說我的理解.
首先看兩階段提交, 它是為了在分布式的資料庫保證資料的一致性而採用的一種策略. 簡單舉乙個例子, 比如乙個事務,涉及到資料庫a中的一些改動, 又涉及到資料庫b中的一些改動. 那麼需要提交的時候如何操作呢? 假設不採用兩階段提交, 我們要先提交乙個資料庫,比如a, 然後再提交第二個,比如b. 但是如果a提交成功, b提交失敗, 這個時候一致性沒有了, 因為a是無法回滾的. 都哪些原因可以引起提交失敗呢? 很多的, 比如一些約束上的衝突, 比如各種日誌寫失敗, 網路失敗, 甚至斷電等等. 兩階段提交如何解決這個問題呢, 簡單的說, 兩階段提交把提交過程分成兩個階段(這句是廢話), 首先進行預提交, 資料庫完成各種約束檢查啊, 日誌寫入等工作. 資料庫承諾, 預提交成功了, 正式提交一定成功.但是預提交畢竟不是提交, 是可以回滾的. 所以如果有某個資料庫預提交失敗, 我們可以對所有的庫回滾掉整個事物. 如果預提交成功, 則進入第二階段, 正式提交. 插一句,兩階段提交可能會需要乙個分布鎖, 用來保證在提交過程中, 相關的資料不可讀寫, 從而消除違反一致性的時間窗. 這個分布鎖跟我們要說的關係不大, 不討論了. 那麼兩階段提交完全解決了分布式系統的一致性問題了嗎? 不是的. 在正式提交階段如果發生錯誤, 比如a提交成功, b網路連線斷掉, 這個時候事物處於錯誤的狀態. 很多時候, 出現這樣的問題是需要dba介入的. 兩階段提交只是把導致事物失敗的危險期縮小到第二個階段, 因為第二階段資料庫要做的事情很少,時間很短,可以認為那個階段幾乎不可能出錯誤.
那麼如果我們來實現 dynamo 是否可以從兩階段提交中吸取營養呢? 我各人認為意義不大. 為了便於討論, 讓我們的 dynamo 例項採取 n=3 w=3 r=1的配置. 這個配置, dynamo的承諾是, 寫要寫三個節點都成功才算是成功, 讀可以只從乙個節點來讀. 兩階段提交不大適用的原因, 我認為有這麼幾個.1 節點之間的互動太多, 效率不夠. 2 寫操作太過頻繁, 加之網路問題是經常出現的, 所以第二階段的失敗成為一種正常事件, 這個失敗又無法自動恢復. 對於第二點, 也許有人會提出, 發現某個節點提交失敗則對其餘節點做乙個反向操作. 我們暫且認為這個反向操作不會失敗(實際上這個也是可能失敗的), 那麼在其餘節點收到反向操作以前, 從該節點的讀操作會讀到update後的資料, 反向操作後, 這部分資料消失了.也就是說, 會有人讀到髒資料. 這個問題對大部分應用來說是比讀到舊資料嚴重得多的問題. 注意, 這裡沒討論分布式鎖的解決方案, 那個效率太差了, 不可接受.
下面看看 dynamo 如何處理這個問題的. 首先要明確的是, dynamo 保證的是最終一致性, 就是說, 如果乙個更新操作正確的完成了, dynamo 不保證所有的讀操作都立刻能讀到最新資訊. 我們看看具體實現就明白了為什麼是這個行為. 具體內容請看原** 4.6 hadling failures: hinted handoff 這裡簡單說一下:dynamo有一層叫做coordinator, 是可以放到任意位置的, 我們假設放到了客戶端. 那麼乙個寫操作, coordinator 會根據一致性雜湊演算法選擇三個節點(不妨設為 a b c), 同時發三個寫操作的包, 然後等候回應. 假設規定時間內, 只有兩個節點返回成功(不妨設為a b), 也就是說, 第三個節點沒成功, 這個時候coordinator會再選擇乙個不同與上面三個的第四個節點, 發出寫操作, ...直到寫成功為止(不妨設這個節點是x). 這樣保證了備份數. 額外被選擇的節點(x)儲存這個資料資訊到乙個單獨的目錄中, x節點負責不斷的嘗試把這部分資料寫回到c節點. 這個過程叫做 hinted handoff. 在這樣的策略下, 因為r=1, 讀任何乙個節點都是有效的, 假設客戶讀節點 a b, 那麼讀到的都是最新資料, 如果讀節點c, 可能讀到老的資料. 但是無論如何讀不到髒資料. 因為在可期望的時間內, 所有的節點上的資料可以達到一致, 所以這種一致性叫做最終一致性.
0
給主人留下些什麼吧！~~
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
最終一致性方案
訊息傳送一致性 微服務架構下，需要通過網路進行通訊，就自然引入了資料傳輸的不確定性，也就是cap原理中的p 分割槽容錯，而這裡的訊息傳送一致性是可靠訊息的保證。生成訊息的業務動作與訊息傳送的一致 e.g 如果業務操作成功，那麼由這個業務操作所產生的訊息一定會成功投遞出去，否則就丟失訊息 如上圖，保證...
CAP原理與最終一致性 強一致性 透析
在足球比賽裡，乙個球員在一場比賽中進三個球，稱之為帽子戲法 hat trick 在分布式資料系統中，也有乙個帽子原理 cap theorem 不過此帽子非彼帽子。cap原理中，有三個要素 cap原理指的是，這三個要素最多只能同時實現兩點，不可能三者兼顧。因此在進行分布式架構設計時，必須做出取捨。而對...