1.什么是事務

但是在這之前要先知道什么是事務。

什么是事務?

舉個生活中的例子：你去小賣鋪買東西，“一手交錢，一手交貨”就是一個事務的例子，交錢和交貨必須全部成功，事務才算成功，任一個活動失敗，事務將撤銷所有已成功的活動。 明白上述例子，再來看事務的定義：

事務可以看做是一次大的活動，它由不同的小活動組成，這些活動要么全部成功，要么全部失敗

2.本地事務

在計算機系統中，更多的是通過關系型數據庫來控制事務，這是利用數據庫本身的事務特性來實現的，因此叫數據庫事務，由于應用主要靠關系數據庫來控制事務，而數據庫通常和應用在同一個服務器，所以基于關系型數據庫的事務又被稱為本地事務

2.1. 數據庫事務特性

• A(Atomic)：原子性，構成事務的所有操作，要么都執行完成，要么全部不執行，不可能出現部分成功部分失敗的情況
• C(Consistency)：一致性，在事務執行前后，數據庫的一致性約束沒有被破壞。比如：張三向李四轉100元，轉賬前和轉賬后的數據是正確狀態這叫一致性，如果出現張三轉出100元，李四賬戶沒有增加100元這就出現了數據錯誤，就沒有達到一致性
• I(Isolation)：隔離性，數據庫中的事務一般都是并發的，隔離性是指并發的兩個事務的執行互不干擾，一個事務不能看到其他事務運行過程的中間狀態。通過配置事務隔離級別可以避臟讀、重復讀等問題
• D(Durability)：持久性，事務完成之后，該事務對數據的更改會被持久化到數據庫，且不會被回滾

數據庫事務在實現時會將一次事務涉及的所有操作全部納入到一個不可分割的執行單元，該執行單元中的所有操作要么都成功，要么都失敗，只要其中任一操作執行失敗，都將導致整個事務的回滾。

3.分布式事務

軟件系統由原來的單體應用轉變為分布式應用，下圖描述了單體應用向微服務的演變

分布式系統把一個應用系統拆分為可獨立部署的多個服務，因此需要服務與服務之間遠程協作才能完成事務操作，這種分布式系統環境下由不同的服務之間通過網絡遠程協作完成事務稱之為分布式事務，例如用戶注冊送積分事務、創建訂單減庫存事務，銀行轉賬事務等都是分布式事務

本地事務依賴數據庫本身提供的事務特性來實現，因此以下邏輯可以控制本地事務：

begin transaction;
//1.本地數據庫操作：張三減少金額
//2.本地數據庫操作：李四增加金額
commit transation;

分布式環境，事務變成下邊這樣:

begin transaction;
//1.本地數據庫操作：張三減少金額
//2.遠程調用：讓李四增加金額
commit transation;

可以想象，當遠程調用讓李四增加金額成功了，由于網絡問題遠程調用并沒有返回，此時本地事務提交失敗就回滾了張三減少金額的操作，此時張三和李四的數據就不一致了。 因此在分布式架構的基礎上，傳統數據庫事務就無法使用了，張三和李四的賬戶不在一個數據庫中甚至不在一個應用系統里，實現轉賬事務需要通過遠程調用，由于網絡問題就會導致分布式事務問題。

4.CAP定理

CAP是是分布式系統設計中非常重要的一個原則,它是指 **Consistency(一致性)、Availability(可用性)、Partition tolerance(分區容錯性)**三個基本原則。

4.1. Consistency(一致性)

一致性:是當數據分布在多個節點上，從任意結點讀取到的數據都是最新的狀態,從而確保數據準確性

在分布式系統中，廣泛的一致性分為三種，分別是強一致性、弱一致性和最終一致性。

4.1.1. 強一致性

強一致性要求用戶在分布式系統中訪問數據時，不管是哪個節點的響應，數據都應該完全一致

比如轉賬系統張三給李四轉賬1000塊，那么張三賬戶減少1000塊，同時李四賬戶響應減少100塊，即要么賬戶 A 和賬戶 B 的余額都更新成功，要么都不更新。這樣可以避免出現轉賬金額在系統中“消失”的情況，從而保證了數據的一致性，確保了銀行業務的正常運行。

4.1.2. 弱一致性

弱一致性是指在分布式系統中，允許在一定條件下出現數據不一致的情況，但最終數據會趨于一致，不保證實時性和強制性。這種一致性級別通常用于需要高可用性和性能的場景，允許在一段時間內出現數據不一致，但最終數據會在系統內部達到一致狀態

比如公眾號在發布消息后，不同的粉絲可能在不同的時間內收到該消息。這是因為消息推送可能會經過多個節點和服務，不同節點的處理速度和網絡延遲會導致消息的推送時延不一致。

4.1.3. 最終一致性

最終一致性是指分布式系統中的數據副本在一段時間內可以存在不一致的情況，但最終會趨于一致狀態。這種一致性級別通常用于分布式系統中的數據復制和同步場景，系統會在一定的時間范圍內保證數據最終達到一致狀態，但不保證實時性和強制性。

比如當你的朋友對帖子進行點贊后，該信息需要被同步到所有觀看該帖子的用戶界面上。這個同步過程可能也是異步的，并且可能會受到網絡延遲等因素的影響，導致一段時間內點贊信息在不同用戶界面上不一致，盡管在點贊過程中可能會出現一定的時間窗口內數據不一致的情況，但社交媒體平臺會通過一定的機制和策略來保證最終所有帖子的點贊數量都達到一致狀態。這種最終一致性的特性使得社交媒體平臺能夠在分布式環境下提供可靠的服務，保證用戶的交互體驗

注意:一般的業務系統基于性價比的考量，絕大多數都是采用最終一致性作為分布式系統的設計思想。而 CAP 理論里的一致性，則要求是強一致性。正如官方文檔中描述的那樣：All nodes see the same data at the same time，所有節點在同一時間內數據完全一致

4.2.Availability(可用性)

可用性是指任何事務操作都可以得到響應結果，且不會出現響應超時或響應錯誤。

可用性確保了系統的穩定性和可靠性，它描述的是系統能夠很好地為用戶服務，不會出現用戶操作失敗或者訪問超時的情況，影響用戶體驗。

4.3.Partition tolerance(分區容錯性)

通常分布式系統的各各結點部署在不同的子網，這就是網絡分區，不可避免的會出現由于網絡問題而導致結點之間通信失敗，此時仍可對外提供服務，這叫分區容忍性

5.CAP特點

思考:CAP可以同時成立嗎

不可以，在CAP理論實際告訴我們，在分布式系統中，我們最多可以同時滿足兩個特性，無法同時滿足三個

在分布式系統中，系統間的網絡不能100%保證健康，一定會有故障的時候，而服務又必須對外保證服務。因此Partition Tolerance(分區容錯性)不可避免。當節點接收到新的數據變更時，就會出現問題了：

• 如果此時要保證**Consistency(一致性)**，就必須等待網絡恢復，完成數據同步后，整個集群才對外提供服務，服務處于阻塞狀態，不可用。
• 如果此時要保證**Availability(可用性)**，就不能等待網絡恢復，那服務之間就會出現數據不一致。

也就是說，在P一定會出現的情況下，A和C之間只能實現一個。

CAP是一個已經被證實的理論：一個分布式系統最多只能同時滿足一致性(Consistency)、可用性(Availability)和分區容忍性(Partition tolerance)這三項中的兩項。它可以作為我們進行架構設計、技術選型的考量標準。對于多數大型互聯網應用的場景，結點眾多、部署分散，而且現在的集群規模越來越大，所以節點故障、網絡故障是常態，而且要保證服務可用性達到N個9(99.99..%)，并要達到良好的響應性能來提高用戶體驗，因此一般都會做出如下選擇：保證P和A，舍棄C強一致，保證最終一致性

6.Base理論

BASE理論是對分布式系統中的一致性和可用性進行權衡的理論，它是對CAP理論的一種延伸和補充，包含三個思想：

• Basically Available (基本可用)：分布式系統在出現故障時，允許損失部分可用性，即保證核心可用。
• Soft State(軟狀態)：在一定時間內，允許出現中間狀態，比如臨時的不一致狀態。
• Eventually Consistent(最終一致性)：雖然無法保證強一致性，但是在軟狀態結束后，最終達到數據一致。

BASE理論相對于傳統的ACID(原子性、一致性、隔離性和持久性)理論，主要強調分布式系統的可用性和性能。在某些特定的場景下，犧牲臨時的一致性來換取系統的高可用性和性能是可接受的。例如，大規模的互聯網應用中，BASE理論常常應用于分布式緩存、消息隊列、分布式文件系統等系統設計中。

注意:BASE并不是一個具體的算法或協議，而是一種設計思想和原則,可以理解為BASE理論是對CAP的一種解決思路。