業務場景
電商業務
上圖是一個電商系統，當一個訂單支付完成後的業務場景：
- 更改訂單的狀態為 “已支付”
- 扣減商品庫存
- 給會員增加積分
- 建立出庫單通知倉庫發貨
想象一下，當訂單支付完成後，個人積分延遲幾分鐘變更，這可以接受嗎？
火車票購票
想想生活中火車票購票場景。
想象一下，當最後一張火車票同時被兩個人購買，去檢票口檢票時被告知車票無效，這可以接受嗎？
銀行轉賬
想想生活中銀行轉賬場景。
想象一下，當銀行轉賬時，轉賬成功後，自己賬戶金額減少了，對方賬戶卻一直未進賬，這可以接受嗎？
關於上述的三種業務需求場景，你是怎麼理解和處理的？
在處理上述問題之前，我們們先來理解以下幾個概念。
什麼是事務？
事務是指作為單個邏輯工作單元執行的一系列操作，要麼完全地執行，要麼完全地不執行。
資料庫事務大家肯定都很熟悉，在開發過程中會經常使用到。
事務的特性
- Atomicity(原子性)
- Consistency(一致性)
- Isolation(隔離性)
- Durability(永續性)
原子性 是指事務中的操作要麼都不做，要麼就全做。
一致性 是指事務必須是使資料庫從一個一致性狀態變到另一個一致性狀態。
隔離性 是指一個事務的執行不能被其他事務干擾。
永續性 是指一個事務一旦提交，它對資料庫中資料的改變就應該是永久性的。
什麼是分散式事務？
分散式事務是指一次大的操作由不同的小操作組成的，而這些小的操作分佈在不同的伺服器上，分散式事務需要保證這些小操作要麼完全地執行，要麼完成地不執行。
產生分散式事務的原因
- 業務的微服務化，例如：文章開頭所描述的電商業務場景。
- 資料庫分庫分表，例如：當發生資料庫分庫分表後，有一個需求既要操作 01 庫，又要操作 02 庫。
分散式理論
CAP 理論
- Consistency(一致性)
- Availability(可用性)
- Partition tolerance(分割槽容錯性)
一致性 是指資料的強一致性，如果在某個節點更新了資料，那麼在其他節點需要同時看到更新後的資料。
可用性 是指每個請求都能在合理的時間內獲得符合預期的響應結果。
分割槽容錯性 是指遇到任何網路分割槽故障的時候，系統仍然能夠正常提供服務，除非是整個網路環境都發生了故障。
CAP 理論認為一個分散式系統最多隻能同時滿足其中的兩項。由於分割槽容錯性是必然存在的，所以大部分分散式軟體系統都在 CP 和 AP 中做取捨。
例如：Zookeeper 採用 CP 一致性，強調一致性，弱化可用性，Eureka 採用 AP 可用性，強調可用性，弱化一致性。
BASE 理論
- Basically Available(基本可用)
- Soft state(軟狀態)
- Eventually consistent(最終一致性)
基本可用 是指不追求強可用性，而且強調系統基本能夠一直執行對外提供服務。當分散式系統遇到不可預估的故障時，允許一定程度上的不可用，比如：對請求進行限流排隊，對非核心服務進行降級。
軟狀態 是指允許系統中的資料存在中間狀態，而不是事務的原子性：要麼全部成功，要不全部不成功。
最終一致性 是指資料不可能一直都是軟狀態，必須在一個時間期限之後達到各個節點的一致性，在此之後，所有的節點的資料都是一致的，系統達到最終一致性。
BASE 理論的核心思想是：即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當的方式來使系統達到最終一致性。
解決方案
2PC(兩階段提交協議)
3PC(三階段提交協議)
TCC
本地訊息表
RocketMQ 事務訊息
小結
本文純屬拋磚引玉，有問題，歡迎批評指正。
關於分散式事務的可落地方案，我會在後續文章中進行介紹。