首先先來看乙個物業繳費的業務場景，使用者收到繳費單之後進行繳費，分為三步，第一步扣減使用者餘額，第二步修改訂單狀態未已繳費，第三步增加物業管理金額。現在我們假設使用者餘額，訂單以及物業管理金額分別在三個不同的資料庫中，並且假定在同乙個服務中（即單服務多資料來源場景，注意與多服務多資料來源做區分，區別在於是否需要全域性的tm，文章後續介紹）
public void pay() catch (exception e)
}
因此就出現了兩階段提交協議，將原本的一步commit變成了兩步，precommit和commit，也就是簡稱的2pc（二階段提交）。
其執行偽**
public void pay() catch (exception e)
}
其實這個時候細心的同學就會有疑問，這不是和之前一樣麼，假如在執行到的時候異常，不是同樣無法被回滾嗎？
但是由於真正的commit操作只是乙個commitrecord操作，已經使出錯的概率大大降低了，因此通常發生異常概率極低。但是極低概率也是有概率，這也是xa協議所不完善的地方。
由於2pc存在這麼多問題，因此就誕生了3pc也就是三階段提交，在2pc的precommit基礎上又新增了cancommit階段。
那麼加入的這個cancommit到底解決了什麼問題呢。
另外實際上效能問題也只是在事務rollback比較頻繁的場景下才有優勢，如果事務本身rollback機率不高，3pc相比與2pc多了一步操作，實際上效能反而更低（至少多一次請求來回）。
注：其實對於單點問題，如果外掛程式協調者，也就是說加協調者抽離出服務本身，使得協調者服務本身是乙個高可用服務也就能解決單點問題了
無論是2pc還是3pc實際上它追求的仍然是事務的acid的強一致性，也就導致了它無論從效能吞吐量還是使用場景上都非常的有限（jta）,並不適用真正的微服務場景（追求的是最終一致性，也就是base）。但是也有許多對xa的改良協議和實現框架，使得其適用與微服務場景，如seata的at模式。at模式實際上也是2pc協議的改良，我們還是從下面三個方面來簡單了解一下。
先看下官網的架構圖
但是世界上沒有免費的午餐，at模式也是有它的缺點的，也就是犧牲了隔離性（及時隔離級別是可重複讀）。其實這個也是顯而易見的，因為本地事務在precommit階段已經提交了，能被其他事務查詢以及修改，這樣就沒有隔離性可言了，同時當這個資料被修改之後也無法通過回滾sql去回滾了。seata為了解決這個問題引入了全域性鎖（global lock其實可以理解為是一種分布式鎖），在執行事務之前必須要先獲得全域性鎖，因此at模式在高併發場景下效能表現也並不好。
分布式 （XA）事務
在談到 xa規範之前，必須首先了解分布式事務處理 distributed transaction processing dtp 的概念。transaction 即事務，又稱之為交易，指乙個程式或程式段，在乙個或多個資源如 資料庫 或檔案上為完成某些功能的執行過程的集合。分布式事務處理是指乙個事務可能...
分布式事務XA
當資料庫單錶一年產生的資料超過1000w，那麼就要考慮分庫分表，具體分庫分表的原理在此不做解釋，以後有空詳細說，簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候，如果乙個操作既訪問01庫，又訪問02庫，而且要保證資料的一致性，那麼就要用到分布式事務。所謂的soa化，就是業務的服務化。比如原來單機...
XA 分布式事務
在談到 xa 規範之前，必須首先了解分布式事務處理 distributed transaction processing dtp 的概念。transaction 即事務，又稱之為交易，指乙個程式或程式段，在乙個或多個資源如資料庫 或檔案上為完成某些功能的執行過程的集合。分布式事務處理是指乙個事務可能...