第一次寫文章，寫的不好，還希望大家不吝賜教。
這幾天看分佈式事務相關的知識，網上的信息都是大同小異，但總感覺理解起來比較費勁，不夠接地氣，所以自己按照自己的理解宏觀的總結了一下，因爲是純理論的，沒圖，看着可能比較累，大家包涵，文章僅代表個人觀點，不一定完全正確，如果哪裏不對希望大家能評論指正，感激不盡。
1、事務的認識
無論是單機事務還是分佈式事務，其目的都是一樣的，就是保證數據的一致性，提交了商品訂單就肯定要減少庫存也必須扣錢，否則就會有糾紛出現，至於怎麼實現數據一致性，那就方法比較多了，單機可以是數據庫事務，某些情況可能也可以是觸發器，分佈式下可以是分佈式事務也可以是可靠消息，從這個角度講現在網絡上說的分佈式事務解決方案准確來說應該是分佈式數據一致性解決方案，畢竟是有了數據一致性的需求才有了事務的解決方案而不是有了事務才保證了一致性。
2、分佈式數據一致性解決方案
在數據必須一致的情況下，有兩種情況：
第一、高時效性要求
a動作和b動作必須同時完成，比如：訂單生成了就一定要同時減庫存，否則其他人就還能買，但可能已經沒貨了，這種情況下只能使用全局事務犧牲性能保證一致性，做法有三種，一是數據庫層的XA模式，二是服務層的全局事務管理，像阿里seata的AT模式，三是TCC補償模式，三種方法的原理在後面講解
第二、低時效性要求
所謂低時效性要求其實就是a動作和b動作在保持順序的情況下不嚴格同時完成（最終一致），比如第三方話費充值，充值申請提交後我並不是特別着急知道成功沒成功，差個幾分鐘不影響啥，只要保證成功了給我把話費加上，不成功的話把錢給我返回來別讓我損失就成，這種情況下主要方法也有三種，一是用可靠消息中間件，通過可靠消息保證數據最終一致，二是使用消息中間件和本地消息表，業務處理時不發消息，通過短輪詢的方式發送消息，三是使用消息中間件和定時校對的方式，如果接收者處理消息狀態沒能反饋，發送者主動校對保證一致性，這個又叫最大努力通知，當然最大努力通知一般用在結果反饋上
3、高時效性方案介紹
2PC
兩階段提交協議，顧名思義，就是把原先的一次提交改成了兩個階段，即準備階段和提交階段，目的是爲了在準備階段就規避像網絡異常、服務異常等情況，增加提交成功率
3PC
把兩階段又擴展了一下，分成canCommit、preCommit、commit，也是爲增加提交成功率，很複雜，一般不用
2PC之XA模式
一般說的XA模式指的是支持XA協議的關係型數據庫的全局事務模式，事務管理者是數據庫，當然如果其他框架支持XA也可以併入這個全局事務，這時候事務管理者就不是數據庫而是其他的角色了
2PC之AT模式
與XA類似，事務管理者是獨立的服務，更大的一個不同點是回滾方式，通過數據庫的逆操作來回滾而不是本地數據庫事務回滾，好處是本地事務已提交不佔用資源，效率高，爲了實現數據庫逆操作使用了數據源代理模式來將操作記錄在數據庫已備回滾
2PC之TCC模式
實現比較麻煩，原理是給每個操作除了實現預備動作，提交動作，還要實現一個回滾動作，就是在業務層面處理回滾，所以靈活性最高，a操作成功b操作失敗時只需要調用a操作的回滾動作就可以保證數據一致
4、低時效性方案介紹
可靠消息
由消息中間件保證消息的可靠性，包括消息遞送的可靠性、消息存儲的可靠性、消息通知的可靠性，保證不會丟消息，如果接收者發生業務異常導致消息不能正常處理，需要發送異常消息給原發送者處理或者人工介入
本地消息表
可以通過本地事務同時處理業務邏輯和在本地保存消息，輪詢發送消息到消息中間件，發送成功時在本地修改消息狀態，接收者正常處理消息，如果有業務失敗情況發送補償消息，最好再有自動校對功能，接收方處理時應該遵循冪等性原則
最大努力通知
是原先業務的接收方通知發送方結果的一個方案，比如充話費那個，第三方提交後運營商充值，充值完成後通知第三方結果，首先是發消息通知，但消息可能具有可靠性問題，如果第三方長時間沒收到回覆會主動調用運營商接口查詢結果
一個通俗的例子
剛開始是個小商店，貨物就在後面的貨架上，一個人經營，買東西的人來說要什麼什麼東西，賣東西的幹兩件事，收錢和交付商品，兩件事是一個人乾的，這叫單機系統，很容易保證一致性，後面生意好了店開大了一個人忙不過來了分成兩個人，一個人收錢一個人交付商品，在這種場景下我們看各個方案下解決一致性。
全局事務
加入了第三個人，老闆娘，老闆娘在旁邊盯着兩個人，看是不是收了錢把貨都交了，如果收了錢交貨的時候發現沒貨了就讓收錢的把錢退了，不能坑害消費者不然人家投訴甚至砸店呢
2PC
客人來買東西，老闆娘先吼一嗓子小王、小李都在不在，兩個人如果有一個人不在，對不起生意做不了了您呆會兒再來，兩個人都答應了在呢，然後就開始正常交易，交易過程仍然受老闆娘監控
XA
原理跟2PC一樣，交易失敗時，老闆娘指揮退錢
TCC
原理跟2PC一樣，交易失敗時，老闆娘不指揮退錢了，而是告訴收錢的人，交付貨物失敗了，你看着處理下，至於怎麼處理，是收錢的人自己負責了，也許他沒退錢而是給那個人那個人加在餘額裏了，下次收錢的時候抵扣呢
可靠消息
科技進步了，買東西不用去實體店了直接網上下單了，收錢的先收錢，收到錢後把交易信息發到公屏上，交付商品的看到公屏上的交易信息準備貨物發貨，如果發現貨物沒了，就把缺貨的信息發到公屏上，收錢的看到缺貨信息，告訴買家，哎對不起沒貨了您吶，同時把錢給人家原路返回
本地消息表
仍然是線上交易，收錢的收到錢後把交易信息記在本本上就不管了了，加入一個幫手定時去看這個記賬本本，然後把信息發到公屏上，後面的流程和可靠消息一樣了
最大努力通知
適用於發送者必須知道接收者的處理結果的情況，收錢的人得知道發貨成功沒有，按正常流程，發貨的人把處理結果發到公屏上收錢的看到就行，但是害怕發貨的忘了或者什麼的沒有把結果發到公屏上，這種情況發貨的提供了一個自動查詢機，收錢的如果等了半天沒結果，就自己去自動查詢機查一下看發貨結果是啥
總結
實現分佈式數據一致性的方法有很多，也各有自己的優缺點，不能說哪一種一定好，哪一種一定不好，都要根據自己的實際業務情況來選擇，還是那句話，滿足業務的實現最簡單的就是最好的。