本文原始碼：[GitHub·點這裡](https://github.com/cicadasmile/data-manage-parent) || [GitEE·點這裡](https://gitee.com/cicadasmile/data-manage-parent) # 一、分散式事務簡介 ## 1、轉賬經典案例 跨地區和機構的轉賬的業務在實際生活中非常常見，基礎流程如下：  賬戶01通過一系列服務和支付的流程，把錢轉入賬戶02，在這一過程中，如果賬戶01出現出賬成功，但是賬戶02沒有入賬，這就導致資料不一致，違反了基本的事務原則。基於資料歸屬在不同服務和不同的資料庫中，這種情況下的事務出錯被稱為分散式事務問題。 ## 2、基本概念 分散式事務是指事務的參與者、支援事務的伺服器、資源伺服器以及事務管理器分別位於不同的分散式系統的不同節點之上。 如上的轉賬案例，看似只有一次的轉賬操，實際上由不同的服務不同資料庫的多個細節操作組成，這些無感知的細節操作分佈在不同服務上，甚至屬於不同的地區和應用，如何保證這些操作全部成功或者全部失敗，即保證不同資料庫間的資料一致性，這就是分散式事務需要解決的核心問題。 ## 3、分散式事務特點 基於如下電商業務場景，基本分散式的架構思路：  - 資料庫基於業務特點，進行分庫分表； - 資料庫拆分，隨之就是業務的服務化(SOA)； 基於電商業務進行拆分，會出現常見的：訂單，使用者，庫存，物流等一系列的服務，管理不同的業務資料庫，在實際的下單支付應用場景下，需要同時操作使用者，訂單，庫存等多個服務，就必須保證資料一致性，下單支付成功，庫存必須就需要用到分散式事務。 # 二、CAP基礎理論 ## 1、基礎簡介 說到分散式事務問題，必然會說下CAP理論，分散式系統的三大指標：  **Consistency：一致性** 單個事務執行更新寫操作，操作結束成功返回，在同一時間的其他事務讀取的資料完全一致，不存在中間狀態。在分散式的系統中描述：使用者下單支付，扣款，減庫存，生成物流，必須一致。例如限量打折促銷中，使用者下單後庫存沒減少，這就導致不一致問題。 **Availability：可用性** 服務必須一直處於可用的狀態，收到使用者的請求，伺服器必須在有限的時間給出迴應，不管結果是處理成功或者處理失敗。 **Partition tolerance：分割槽容錯** 通俗說，在分散式系統中，一個流程裡可能出現某個服務出錯情況，這是無法絕對避免的，在程式設計上要能容忍這種錯誤發生。 ## 2、CP和AP模式 分散式系統很難同時滿足一致性、可用性、分割槽容錯性三個特點，在大部分的系統架構中，都會選擇CP或者AP模式，即需要拋棄一個特點，說明一點，為何P沒有拋棄，對於分散式系統而言，分割槽容錯是該架構模式下的基本原則，不同的SOA服務和資料庫是比如會被部署到不同的節點下。所以如何解決C（一致性）和A（可用性）就成分散式系統的最大痛點。 為何不能同時滿足C和A，這也是基於分散式架構特點看，不同服務直接不能保證通訊是100%成功，一旦出現失敗情況，一致性和可用性就無法滿足。 既然強一致性無法保證，那退一步，給處理時間，最後結果保證一致性，也可以，這就涉及到BASE理論。 # 三、BASE基礎理論 ## 1、基礎簡介 BASE理論是由eBay公司的架構師提出的，主要是對上述的CAP理論中一致性和可用性做的權衡結果，基於CAP定律逐步演化而來，核心思想；即使無法做到強一致性，但每個應用都可以根據自身業務特點，採用適當策略實現資料的最終一致性。 **Basically Available：基本可用** 分散式系統在發生故障的時，允許損失部分可用性。例如常見電商清倉甩賣時，為保證主業務可以，一些不重要的服務直接降級提示。 **Soft State：軟狀態** 允許系統中的資料存在中間狀態，並認為該中間狀態的存在不會影響系統的整體可用性。相對於原子性而言，要求多個節點的資料副本都是一致的，這是一種硬狀態。 **Eventual Consistency：最終一致** 強調的資料更新操作，即軟狀態必須有個時間期限，在經過一段時間的同步之後，最終都能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終資料能夠達到一致，而不需要實時保證系統資料的強一致性。時間期限長短取決於延時、負載、資料同步等各種因素。 BASE理論提出是基於大規模高可用可擴充套件的分散式系統架構，不同於關係型資料庫事務特點(ACID)的強一致性模型，通過犧牲強一致性來獲取更高的可用性，並允許資料在一段時間內是不一致的，但最終達到一致狀態。實際的業務場景下事物(ACID)基本特性和BASE理論也是要權衡考慮。 ## 2、柔性事務 遵循BASE理論，利用業務特點，在指定期限內讓事務保持最終一致性，柔性事務是一種思想，從根本上看，就是業務模式對於事務過程中不一致性有一定的容忍度，可以留出足夠的時間執行事務最終一致的方法。 ## 3、PAXOS演算法 Paxos演算法一種保障分散式系統最終一致性的共識演算法，利用的是選舉策略，少數服從多數的思想。PAXOS不要求對所有節點做實時同步，實質上是考慮到了分割槽情況下的可用性，通過減少完成一次事務需要的參與者個數，來保障系統的可用性。 例如：N個服務節點，有(N/2)+1個節點達成共識，則認為系統達到了一致，並且按照Paxos原則，最終理論上也達到了一致，不會再改變，如此一來，只要保證有半數以上的服務存活，允許小部分服務掛掉，客戶可以與大部分服務節點通訊，那麼就不會影響整體操作流程，也不需確保伺服器全部處於工作狀態，容錯性非常好。操作影響的資料和結果隨後會被非同步的同步到其他節點上，從而保證最終一致性。 分散式事務的各種具體實現案例，後續再說。 # 四、原始碼地址 ``` GitHub·地址 https://github.com/cicadasmile/data-manage-parent GitEE·地址 https://gitee.com/cicadasmile/data-manage-parent ```  **推薦閱讀：架構設計系列** |序號| 標題| |:---|:---| |00 | [架構設計：單服務.叢集.分散式，基本區別和聯絡](https://mp.weixin.qq.com/s/NGxI3rC-6mWMDnrClaOR3Q)| |01 | [架構設計：分散式業務系統中，全域性ID生成策略](https://mp.weixin.qq.com/s/1TKAwr99rKEHSxqXFixEhQ)| |02 | [架構設計：分散式系統排程，Zookeeper叢集化管理](https://mp.weixin.qq.com/s/Yr4A95poVjlFsQ-Q0dF7hA)| |03 | [架構設計：介面冪等性原則，防重複提交Token管理](https://mp.weixin.qq.com/s/o9sxN6GwxdNYTKZvRexwjg)| |04 | [架構設計：快取管理模式，監控和記憶體回收策略](https://mp.weixin.qq.com/s/jBu-OZ69DbXfmdIf5VC7kQ)| |05 | [架構設計：非同步處理流程，多種實現模式詳解](https://mp.weixin.qq.com/s/RQm1vPJak0rCGW8dll4oAA)| |06 | [架構設計：高併發流量削峰，共享資源加鎖機制](https://mp.weixin.qq.com/s/T13aak6us7ZF36qooQ-YPQ)| |07 | [架構設計：分散式服務，庫表拆分模式詳解](https://mp.weixin.qq.com/s/EZCIgZ4EWvFKgKlC