几种分布式事务实现方案
目錄
?
CAP（Consistency、Availability、Partition Tolerence）理論
BASE理論
2PC兩階段提交方案/XA方案
TCC方案
可靠消息最終一致性方案
最大努力通知方案
CAP（Consistency、Availability、Partition Tolerence）理論
一、一致性（C）
就是說一個分布式系統中，一旦你做了一個數據的修改，那么這個操作成功的時候，就必須是分布式系統的各個節點都是一樣的。
例如客戶端發起一個數據修改的請求，然后服務器返回成功了，結果去查的時候，從某個節點上查詢數據，發現這個數據不對，這樣的話就成了數據不一致了，就是分布式系統的各個節點上的數據是不一樣的，也就是所謂的強一致性。
弱一致性，就是更新數據后，不確定各個節點間是否都更新成功；最終一致性，就是更新后，一段時間內不一致，但是最后過了一段時間各個節點間都更新成功。
二、可用性（A）
就是說分布式系統必須是可用的
三、分區容錯性（P）
布式系統在遇到任何網絡分區故障的時候，仍然需要能夠保證對外提供滿足一致性和可用性的服務。
四、CP
經典的就是一些分布式存儲，比如說zookeeper、mongodb、hbase等等，跟他們都是CP的，也就是說數據100%一致，但是有可能有些時候你請求是失敗的，不讓你請求到不一致的數據，這就是CP。
五、AP
如果網絡故障，數據沒同步，數據處于不一致的狀態下，要保證A，可用性，你兩個節點都要允許任何客戶端來查詢，都可以查到，這樣的話呢，整個系統就處于可用的狀態下，但是此時就犧牲掉了C。
對于12306、電商系統，這種業務類系統，一般都是AP，也就是說，你可能看到的商品庫存或者火車票的庫存，是錯的，有可能是舊的啊，那么數據很可能看到的都是不一致的，但是呢，你買東西或者買票的時候，一定會檢查庫存，就可以了，但是保證了可用性，任何時候都要響應結果。
?
BASE理論
所謂的BASE，Basicly Available、Soft State、Eventual Consistency，也就是基本可用、軟狀態、最終一致性。
BASE希望的是，CAP里面基本都可以同時實現，但是不要求同時全部100%完美的實現，CAP三者同時基本實現，BASE，基本可用、最終一致性
此時要保證基本可用性，兩個節點都可以查詢的，但是這個時候會發現有的節點可以返回數據，有的節點無法返回數據，會看到不一致的狀態，這個不一致的狀態，就是指的是BASE中的S，soft state，軟狀態；
基本可用，降級，正常情況下，是查詢可以負載均衡到各個節點去查的，也就是可以多節點抗高并發查詢，但是此時如果你要降級的話，可以降級為，所有客戶端強制查詢主節點，這樣看到的數據暫時而言都是一樣的，都是從主節點去查。因為客戶端訪問量太大了，同時用一個主節點來支撐很坑，扛不住，怎么辦呢，主節點做限流降級，也就是說如果流量太大了，直接返回一個空，讓你稍后再來查詢；
最終一致性，一旦故障或者延遲解決了，數據過了一段時間最終一定是可以同步到其他節點的，數據最終一定是可以處于一致性的。
?
2PC兩階段提交方案/XA方案
將事務的提交過程分成提交事務請求和執行事務提交兩個階段進行處理。這種分布式事務方案，比較適合單塊應用里，跨多個庫的分布式事務，而且因為嚴重依賴于數據庫層面來搞定復雜的事務，效率很低，不適合高并發的場景。
?
TCC方案
try接口里是鎖定資源，confirm是業務邏輯，cancel是回滾邏輯
try接口里，一般就是預留資源，比如說經典的資金轉賬，卡掉一些鎖定資金，要是不這么控制，萬一別的分布式事務給干掉了一些資金，那么實際執行confirm的時候一旦檢查資金余額就會發現轉賬失敗，余額不足了；有些接口，沒有資源鎖定的操作，try接口就留空。
confirm就是原來的業務方法，執行實際的轉賬操作，A銀行賬戶的資金扣減，B銀行賬戶的資金增加。
cnacel接口，要提供回滾的方法，就是把try或者confirm里的操作給回滾。
比如說，如果是try階段，資金服務的try成功了，資金被凍結了，結果訂單服務的try失敗了，主業務服務就會通知回滾，調用資金服務的cancel接口，將凍結的金額給解凍。
confirm階段，資金服務，把錢從iA賬號里轉移到B賬號里去了，結果某一服務的confirm失敗了，整個分布式事務回滾，調用各個接口的cancel接口。
（1）、空回滾
當沒有調用參與方Try方法的情況下，就調用了二階段的Cancel方法，Cancel方法需要有辦法識別出此時Try有沒有執行。如果Try還沒執行，表示這個Cancel操作是無效的，即本次Cancel屬于空回滾；如果Try已經執行，那么執行的是正常的回滾邏輯。
（2）、倒置請求
比如調用try接口，中間網絡超時，結果認定失敗，直接調用cancel空回滾；結果過了幾秒鐘try接口請求到來，要在這個時候不允許執行try接口操作；同理，confirm請求超時了，結果都cancel掉了，但是過了幾秒請求來了，也不允許執行confirm操作。
（3）、接口的冪等性保證
try、confirm和cancel都可能被多次調用，所以得保證這幾個接口的冪等性，分布式接口冪等性那必須依賴第三方的中間件來實現，可以考慮使用經典的zk，zk非常適用于分布式系統的協調類操作。所以一個接口對同一個參數調用，只能調用一次，保證冪等操作。
?
可靠消息最終一致性方案
這個方案，適合于那那種比較耗時的操作，通過這個消息中間件做成異步調用，發送一個消息出去，由服務消費消息來執行業務邏輯。
1）A系統先發送一個prepared消息到mq，如果這個prepared消息發送失敗那么就直接取消操作；
2）如果這個消息發送成功過了，那么接著執行本地事務，如果成功就告訴mq發送確認消息，如果失敗就告訴mq回滾消息；
3）如果發送了確認消息，那么此時B系統會接收到確認消息，然后執行本地的事務；
4）mq會自動定時輪詢所有prepared消息回調接口，這個消息是不是本地事務處理失敗了，所有沒發送確認消息？那是繼續重試還是回滾？一般來說這里你就可以查下數據庫看之前本地事務是否執行，如果回滾了，那么這里也回滾吧。這個就是避免可能本地事務執行成功了，別確認消息發送失敗了。
5）這個方案里，要是系統B的事務失敗了咋辦？自動不斷重試直到成功，如果實在是不行，要么就是針對重要的資金類業務進行回滾，比如B系統本地回滾后，想辦法通知系統A也回滾；或者是發送報警由人工來手工回滾和補償
調用第三方運營商系統接口的操作，適合用可靠消息最終一致性的方案。
最大努力通知方案
跟可靠消息最終一致性方案是類似的，可靠消息最終一致性方案，會保證最終必須要讓那個執行成功的，但是最大努力通知方案，不一定保證最終一定會成功，可能會失敗，但是他會盡力給你去給你通知那個服務的執行。
比較適合那種不太核心一些服務調用的操作，比如說消息服務，充值好了以后發送短信，一般來說肯定是要發出去短信的，但是如果真的不小心發送失敗了，發送短信失敗了也無所謂的。
?
?
?
?
?
?
總結
以上是生活随笔為你收集整理的几种分布式事务实现方案的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 【英语语法】 for
- 下一篇： JQuery样式