相關理論：
在聊分布式環境下數據一致性問題之前我們先看一個理論（事務的ACID一定要知道的）CAP理論：
CAP理論由加州大學伯克利分校的計算機教授Eric Brewer在2000年提出，其核心思想是任何基於網絡的數據共享系統最多只能滿足數據一致性(Consistency)、可用性(Availability)和網絡分區容忍(Partition Tolerance)三個特性中的兩個，三個特性的定義如下：
C數據一致性：等同於所有節點擁有數據的最新版本
A可用性：數據具備高可用性
P分區容忍：容忍網絡出現分區，分區之間網絡不可達
在大規模的分布式環境下，網絡分區是必須容忍的現實，於是只能在可用性和一致性兩者間做出選擇。 CAP理論帶來的價值是指引我們在設計分布式系統時需要區分各種數據的特點，並仔細考慮在小概率的網絡分區發生時究竟為該數據選擇可用性還是一致性。
我們本次聊的是數據一致性，所以一切前提是CP。並且以資金賬戶解凍為例。
場景分類：
數據一致性場景大致可以分為弱一致性，強一致性。
所謂的弱一致性，就是有可能在某個時刻數據非一致，但是到達某個時間點以后總能保持一致，也即我們所說的最終一致性。 而強一致性就是需要保證數據的一致性是實時的，每一時刻都保持一致。
解決方案總結：
弱一致性的解決方案：
- 由外圍系統重試，自身實現冪等，保證最終一致性。
比如用戶解凍功能，后台web界面提供重試按鈕，第一次操作可能解凍沒有成功。用戶可以不停的點擊直到解凍成功，自身業務系統只要實現冪等即可。
該方案設計簡單，業務系統不用太關心一致性的問題，只要自身系統實現業務冪等即可，無耦合性。
2. 依賴於事務型消息，通過消息重試，保證最終一致性。
上層業務無重試，無補償，只能依賴於系統自身保證一致性。可以在完成合約解凍結之后，發送事務型消息，只要消息發送和合約解凍成功即可返回外圍系統成功。后邊賬務的解凍依賴於消息中心的消息投遞，如果失敗，消息中心會由重試機制直到成功。如果業務推進不下去的化，需要人工接入。
該方案設計相對簡單，只需要在原有流程中加入發送消息的邏輯，賬務那邊數據的保證交給消息中心去搞定。但是自身系統需接入消息中心，被調用方需要實現業務冪等，增加消息中心的耦合依賴。自身無法控制投遞規則。
- 依賴於調度任務，通過調度任務重試，保證最終一致性。
上層業務無重試，無補償，只能依賴於系統自身保證一致性。可以在完成合約解凍結之后，本地落地一張異步任務表。由定時任務定時掃描去調用賬務進行解凍。
該方案對比依賴於消息中心的方案主要區別點在於失敗后的數據落地在本系統內，不是消息中心，系統需增加一步任務表。自身能夠完全掌握待恢復的數據，是否重試，是否終止都由自身系統決定，靈活性增加了。減少了消息中心的耦合，但是會增加調度中心的依賴。
強一致性的解決方案：
1. 引入協調者：
強一致性的解決依賴於中間協調者，中間協調者能夠從全局把控該次業務涉及到的哪幾系統。是否都成功了，是否存在部分失敗，最終要提交還是要回滾。
已有的理論就是2PC兩階段提交理論。我自己理解的兩階段是這樣的。
（發起方：發起分布式事務的系統。 參數者：被調用的系統）
第一階段： 准備階段。
發起方問參與者們你們可以提交嗎？ 參與者通常在本地事務試着提交一把，通常的做法就是設置中間表，將數據先寫入中間表，如果寫入成功，那么意味着我是可以提交了。
第二階段：提交階段。
發起方告訴協調者，好了參與者們都可以提交了，我先提交本地事務，你再去提交（或者回滾）他們的事務吧。
通過第一階段的試提交，保證了整個分布式事務在第二階段的成功率，使得如果出現不可提交的情況的時候能夠及早發現及早回滾。可提交的情況下，能夠保證正確提交。
該方案能夠解決強一致性的需求，但是需要大量的接入成本。業務系統耦合兩階段框架，參與者系統需要保證冪等，增加中間表，並且實現二階段提交回滾的方法供協調者調用。
總結：
業務上應該視業務需求考慮是需要強一致性還是弱一致性，然后再根據自身情況考慮選取哪種方案更加適合自己。以上分析都是基於自己的理解進行的總結，只是從宏觀上進行了表達，里面還有很多細節需要探索。其中可能存在着某些錯誤，如果有請各位一定指出，互相學習。