本文原始碼：GitHub·點這里 || GitEE·點這里
一、分布式事務簡介
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 | 架構設計：單服務.集群.分布式，基本區別和聯系 |
| 01 | 架構設計：分布式業務系統中，全域ID生成策略 |
| 02 | 架構設計：分布式系統調度，Zookeeper集群化管理 |
| 03 | 架構設計：介面冪等性原則，防重復提交Token管理 |
| 04 | 架構設計：快取管理模式，監控和記憶體回收策略 |
| 05 | 架構設計：異步處理流程，多種實作模式詳解 |
| 06 | 架構設計：高并發流量削峰，共享資源加鎖機制 |
| 07 | 架構設計：分布式服務，庫表拆分模式詳解 |
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/147234.html
標籤：Java