業務場景
電商業務
上圖是一個電商系統，當一個訂單支付完成后的業務場景：
- 更改訂單的狀態為 “已支付”
- 扣減商品庫存
- 給會員增加積分
- 創建出庫單通知倉庫發貨
想象一下，當訂單支付完成后，個人積分延遲幾分鍾變更，這可以接受嗎？
火車票購票
想想生活中火車票購票場景。
想象一下，當最后一張火車票同時被兩個人購買，去檢票口檢票時被告知車票無效，這可以接受嗎？
銀行轉賬
想想生活中銀行轉賬場景。
想象一下，當銀行轉賬時，轉賬成功后，自己賬戶金額減少了，對方賬戶卻一直未進賬，這可以接受嗎？
關於上述的三種業務需求場景，你是怎么理解和處理的？
在處理上述問題之前，咱們先來理解以下幾個概念。
什么是事務？
事務是指作為單個邏輯工作單元執行的一系列操作，要么完全地執行，要么完全地不執行。
數據庫事務大家肯定都很熟悉，在開發過程中會經常使用到。
事務的特性
- 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 事務消息
小結
本文純屬拋磚引玉，有問題，歡迎批評指正。
關於分布式事務的可落地方案，我會在后續文章中進行介紹。