- 剛性事務總結 -
在《分佈式架構之設計篇-剛性事務之2PC詳解》和《分佈式架構之設計篇-剛性事務之3PC詳解》二文中分析了分佈式事務的本質、XA、2PC、3PC等等。但是沒有說分佈式事務的現象或者場景，我總結了分佈式事務的觸發場景大約有以下幾種：
1、跨數據庫分佈式事務：數據庫的物理分割下保障跨庫操作的ACID。
2、跨服務分佈式事務：服務的網絡分割下保障多服務的事務完整性。
3、混合式分佈式事務：跨數據庫分佈式事務 + 跨服務分佈式事務。
最根本的原因就是事務參與者出現在不同的網絡中，需要網絡通訊進行交互，因此不可避免的出現失敗、超時等情況，所以需要分佈式事務來處理。
前面也大體說了下事務的解決方案，接下來咱們先來個完整的結論：業務規避 > BASE柔性事務 > CP剛性事務。剛性事務已經介紹過了，因爲追求CP，通常使用在金融等強一致性場景的行業。剛性事務首先有XA規範，這個XA規範的實現方案是2PC，業界開源框架有Atomikos、Bitronix、Seata XA模型及各大數據庫廠商對XA的落地。
目前國內對剛性事務使用最廣泛的是螞蟻金服的2PC，但是並不開源。不夠我們可以從Seata XA模型去看到一部分螞蟻2PC的影子。Seata XA模型是1.2版本推出的新功能，目前並不是很成熟，建議可以先觀望下。
- XA規範 -
XA規範定義將事務參與者分成了TM、AP、RM三個角色。XA規範要求事務資源(如數據庫) 本身提供對規範和協議的支持，這樣的好處是如下：
1、可以從任何角度保證數據的隔離。
2、實現數據的全局一致性。
3、對業務無侵入。
XA規範將事務機制落地到事務資源上,在落地上使用的是XAConnection和 XADataSource。XA開源框架都是從這入手的，但是從職責上去區分，XAConnection 和 XADataSource屬於數據庫的驅動範圍內，如果框架自己去實現，無法保證數據庫的兼容完整性。最佳的實踐需要事務資源(如數據庫) 本身提供對規範和協議的支持。Seata XA模型也是如此，不夠Seata 官方承諾保證 提供的驅動程序是經過充分測試的；再加上一個場外因素-阿里多年的實踐經驗，因此還是可以期待。
XA 框架通過connection通訊層面去處置事務機制，避免了SQL的相關處理、也利用了數據庫內部XA實現，因此最能保障 數據全局一致性。但是XA規範在1994年就出現了，至今沒有大規模流行起來，必然有他一定的缺陷：
1、數據鎖定：數據在事務未結束前，爲了保障一致性，根據數據隔離級別進行鎖定。
2、協議阻塞：本地事務在全局事務 沒 commit 或 callback前都是阻塞等待的。
3、性能損耗高：主要體現在事務協調增加的RT成本，併發事務數據使用鎖進行競爭阻塞。
- 柔性事務 -
剛性事務都是CP的，所以不可避免的面臨性能有上限，無法滿足超高量級的互聯網場景。因此出現了柔性事務，相比較與數據庫事務中的ACID這種剛性事務來說，柔性事務本質是對XA協議的妥協，它通過降低強一致性要求，從而降低數據庫資源鎖定時間，提升可用性。這其實就是基於BASE理論，保證數據的最終一致性。
-
Basically Available-基本可用
-
Soft state-柔性狀態
-
Eventual consistency-最終一致性
基本可用指分佈式系統出現不可知故障時，允許損失部分可用性。具體表現爲，一響應時間的損失：出現故障後，通過延長響應(服務重試其他提供者)來保障可用性；二功能上的損失：流量高峯時，通過服務降級、限流等治理手段提供有損服務。
柔性狀態指允許系統的數據存在中間狀態，並認爲中間狀態的存在不影響系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。
最終一致性指系統中所有的數據副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終數據能夠達到一致，而不需要實時保證系統數據的強一致性。
柔性事務主要分爲補償型和通知型。補償型事務又分TCC、Saga，通知型事務分MQ事務消息、最大努力通知型。補償型事務都是同步的，通知型事務都是異步的，所以有時可以聽到另外一種劃分。
作者介紹
孫玄
畢業於浙江大學，奈學教育創始人兼CEO，前轉轉公司技術委員會主席，前58集團技術委員會主席，前百度資深研發工程師，騰訊雲TVP，阿里雲MVP，在線直播大課《百萬架構師》品牌創始人。
林淮川
畢業於西安交通大學；前大樹金融高級架構師；前大樹金融技術委員會開創者；前大樹金融供應鏈金融技術總監；前天陽宏業交易事業部技術主管；多年互聯網金融行業（ToB）經驗。