分佈式事務一致性

1、分佈式事務產生的緣由 -  數據分區

1. 分庫分表

實際狀況：MySQL單表數據達到千萬級別後，會隨數據量增大，會出現性能降低的狀況，這時須要分表保存數據

2. 應用垂直切分（服務化）

後端按功能切分後，須要保持庫存與支付模塊的數據一致性。

2、 數據分區時的一致性問題

1. 基於ACID的分佈式事務解決方案 - XATransactionManager

A：原子性，在整個事務中的全部操做，要麼所有完成，要麼所有不作，沒有中間狀態。對於事務在執行中發生錯誤，全部的操做都會被回滾，整個事務就像從沒被執行過同樣。

C：一致性，事務必須始終保持系統處於一致的狀態，無論在任何給定的時間併發事務有多少。

I：隔離性，事務與事務之間不會互相影響，一個事務的中間狀態不會被其餘事務感知。

D：持久性，一旦事務完成了，那麼事務對數據所作的變動就徹底保存在了數據庫中

A：準備後，仍可提交與回滾

C：準備時，一致性檢查必須OK

I：提交完成前，事務結果仍然只在事務內可見

D：提交完成後，事務結果已經持久

問題

1. 準備階段的持久成本

2. 全局事務狀態的持久成本

3. 潛在故障點多

4. 準備後發生故障以後的恢復

3、解決方案

CAP原理

Consistency(一致性): 全部用戶看到一致的數據

Availability(可用性): 總能找到一個可用的數據複本

Partition(分區容忍性): 即便在系統被分區的狀況下，仍然知足上述兩點

分佈式場景下，P是必須的，A > C

BASE

BA(Basic Availability)：基本可用性

S(Soft state)：柔性狀態

E(Eventuallconsistency)：最終一致性

咱們的目標

知足用戶的一致性

1. 服務模式分類

• 可查詢服務

• 冪等服務

• tcc服務

• 可補償服務

2. 一致性解決方案 - 依賴事務日誌的恢復/補償/重試

• 可靠消息送達（冪等服務）

• tcc（tcc服務）

• 交易編排（可查詢服務、冪等服務、可補償服務）

3. 分佈式事務一致性不能僅從技術上解決

客戶充值，三方支付劃扣異常，客戶能夠直接提現

客戶提現，三方支付付款超時（成功），客戶能夠重複提現

要保護資金的安全

5、咱們的選擇

原則

1. 保護系統資金（利益）安全

2. 保持客戶體驗一致性

1. 複雜的一致性要求高的集成交易 → 交易編排 lo-process

2. 簡單的一致性要求不高的集成交易 → 可靠消息送達

3. 不選擇TCC的理由（雖然TCC是編程式，編碼方便）

• TCC的多級系統的嵌套事務很差解決

• TCC對於外部系統提供的服務要求很高，必須所有知足TCC服務要求，實際場景下不少外部服務提供方沒法提供TCC服務，而且提供方的服務也沒法很好地經過代理層封裝爲TCC服務

4. 對服務設計的要求

• 全部提供給外系統調用的服務接口，均須要記錄流水號，服務接收時插入流水，服務完成時更新流水，該流水用於提供可查詢的服務能力

• 全部調用外部系統接口的操做，均須要記錄流水，接口調用前插入流水，調用完成時更新流水，該流水用於提供交易編排時的重試、查詢和反衝

• 全部提供給外系統調用的服務接口，均系統有流水號字段，該字段在系統內部不能重複，用於提供冪等或交易重複提示的功能