分佈式環境下數據一致性的設計總結

相關理論：

在聊分佈式環境下數據一致性問題以前咱們先看一個理論（事務的ACID必定要知道的）CAP理論：

CAP理論由加州大學伯克利分校的計算機教授Eric Brewer在2000年提出，其核心思想是任何基於網絡的數據共享系統最多隻能知足數據一致性(Consistency)、可用性(Availability)和網絡分區容忍(Partition Tolerance)三個特性中的兩個，三個特性的定義以下：

C數據一致性：等同於全部節點擁有數據的最新版本

A可用性：數據具有高可用性

P分區容忍：容忍網絡出現分區，分區之間網絡不可達

        在大規模的分佈式環境下，網絡分區是必須容忍的現實，因而只能在可用性和一致性二者間作出選擇。 CAP理論帶來的價值是指引咱們在設計分佈式系統時須要區分各類數據的特色，並仔細考慮在小几率的網絡分區發生時究竟爲該數據選擇可用性仍是一致性。

       咱們本次聊的是數據一致性，因此一切前提是CP。而且以資金帳戶解凍爲例。

 

場景分類：

 

數據一致性場景大體能夠分爲弱一致性，強一致性。

所謂的弱一致性，就是有可能在某個時刻數據非一致，可是到達某個時間點之後總能保持一致，也即咱們所說的最終一致性。 而強一致性就是須要保證數據的一致性是實時的，每一時刻都保持一致。

 

解決方案總結：

 

弱一致性的解決方案：

 

1. 由外圍系統重試，自身實現冪等，保證最終一致性。

好比用戶解凍功能，後臺web界面提供重試按鈕，第一次操做可能解凍沒有成功。用戶能夠不停的點擊直到解凍成功，自身業務系統只要實現冪等便可。

 

該方案設計簡單，業務系統不用太關心一致性的問題，只要自身系統實現業務冪等便可，無耦合性。

 

2. 依賴於事務型消息，經過消息重試，保證最終一致性。

       上層業務無重試，無補償，只能依賴於系統自身保證一致性。能夠在完成合約解凍結以後，發送事務型消息，只要消息發送和合約解凍成功便可返回外圍系統成功。後邊帳務的解凍依賴於消息中心的消息投遞，若是失敗，消息中心會由重試機制直到成功。若是業務推動不下去的化，須要人工接入。

 

       該方案設計相對簡單，只須要在原有流程中加入發送消息的邏輯，帳務那邊數據的保證交給消息中心去搞定。可是自身系統需接入消息中心，被調用方須要實現業務冪等，增長消息中心的耦合依賴。自身沒法控制投遞規則。

 

1. 依賴於調度任務，經過調度任務重試，保證最終一致性。

上層業務無重試，無補償，只能依賴於系統自身保證一致性。能夠在完成合約解凍結以後，本地落地一張異步任務表。由定時任務定時掃描去調用帳務進行解凍。

 

       該方案對比依賴於消息中心的方案主要區別點在於失敗後的數據落地在本系統內，不是消息中心，系統需增長一步任務表。自身可以徹底掌握待恢復的數據，是否重試，是否終止都由自身系統決定，靈活性增長了。減小了消息中心的耦合，可是會增長調度中心的依賴。

 

強一致性的解決方案：

    

1. 引入協調者：

強一致性的解決依賴於中間協調者，中間協調者可以從全局把控該次業務涉及到的哪幾系統。是否都成功了，是否存在部分失敗，最終要提交仍是要回滾。

       已有的理論就是2PC兩階段提交理論。我本身理解的兩階段是這樣的。

       （發起方：發起分佈式事務的系統。 參數者：被調用的系統）

第一階段： 準備階段。

發起方問參與者們大家能夠提交嗎？ 參與者一般在本地事務試着提交一把，一般的作法就是設置中間表，將數據先寫入中間表，若是寫入成功，那麼意味着我是能夠提交了。

第二階段：提交階段。

發起方告訴協調者，好了參與者們均可以提交了，我先提交本地事務，你再去提交（或者回滾）他們的事務吧。

 

經過第一階段的試提交，保證了整個分佈式事務在第二階段的成功率，使得若是出現不可提交的狀況的時候可以及早發現及早回滾。可提交的狀況下，可以保證正確提交。

 

該方案可以解決強一致性的需求，可是須要大量的接入成本。業務系統耦合兩階段框架，參與者系統須要保證冪等，增長中間表，而且實現二階段提交回滾的方法供協調者調用。

 

總結：

業務上應該視業務需求考慮是須要強一致性仍是弱一致性，而後再根據自身狀況考慮選取哪一種方案更加適合本身。以上分析都是基於本身的理解進行的總結，只是從宏觀上進行了表達，裏面還有不少細節須要探索。其中可能存在着某些錯誤，若是有請各位必定指出，互相學習。