面試官問到分布式事務？這樣回答就對了！
小王面試某互聯網公司高級開發崗位，介紹項目的時候，談到公司業務量和研發團隊暴增后，自己主導完成公司項目的架構升級，從傳統的單體架構升級到微服務架構，面試官接下來就問了一道經典面試題：你們架構升級過程中，分布式事務是如何解決的？請介紹一下。
看重點
主要圍繞三個大方向：
1. 事務相關概念介紹；
2. 分布式事務常見方案；
3. 柔性事務之最大努力通知型落地實現；
1.事務相關概念介紹
事務是一系列的動作,它們綜合在一起才是一個完整的工作單元,這些動作必須全部完成,如果有一個失敗的話,那么事務就會回滾到最開始的狀態,仿佛什么都沒發生過一樣。
單事務概念
應用多次數據庫操作，通過用事務進行管理，來保證ACID原則。
原子性（A）：操作這些指令時，要么全部執行成功，要么全部不執行。只要其中一個指令執行失敗，所有的指令都執行失敗，數據進行回滾，回到執行指令前的數據狀態。
一致性（C）：事務的執行使數據從一個狀態轉換為另一個狀態，事務在執行之前和之后，數據庫都必須處于一致性狀態。
隔離性（I）：在該事務執行的過程中，無論發生的任何數據的改變都應該只存在于該事務之中，對外界不存在任何影響。只有在事務確定正確提交之后，才會顯示該事務對數據的改變。其他事務才能獲取到這些改變后的數據。
持久性（D）：當事務正確完成后，它對于數據的改變是永久性的。
分布式事務概念
- 單應用內部調用（多個數據源調用，操作多個庫）以某業務的動態折扣業務場景為例：動態折扣規則-運營后臺配置（配置庫）用戶享受的動態折扣-用戶折扣記錄（按userId分片的分片庫，120個）
- 涉及多應用調用（有可能操作同一個數據源,也有可能操作不同的數據源）以某業務用戶抵扣可用優惠場景為例：用戶 -> 查詢可用優惠 -> 支付訂單 -> 調用動態折扣系統抵扣 -> 調用優惠券系統抵扣
CAP理論
C：一致性，數據一致性：強一致性、弱一致性、最終一致性。
強一致性：流程涉及的各個環節數據必須實時一致性
弱一致性：流程涉及的各個環節數據允許存在部分數據不一致
最終一致性：允許存在中間狀態，只要求經過一段時間后，數據最終是一致的
A：可用性：系統提供的服務必須一直處于可用的狀態，對于用戶的每一個操作請求總是能夠在有限的時間內返回結果。
P：分區容錯性（一定會存在）：分布式系統在遇到任何網絡分區故障時，仍然需要能夠保證對外提供滿足一致性和可用性的服務。
無法同時滿足CAP，常見組合：AP：互聯網業務 CP：金融業務
base理論
base理論是CAP理論中AP方案的延伸，核心思想是即時無法做到強一致性，但每個應用都可以根據自身業務特點，采用適當的方式來使系統達到最終一致性。
Basically Available（基本可用）Soft state（軟狀態，中間狀態）Eventually consistent（最終一致性）
2.分布式事務常見方案
分布式場景下，多個服務同時對服務一個流程，比如電商下單場景，需要支付服務進行支付、庫存服務扣減庫存、訂單服務進行訂單生成、物流服務更新物流信息等。如果某一個服務執行失敗，或者網絡不通引起的請求丟失，那么整個系統可能出現數據不一致的原因。
常見方案：
1. 設計方案盡可能規避分布式事務方案（相似的業務放在一起，不要過度拆分）
2. 強事務(CP, 低并發短事務)和柔性事務(AP，高性能)
強事務：滿足CP理論，XA協議（2PC、JTA、JTS）、3PC，但由于同步阻塞，處理效率低，適合低并發、短事務業務。
2PC：Seeta(AT)、LCN(2PC)，適合分布式系統 JTA：atomikos(適合單系統多數據源)
柔性事務：滿足AP，base理論，適合異步更新數據，并且對數據的實時性要求較低的場景，主要分為： .補償型（TCC、saga） .最大努力通知型（MQ、本地消息表） .異步確保型（MQ、本地消息表）
實現方式：TCC(seeta-tcc,lcn-tcc)、Saga（seeta-saga狀態機模式、Aop模式）、本地事務消息、事務消息MQ
互聯網業務，一般的流量比較大，涉及很多高并發場景，我們一般采用柔性事務，這樣系統的性能好。
3.柔性事務之最大努力通知型落地實現
互聯網應用最廣泛：
- 重試：通過本地消息表+job重試對賬+下游(接口冪等、提供接口的校驗)+(打印日志+告警+人工介入補償）基于本地消息表實現分布式事務基于mq實現柔性分布式事務。
- 回滾：1）程序捕獲異常，調用回滾代碼 2）發送回滾MQ，各個系統消費MQ，調用本地回滾方法。
