本文源碼：GitHub·點這里 || GitEE·點這里

一、分布式事務簡介

1、轉(zhuǎn)賬經(jīng)典案例

跨地區(qū)和機構(gòu)的轉(zhuǎn)賬的業(yè)務在實際生活中非常常見，基礎(chǔ)流程如下：

賬戶01通過一系列服務和支付的流程，把錢轉(zhuǎn)入賬戶02，在這一過程中，如果賬戶01出現(xiàn)出賬成功，但是賬戶02沒有入賬，這就導致數(shù)據(jù)不一致，違反了基本的事務原則。基于數(shù)據(jù)歸屬在不同服務和不同的數(shù)據(jù)庫中，這種情況下的事務出錯被稱為分布式事務問題。

2、基本概念

分布式事務是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點之上。

如上的轉(zhuǎn)賬案例，看似只有一次的轉(zhuǎn)賬操，實際上由不同的服務不同數(shù)據(jù)庫的多個細節(jié)操作組成，這些無感知的細節(jié)操作分布在不同服務上，甚至屬于不同的地區(qū)和應用，如何保證這些操作全部成功或者全部失敗，即保證不同數(shù)據(jù)庫間的數(shù)據(jù)一致性，這就是分布式事務需要解決的核心問題。

3、分布式事務特點

基于如下電商業(yè)務場景，基本分布式的架構(gòu)思路：

• 數(shù)據(jù)庫基于業(yè)務特點，進行分庫分表；
• 數(shù)據(jù)庫拆分，隨之就是業(yè)務的服務化(SOA)；

基于電商業(yè)務進行拆分，會出現(xiàn)常見的：訂單，用戶，庫存，物流等一系列的服務，管理不同的業(yè)務數(shù)據(jù)庫，在實際的下單支付應用場景下，需要同時操作用戶，訂單，庫存等多個服務，就必須保證數(shù)據(jù)一致性，下單支付成功，庫存必須就需要用到分布式事務。

二、CAP基礎(chǔ)理論

1、基礎(chǔ)簡介

說到分布式事務問題，必然會說下CAP理論，分布式系統(tǒng)的三大指標：

Consistency：一致性

單個事務執(zhí)行更新寫操作，操作結(jié)束成功返回，在同一時間的其他事務讀取的數(shù)據(jù)完全一致，不存在中間狀態(tài)。在分布式的系統(tǒng)中描述：用戶下單支付，扣款，減庫存，生成物流，必須一致。例如限量打折促銷中，用戶下單后庫存沒減少，這就導致不一致問題。

Availability：可用性

服務必須一直處于可用的狀態(tài)，收到用戶的請求，服務器必須在有限的時間給出回應，不管結(jié)果是處理成功或者處理失敗。

Partition tolerance：分區(qū)容錯

通俗說，在分布式系統(tǒng)中，一個流程里可能出現(xiàn)某個服務出錯情況，這是無法絕對避免的，在程序設計上要能容忍這種錯誤發(fā)生。

2、CP和AP模式

分布式系統(tǒng)很難同時滿足一致性、可用性、分區(qū)容錯性三個特點，在大部分的系統(tǒng)架構(gòu)中，都會選擇CP或者AP模式，即需要拋棄一個特點，說明一點，為何P沒有拋棄，對于分布式系統(tǒng)而言，分區(qū)容錯是該架構(gòu)模式下的基本原則，不同的SOA服務和數(shù)據(jù)庫是比如會被部署到不同的節(jié)點下。所以如何解決C（一致性）和A（可用性）就成分布式系統(tǒng)的最大痛點。

為何不能同時滿足C和A，這也是基于分布式架構(gòu)特點看，不同服務直接不能保證通信是100%成功，一旦出現(xiàn)失敗情況，一致性和可用性就無法滿足。

既然強一致性無法保證，那退一步，給處理時間，最后結(jié)果保證一致性，也可以，這就涉及到BASE理論。

三、BASE基礎(chǔ)理論

1、基礎(chǔ)簡介

BASE理論是由eBay公司的架構(gòu)師提出的，主要是對上述的CAP理論中一致性和可用性做的權(quán)衡結(jié)果，基于CAP定律逐步演化而來，核心思想；即使無法做到強一致性，但每個應用都可以根據(jù)自身業(yè)務特點，采用適當策略實現(xiàn)數(shù)據(jù)的最終一致性。

Basically Available：基本可用

分布式系統(tǒng)在發(fā)生故障的時，允許損失部分可用性。例如常見電商清倉甩賣時，為保證主業(yè)務可以，一些不重要的服務直接降級提示。

Soft State：軟狀態(tài)

允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性。相對于原子性而言，要求多個節(jié)點的數(shù)據(jù)副本都是一致的，這是一種硬狀態(tài)。

Eventual Consistency：最終一致

強調(diào)的數(shù)據(jù)更新操作，即軟狀態(tài)必須有個時間期限，在經(jīng)過一段時間的同步之后，最終都能夠達到一個一致的狀態(tài)。因此，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達到一致，而不需要實時保證系統(tǒng)數(shù)據(jù)的強一致性。時間期限長短取決于延時、負載、數(shù)據(jù)同步等各種因素。

BASE理論提出是基于大規(guī)模高可用可擴展的分布式系統(tǒng)架構(gòu)，不同于關(guān)系型數(shù)據(jù)庫事務特點(ACID)的強一致性模型，通過犧牲強一致性來獲取更高的可用性，并允許數(shù)據(jù)在一段時間內(nèi)是不一致的，但最終達到一致狀態(tài)。實際的業(yè)務場景下事物(ACID)基本特性和BASE理論也是要權(quán)衡考慮。

2、柔性事務

遵循BASE理論，利用業(yè)務特點，在指定期限內(nèi)讓事務保持最終一致性，柔性事務是一種思想，從根本上看，就是業(yè)務模式對于事務過程中不一致性有一定的容忍度，可以留出足夠的時間執(zhí)行事務最終一致的方法。

3、PAXOS算法

Paxos算法一種保障分布式系統(tǒng)最終一致性的共識算法，利用的是選舉策略，少數(shù)服從多數(shù)的思想。PAXOS不要求對所有節(jié)點做實時同步，實質(zhì)上是考慮到了分區(qū)情況下的可用性，通過減少完成一次事務需要的參與者個數(shù)，來保障系統(tǒng)的可用性。

例如：N個服務節(jié)點，有(N/2)+1個節(jié)點達成共識，則認為系統(tǒng)達到了一致，并且按照Paxos原則，最終理論上也達到了一致，不會再改變，如此一來，只要保證有半數(shù)以上的服務存活，允許小部分服務掛掉，客戶可以與大部分服務節(jié)點通信，那么就不會影響整體操作流程，也不需確保服務器全部處于工作狀態(tài)，容錯性非常好。操作影響的數(shù)據(jù)和結(jié)果隨后會被異步的同步到其他節(jié)點上，從而保證最終一致性。

分布式事務的各種具體實現(xiàn)案例，后續(xù)再說。

四、源代碼地址

GitHub·地址 https://github.com/cicadasmile/data-manage-parent GitEE·地址 https://gitee.com/cicadasmile/data-manage-parent

推薦閱讀：架構(gòu)設計系列

序號標題

00	架構(gòu)設計：單服務.集群.分布式，基本區(qū)別和聯(lián)系
01	架構(gòu)設計：分布式業(yè)務系統(tǒng)中，全局ID生成策略
02	架構(gòu)設計：分布式系統(tǒng)調(diào)度，Zookeeper集群化管理
03	架構(gòu)設計：接口冪等性原則，防重復提交Token管理
04	架構(gòu)設計：緩存管理模式，監(jiān)控和內(nèi)存回收策略
05	架構(gòu)設計：異步處理流程，多種實現(xiàn)模式詳解
06	架構(gòu)設計：高并發(fā)流量削峰，共享資源加鎖機制
07	架構(gòu)設計：分布式服務，庫表拆分模式詳解

總結(jié)

以上是生活随笔為你收集整理的架构设计 | 分布式事务①概念简介和基础理论的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。