最近項目正在做重構，而這次重構實質上比原來更接近於SOA化和微服務的思想。對於我們金融交易來說，數據結果的准確性是重中之重。所以今天總結一下分布式事務的實現方法，下次組內周會給大家統一一下概念。
https://www.cnblogs.com/xiexj/p/8419430.html
剛性事務和柔性事務
剛性事務：嚴格遵循ACID原則（原子性、一致性、隔離性、持久性）的事務。基本上指的是本地數據庫事務。根據CAP原則，分布式下的事務都不是剛性事務。
柔性事務：遵循CAP理論或者其變種BASE理論的事務。分布式事務基本上都是柔性事務。
因為剛性事務基本上等價於本地數據庫事務，而柔性事務基本上等價於分布式事務。只是一個是按照事務嚴格性來區分，一個是按使用場景來區分。所以平時除了用來做對比，很少直接提剛性事務和柔性事務的概念。
分布式事務理論
分布式事務：在分布式環境下，各個操作步驟並不在同一台機器上，需要保證所有動作都有一個統一的結果的一組操作。
CAP原則（記得在之前的博客中多次寫過）：分布式環境下，數據一致性、服務可用性、分區容錯性三者最多只能滿足其中二者。
數據一致性（consistency）:這里的一致性是強一致性，又叫線性一致性。即一個寫操作成功，而讀出的必須是寫操作后的新數據。而寫操作失敗讀出的必須是寫操作前的舊數據。
服務可用性（availability）:所有的操作在一定時間內都能得到響應。
分區容錯性（partition-tolerance）:在網絡分區環境下，被分割的節點仍然能對外提供服務。
| 選 擇 | 說 明 |
| AP | 分隔的節點同時對外服務但不能相互通信，將導致狀態不一致，即不能滿足C |
| CP | 網絡分區的情況下為達成C，請求只能一直等待，即不滿足A |
| CA | 在一定時間內要達到節點狀態一致，要求不能出現網絡分區，則不能滿足P |
BASE理論：這是基於CAP理論權衡之后的結果。核心思想是即使無法做到強一致性，但可以使用一些技術手段達到最終一致。BASE是Basically Available(基本可用)、Soft state(軟狀態)、Eventually consistent(最終一致性)的縮寫。
分布式事務一致性實現方案
為了解決分布式一致性問題，前人在性能和數據一致性的權衡過程中總結了許多經典的協議和算法。比較著名的有：2PC、3PC、TCC、Paxos、Raft、Zab、ISR。除了這些之外，業界用的最多的其實是基於MQ實現的。
2PC（Two Phase Commit）兩階段提交:一般說的兩階段提交是基於XA協議的。另外JTA協議的也比較常見。
XA是一個分布式事務協議。它大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由數據庫實現，比如Oracle、DB2都實現了XA接口。MySQL對XA的支持不是很好。而事務管理器作為全局的調度者，負責各個本地資源的提交和回滾。
兩階段提交的優點是：原理簡單、實現方便。缺點是同步阻塞、單點問題、數據不一致。
3PC(Three Phrase Commit)三階段提交：分為CanCommit、PreCommit、Do Commit 三個階段。就是把兩階段提交的Phase 1分成兩個，預提交的時候如果有參與者返回No或者超時則中斷事務。
三階段提交的優點是降低參與者阻塞范圍，並能夠在出現單點故障后繼續達成一致。缺點是因為preCommit階段，在這個階段如果出現網絡分區，協調者無法與參與者正常通信，參與者仍然會進行實物提交，造成數據不一致。
TCC(Try-Confirm-Cancel)
Try:完成所有的檢查，預留必須資源
Confirm:使用Try階段預留的資源執行業務，如果執行出現異常，要重試
Cancel:釋放Try階段預留資源
TCC能夠對分布式事務中的各個資源進行分別鎖定，分別提交與釋放。適用於嚴格一致、執行時間短、實時性要求高的場景。
Paxos算法：之前看過《從Paxos到Zookeeper》那本書，沒怎么看明白。實現比較復雜，Zookeeper就是用這個來實現的分布式一致性。Paxos算法、Raft協議和Zab（Zookeeper Atomic Broadcast）協議都是一種通過多數投票來保證主備數據一致性的。
ISR（In-Sync Replicas）機制：Kafka使用了這個機制來保證數據一致性。ISR認為對於2f+1個副本來說，多數投票機制要求最多只能允許f個副本發生故障，如果要支持2個副本的容錯，則需要至少維持5個副本。
基本MQ實現是一種異步確保型的實現方案。將同步阻塞的事務變成異步的，避免了對數據庫事務的爭用。