相關理論：

在聊分散式環境下資料一致性問題之前我們先看一個理論（事務的ACID一定要知道的）CAP理論：

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

C資料一致性：等同於所有節點擁有資料的最新版本

A可用性：資料具備高可用性

P分割槽容忍：容忍網路出現分割槽，分割槽之間網路不可達

        在大規模的分散式環境下，網路分割槽是必須容忍的現實，於是只能在可用性和一致性兩者間做出選擇。 CAP理論帶來的價值是指引我們在設計分散式系統時需要區分各種資料的特點，並仔細考慮在小概率的網路分割槽發生時究竟為該資料選擇可用性還是一致性。

       我們本次聊的是資料一致性，所以一切前提是CP。並且以資金賬戶解凍為例。

場景分類：

資料一致性場景大致可以分為弱一致性，強一致性。

所謂的弱一致性，就是有可能在某個時刻資料非一致，但是到達某個時間點以後總能保持一致，也即我們所說的最終一致性。 而強一致性就是需要保證資料的一致性是實時的，每一時刻都保持一致。

解決方案總結：

弱一致性的解決方案：

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

比如使用者解凍功能，後臺web介面提供重試按鈕，第一次操作可能解凍沒有成功。使用者可以不停的點選直到解凍成功，自身業務系統只要實現冪等即可。

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

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

       上層業務無重試，無補償，只能依賴於系統自身保證一致性。可以在完成合約解凍結之後，傳送事務型訊息，只要訊息傳送和合約解凍成功即可返回外圍系統成功。後邊賬務的解凍依賴於訊息中心的訊息投遞，如果失敗，訊息中心會由重試機制直到成功。如果業務推進不下去的化，需要人工接入。

       該方案設計相對簡單，只需要在原有流程中加入傳送訊息的邏輯，賬務那邊資料的保證交給訊息中心去搞定。但是自身系統需接入訊息中心，被呼叫方需要實現業務冪等，增加訊息中心的耦合依賴。自身無法控制投遞規則。

1. 依賴於排程任務，通過排程任務重試，保證最終一致性。

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

       該方案對比依賴於訊息中心的方案主要區別點在於失敗後的資料落地在本系統內，不是訊息中心，系統需增加一步任務表。自身能夠完全掌握待恢復的資料，是否重試，是否終止都由自身系統決定，靈活性增加了。減少了訊息中心的耦合，但是會增加排程中心的依賴。

強一致性的解決方案：

1. 引入協調者：

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

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

       （發起方：發起分散式事務的系統。 引數者：被呼叫的系統）

第一階段： 準備階段。

發起方問參與者們你們可以提交嗎？ 參與者通常在本地事務試著提交一把，通常的做法就是設定中間表，將資料先寫入中間表，如果寫入成功，那麼意味著我是可以提交了。

第二階段：提交階段。

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

通過第一階段的試提交，保證了整個分散式事務在第二階段的成功率，使得如果出現不可提交的情況的時候能夠及早發現及早回滾。可提交的情況下，能夠保證正確提交。

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

總結：

業務上應該視業務需求考慮是需要強一致性還是弱一致性，然後再根據自身情況考慮選取哪種方案更加適合自己。以上分析都是基於自己的理解進行的總結，只是從巨集觀上進行了表達，裡面還有很多細節需要探索。其中可能存在著某些錯誤，如果有請各位一定指出，互相學習。