一個複雜的系統往往都是從一個小而簡的系統發展衍化而來，為了滿足日益增長的業務需求，不斷的增加系統的複雜度，從單體架構逐步發展為分佈式架構，而分佈式系統架構的設計主要關注：高性能，高可用，高拓展。
分佈式事務
高可用是指系統無中斷的執行功能的能了，代表了系統的可用程度，是進行系統設計時必須要遵守的準則之一。
而高可用的實現方案，無外乎就是冗餘，就存儲的高可用而言，問題不在於如何進行數據備份，而在於如何規避數據不一致對業務造成的影響。
對於分佈式系統而言，要保證分佈式系統中的數據一致性就需要一種方案，可以保證數據在子系統中始終保持一致，避免業務出現問題，這種實現方案就叫做分佈式事務，要麼一起成功，要麼一起失敗，必須是一個整體性的事務。
舉個例子：
在電商網站中，用戶對商品進行下單，需要在訂單表中創建一條訂單數據，同時需要在庫存表中修改當前商品的剩餘庫存數量，兩步操作一個添加，一個修改，我們一定要保證這兩步操作一定同時操作成功或失敗，否則業務就會出現問題。
建立時：
業務量不大，用戶少，系統只是一個單體架構，訂單表與庫存表都在一個數據庫中，這時可以使用MySQL的本地事務保證數據一致性。
發展期：
業務發展迅速，用戶量變多，單數據已經出現了性能瓶頸，按照業務緯度進行分庫，分為訂單庫和庫存庫，由於跨庫跨機器，MySQL的本地事務不能再保證訂單庫和庫存庫的數據一致性，這時候就需要分佈式事務來保證。
成熟期：
業務拓展，單體架構已經滿足不了需求，進而衍化成了分佈式系統，這時的訂單和庫存已經拆分為了兩個子系統提供服務，子系統間使用RPC進行通信，但是無論系統發展成什麼樣，我們都要保證業務不出問題，保證訂單和庫存的數據一致，這時候要思考下在服務之間我們應如何保證數據一致。
理論基礎
在講解具體方案之前，有必要了解一下分佈式中數據設計需要遵循的理論基礎，CAP理論和BACS理論，為後面的實踐鋪平道路。
CAP理論
CAP：Consistency Acailability Partition tolerance的簡寫
- Consistency：一致性，對某個客戶端來說，讀操作能夠返回最新的寫操作結果。
- Acailability：可用性，非故障節點在合理的時間內返回合理的響應。
- Partition tolerance：分區容錯性，當出現網絡分區後，系統能夠繼續提供服務。你知道什麼是網絡分區嗎？
因為分佈式系統中系統肯定部署在多臺機器上，無法保證網絡做到100%的可靠，所以網絡分區一定存在，即P一定存在；
在出現網絡分區後，就出現了可用性和一致性的問題，我們必須要在這兩者之間進行取捨，因此就有了兩種架構：CP架構，AP架構。
CP架構
當網絡分區出現後，為了保證一致性，就必須拒接請求，否則無法保證一致性。
- 當沒有出網絡分區時，系統A與系統B的數據一致，X=1
- 將系統A的X修改為2，X=2
- 當出現網絡分區後，系統A與系統B之間的數據同步數據失敗，系統B的X=1
- 當客戶端請求系統B時，為了保證一致性，此時系統B應拒絕服務請求，返回錯誤碼或錯誤信息
上面這種方式就違背了可用性的要求，只滿足一致性和分區容錯，即CP。
CAP理論是忽略網絡延遲，從系統A同步數據到系統B的網絡延遲是忽略的。
CP架構保證了客戶端在獲取數據時一定是最近的寫操作，或者獲取到異常信息，絕不會出現數據不一致的情況。
AP架構
當網絡分區出現後，為了保證可用性，系統B可以返回舊值，保證系統的可用性。
- 當沒有出網絡分區時，系統A與系統B的數據一致，X=1
- 將系統A的X修改為2，X=2
- 當出現網絡分區後，系統A與系統B之間的數據同步數據失敗，系統B的X=1
- 當客戶端請求系統B時，為了保證可用性，此時系統B應返回舊值，X=1
上面這種方式就違背了一致性的要求，只滿足可用性和分區容錯，即AP。
CP架構保證了客戶端在獲取數據時無論返回的是最新值還是舊值，系統一定是可用的。
CAP理論關注粒度是數據，而不是整體系統設計的策略。
BASE理論
BASE理論指的是基本可用Basically Available，軟狀態Soft Stat，最終一致性Eventual Consistency，核心思想是即便無法做到強一致性，但應該可以有采用適合的方式保證最終一致性。
BASE：Basically Available Soft Stat Eventual Consistency的簡寫。
- BA：Basically Available基本可用，分佈式系統在出現故障的時候，允許損失部分可用性，即保證核心可用。
- S：Soft Stat軟狀態，允許系統存在中間狀態，而該中間狀態不會影響系統整體可用性。
- E：Consistency最終一致性，系統中的所有數據副本經過一定時間後，最終能夠達到一致的狀態。
BASE理論本質上是對CAP理論的延伸，是對CAP中AP方案的一個補充。
分佈式事務協議
前提：在單體架構中，事務的保證有MySQL實現，不用我們實現，當單個數據庫的性能出現瓶頸的時候，對數據庫進行分表分庫處理，按業務緯度將訂單和庫存的表分為兩個庫，訂單庫和庫存庫。
X/Open XA協議
XA是一個分佈式事務協議，由Tuxedo提出。XA規範主要定義了（全局）事務管理器（Transaction Manager）和（局部）資源管理器（Resource Manager）之間的接口。XA接口是雙向的系統接口，在事務管理器Transaction Manager）以及一個或多個資源管理器（Resource Manager）之間形成通信橋樑。
XA協議採用兩階段提交方式來管理分佈式事務。XA接口提供資源管理器與事務管理器之間進行通信的標準接口。
2PC：二階段提交協議
二階段提交（Two-phase Commit），是指，為了使基於分佈式系統架構下的所有節點在進行事務提交時保持一致性而設計的一種算法（Algorithm）。通常，二階段提交也被稱為是一種協議（Protocol）。在分佈式系統中，每個節點雖然可以知曉自己的操作時成功或者失敗，卻無法知道其他節點的操作的成功或失敗。當一個事務跨越多個節點時，為了保持事務的ACID特性，需要引入一個作為協調者的組件來統一掌控所有節點（稱作參與者）的操作結果並最終指示這些節點是否要把操作結果進行真正的提交（比如將更新後的數據寫入磁盤等等）。因此，二階段提交的算法思路可以概括為：參與者將操作成敗通知協調者，再由協調者根據所有參與者的反饋情報決定各參與者是否要提交操作還是中止操作。
二階段提交算法的成立基於以下假設：
- 該分佈式系統中，存在一個節點作為協調者（Coordinator），其他節點作為參與者（Cohorts）。且節點之間可以進行網絡通信。
- 所有節點都採用預寫式日誌，且日誌被寫入後即被保持在可靠的存儲設備上，即使節點損壞不會導致日誌數據的消失。
- 所有節點不會永久性損壞，即使損壞後仍然可以恢復。
二階段提交分為兩階段：
投票階段 Prepares
協調者向所有參與者詢問是否可以執行提交操作，並開始等待各參與者的響應
參與者執行事務操作，如果執行成功就返回Yes響應，如果執行失敗就返回No響應
如果協調者接受參與者響應超時，也會認為執行事務操作失敗
提交階段 Commit
1.如果第一階段匯中所有參與者都返回Yes響應，協調者向所有參與者發出提交請求，所有參與者提交事務
2.如果第一階段中有一個或者多個參與者返回No響應，協調者向所有參與者發出回滾請求，所有參與者進行回滾操作
二階段提交優點：儘量保證了數據的強一致，但不是100%一致。
缺點：
1.單點故障，由於協調者的重要性，一旦協調者發生故障，參與者會一直阻塞，尤其時在第二階段，協調者發生故障，那麼所有的參與者都處於鎖定事務資源的狀態中，而無法繼續完成事務操作
2.同步阻塞，由於所有節點在執行操作時都是同步阻塞的，當參與者佔有公共資源時，其他第三方節點訪問公共資源不得不處於阻塞狀態
3.數據不一致，在第二階段中，當協調者想參與者發送提交事務請求之後，發生了局部網絡異常或者在發送提交事務請求過程中協調者發生了故障，這會導致只有一部分參與者接收到了提交事務請求。而在這部分參與者接到提交事務請求之後就會執行提交事務操作。但是其他部分未接收到提交事務請求的參與者則無法提交事務。從而導致分佈式系統中的數據不一致
二階段提交的問題
如果協調者在第二階段發送提交請求之後掛掉，而唯一接受到這條消息的參與者執行之後也掛掉了，即使協調者通過選舉協議產生了新的協調者並通知其他參與者進行提交或回滾操作的話，都可能會與這個已經執行的參與者執行的操作不一樣，當這個掛掉的參與者恢復之後，就會產生數據不一致的問題。
3PC：三階段提交協議
三階段提交（Three-phase commit），三階段提交是為解決兩階段提交協議|的缺點而設計的。與兩階段提交不同的是，三階段提交是“非阻塞”協議。三階段提交在兩階段提交的第一階段與第二階段之間插入了一個準備階段，使得原先在兩階段提交中，參與者在投票之後，由於協調者發生崩潰或錯誤，而導致參與者處於無法知曉是否提交或者中止的“不確定狀態”所產生的可能相當長的延時的問題得以解決。
三階段提交的三個階段：
詢問階段 CanCommit
協調者向參與者發送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。
準備階段 PreCommit
協調者根據參與者在詢問階段的響應判斷是否執行事務還是中斷事務：
如果所有參與者都返回Yes，則執行事務
如果參與者有一個或多個參與者返回No或者超時，則中斷事務
參與者執行完操作之後返回ACK響應，同時開始等待最終指令
提交階段 DoCommit
協調者根據參與者在準備階段的響應判斷是否執行事務還是中斷事務：
1.如果所有參與者都返回正確的ACK響應，則提交事務
2.如果參與者有一個或多個參與者收到錯誤的ACK響應或者超時，則中斷事務
3.如果參與者無法及時接收到來自協調者的提交或者中斷事務請求時，會在等待超時之後，會繼續進行事務提交
協調者收到所有參與者的ACK響應，完成事務。
解決二階段提交時的問題
在三階段提交中，如果在第三階段協調者發送提交請求之後掛掉，並且唯一的接受的參與者執行提交操作之後也掛掉了，這時協調者通過選舉協議產生了新的協調者，在二階段提交時存在的問題就是新的協調者不確定已經執行過事務的參與者是執行的提交事務還是中斷事務，但是在三階段提交時，肯定得到了第二階段的再次確認，那麼第二階段必然是已經正確的執行了事務操作，只等待提交事務了，所以新的協調者可以從第二階段中分析出應該執行的操作，進行提交或者中斷事務操作，這樣即使掛掉的參與者恢復過來，數據也是一致的。
所以，三階段提交解決了二階段提交中存在的由於協調者和參與者同時掛掉可能導致的數據一致性問題和單點故障問題，並減少阻塞，因為一旦參與者無法及時收到來自協調者的信息之後，他會默認執行提交事務，而不會一直持有事務資源並處於阻塞狀態。
三階段提交的問題
在提交階段如果發送的是中斷事務請求，但是由於網絡問題，導致部分參與者沒有接到請求，那麼參與者會在等待超時之後執行提交事務操作，這樣這些由於網絡問題導致提交事務的參與者的數據就與接受到中斷事務請求的參與者存在數據不一致的問題。
所以無論是2PC還是3PC都不能保證分佈式系統中的數據100%一致。
解決方案
強一致性分佈式事務
單體架構多數據源，在業務開發中，肯定是先執行對訂單庫的操作，但是不提交事務，再執行對庫存庫的操作，也不提交事務，如果兩個操作都成功，在一起提交事務，如果有一個操作失敗，則兩個都進行回滾。
基於2PC/XA協議實現的JTA
我們已經知道了2PC和XA協議的原理，而JTA是Java規範，是XA在Java上的實現。
JTA（Java Transaction Manager）：
TransactionManager：常用方法，可以開啟，回滾，獲取事務。begin()，rollback()……
XAResouce：資源管理，通過Session來進行事務管理，commit(xid)……
XID：每一個事務都分配一個特定的XID
JTA主要的原理是二階段提交，當整個業務完成了之後只是第一階段提交，在第二階段提交之前會檢查其他所有事務是否已經提交，如果前面出現了錯誤或是沒有提交，那麼第二階段就不會提交，而是直接回滾，這樣所有的事務都會做回滾操作。
基於JTA這種方案實現分佈式事務的強一致性。
JTA的特點：
1.基於兩階段提交，有可能會出現數據不一致的情況
2.事務時間過長，阻塞
3.性能低，吞吐量低
實現可以使用基於JTA實現的jar包Atomikos，使用例子可以自己百度一下。
正常架構設計中是否應該出現這種跨庫的操作，我覺得是不應該的，如果過按業務拆分將數據源進行分庫，我們應該同時將服務也拆分出去才合適，應遵循一個系統只操作一個數據源（主從沒關係），避免後續可能會出現的多個系統調用一個數據源的情況。
最終一致性分佈式事務方案（柔性事務）
JTA方案適用於單體架構多數據源時實現分佈式事務，但對於微服務間的分佈式事務就無能為力了，我們需要使用其他的方案實現分佈式事務。
本地消息表
本地消息表的核心思想是將分佈式事務拆分成本地事務進行處理。
以本文中例子，在訂單系統新增一條消息表，將新增訂單和新增消息放到一個事務裡完成，然後通過輪詢的方式去查詢消息表，將消息推送到MQ，庫存系統去消費MQ。
執行流程：
1.訂單系統，添加一條訂單和一條消息，在一個事務裡提交
2.訂單系統，使用定時任務輪詢查詢狀態為未同步的消息表，發送到MQ，如果發送失敗，就重試發送
3.庫存系統，接收MQ消息，修改庫存表，需要保證冪等操作
4.如果修改成功，調用rpc接口修改訂單系統消息表的狀態為已完成或者直接刪除這條消息
5.如果修改失敗，可以不做處理，等待重試
訂單系統中的消息有可能由於業務問題會一直重複發送，所以為了避免這種情況可以記錄一下發送次數，當達到次數限制之後報警，人工接入處理；庫存系統需要保證冪等，避免同一條消息被多次消費造成數據一致。
本地消息表這種方案實現了最終一致性，需要在業務系統裡增加消息表，業務邏輯中多一次插入的DB操作，所以性能會有損耗，而且最終一致性的間隔主要有定時任務的間隔時間決定。
MQ消息事務
消息事務的原理是將兩個事務通過消息中間件進行異步解耦。
訂單系統執行自己的本地事務，併發送MQ消息，庫存系統接收消息，執行自己的本地事務，乍一看，好像跟本地消息表的實現方案類似，只是省去了對本地消息表的操作和輪詢發送MQ的操作，但實際上兩種方案的實現是不一樣的。
消息事務一定要保證業務操作與消息發送的一致性，如果業務操作成功，這條消息也一定投遞成功。
消息事務依賴於消息中間件的事務消息，基於消息中間件的二階段提交實現的，RocketMQ就支持事務消息。
執行流程：
1.發送prepare消息到消息中間件
2.發送成功後，執行本地事務
3.如果事務執行成功，則commit，消息中間件將消息下發至消費端
4.如果事務執行失敗，則回滾，消息中間件將這條prepare消息刪除
5.消費端接收到消息進行消費，如果消費失敗，則不斷重試
這種方案也是實現了最終一致性，對比本地消息表實現方案，不需要再建消息表，不再依賴本地數據庫事務了，所以這種方案更適用於高併發的場景。
最大努力通知
最大努力通知相比前兩種方案實現簡單，適用於一些最終一致性要求較低的業務，比如支付通知，短信通知這種業務
以支付通知為例，業務系統調用支付平臺進行支付，支付平臺進行支付，進行操作支付之後支付平臺會盡量去通知業務系統支付操作是否成功，但是會有一個最大通知次數，如果超過這個次數後還是通知失敗，就不再通知，業務系統自行調用支付平臺提供一個查詢接口，供業務系統進行查詢支付操作是否成功。
執行流程：
1.業務系統調用支付平臺支付接口，並在本地進行記錄，支付狀態為支付中
2.支付平臺進行支付操作之後，無論成功還是失敗，都需要給業務系統一個結果通知
3.如果通知一直失敗則根據重試規則進行重試，達到最大通知次數後，不在通知
4.支付平臺提供查詢訂單支付操作結果接口
5.業務系統根據一定業務規則去支付平臺查詢支付結果
這種方案也是實現了最終一致性。
補償事務TCC
TCC Try-Confirm-Cancel的簡稱，針對每個操作，都需要有一個其對應的確認和取消操作，當操作成功時調用確認操作，當操作失敗時調用取消操作，類似於二階段提交，只不過是這裡的提交和回滾是針對業務上的，所以基於TCC實現的分佈式事務也可以看做是對業務的一種補償機制。
TCC的三階段：
- Try階段：對業務系統做檢測及資源預留
- Confirm階段：對業務系統做確認提交，Try階段執行成功並開始執行 Confirm階段時，默認Confirm階段是不會出錯的。即：只要Try成功，Confirm一定成功
- Cancel階段：在業務執行錯誤，需要回滾的狀態下執行的業務取消，預留資源釋放
在Try階段，是對業務系統進行檢查及資源預覽，比如訂單和存儲操作，需要檢查庫存剩餘數量是否夠用，並進行預留，預留操作的話就是新建一個可用庫存數量字段，Try階段操作是對這個可用庫存數量進行操作。
比如下一個訂單減一個庫存：
執行流程：
- Try階段：訂單系統將當前訂單狀態設置為支付中，庫存系統校驗當前剩餘庫存數量是否大於1，然後將可用庫存數量設置為庫存剩餘數量-1，
- 如果Try階段執行成功，執行Confirm階段，將訂單狀態修改為支付成功，庫存剩餘數量修改為可用庫存數量
- 如果Try階段執行失敗，執行Cancel階段，將訂單狀態修改為支付失敗，可用庫存數量修改為庫存剩餘數量
基於TCC實現分佈式事務，代碼邏輯想對複雜一些，需要將原來的接口的邏輯拆分為：try，confirm，cancel三個接口的邏輯。
基於TCC實現的分佈式事務框架：
- ByteTCC：github.com/liuyangming
- tcc-transaction：github.com/changmingxi
讀完之後應該對分佈式事務有了一個大致的瞭解，在實際生產中我們要儘量避免使用分佈式事務，能轉化為本地事務就用本地事務，如果必須使用分佈式事務，還需要從業務角度多思考使用哪種方案更適合，總之行動之前多思考。
原文鏈接：https://chenmingyu.top/distributed-transaction/，作者：陳明羽
最後，小編想說：我是一名python開發工程師，
整理了一套最新的python系統學習教程，
想要這些資料的可以關注私信小編“01”即可（免費分享哦）希望能對你有所幫助
閱讀更多 Python智禪 的文章
