架構設計 | 分佈式事務①概念簡介和基礎理論

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

1、分佈式事務簡介

一、轉帳經典案例

跨地區和機構的轉帳的業務在實際生活中很是常見，基礎流程以下：

帳戶01經過一系列服務和支付的流程，把錢轉入帳戶02，在這一過程當中，若是帳戶01出現出帳成功，可是帳戶02沒有入帳，這就致使數據不一致，違反了基本的事務原則。基於數據歸屬在不一樣服務和不一樣的數據庫中，這種狀況下的事務出錯被稱爲分佈式事務問題。

二、基本概念

分佈式事務是指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位於不一樣的分佈式系統的不一樣節點之上。

如上的轉帳案例，看似只有一次的轉帳操，實際上由不一樣的服務不一樣數據庫的多個細節操做組成，這些無感知的細節操做分佈在不一樣服務上，甚至屬於不一樣的地區和應用，如何保證這些操做所有成功或者所有失敗，即保證不一樣數據庫間的數據一致性，這就是分佈式事務須要解決的核心問題。

三、分佈式事務特色

基於以下電商業務場景，基本分佈式的架構思路：

• 數據庫基於業務特色，進行分庫分表；
• 數據庫拆分，隨之就是業務的服務化(SOA)；

基於電商業務進行拆分，會出現常見的：訂單，用戶，庫存，物流等一系列的服務，管理不一樣的業務數據庫，在實際的下單支付應用場景下，須要同時操做用戶，訂單，庫存等多個服務，就必須保證數據一致性，下單支付成功，庫存必須就須要用到分佈式事務。

2、CAP基礎理論

一、基礎簡介

說到分佈式事務問題，必然會說下CAP理論，分佈式系統的三大指標：

Consistency：一致性

單個事務執行更新寫操做，操做結束成功返回，在同一時間的其餘事務讀取的數據徹底一致，不存在中間狀態。在分佈式的系統中描述：用戶下單支付，扣款，減庫存，生成物流，必須一致。例如限量打折促銷中，用戶下單後庫存沒減小，這就致使不一致問題。

Availability：可用性

服務必須一直處於可用的狀態，收到用戶的請求，服務器必須在有限的時間給出迴應，無論結果是處理成功或者處理失敗。

Partition tolerance：分區容錯

通俗說，在分佈式系統中，一個流程裏可能出現某個服務出錯狀況，這是沒法絕對避免的，在程序設計上要能容忍這種錯誤發生。

二、CP和AP模式

分佈式系統很難同時知足一致性、可用性、分區容錯性三個特色，在大部分的系統架構中，都會選擇CP或者AP模式，即須要拋棄一個特色，說明一點，爲什麼P沒有拋棄，對於分佈式系統而言，分區容錯是該架構模式下的基本原則，不一樣的SOA服務和數據庫是好比會被部署到不一樣的節點下。因此如何解決C（一致性）和A（可用性）就成分佈式系統的最大痛點。

爲什麼不能同時知足C和A，這也是基於分佈式架構特色看，不一樣服務直接不能保證通訊是100%成功，一旦出現失敗狀況，一致性和可用性就沒法知足。

既然強一致性沒法保證，那退一步，給處理時間，最後結果保證一致性，也能夠，這就涉及到BASE理論。

3、BASE基礎理論

一、基礎簡介

BASE理論是由eBay公司的架構師提出的，主要是對上述的CAP理論中一致性和可用性作的權衡結果，基於CAP定律逐步演化而來，核心思想；即便沒法作到強一致性，但每一個應用均可以根據自身業務特色，採用適當策略實現數據的最終一致性。

Basically Available：基本可用

分佈式系統在發生故障的時，容許損失部分可用性。例如常見電商清倉甩賣時，爲保證主業務能夠，一些不重要的服務直接降級提示。

Soft State：軟狀態

容許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的總體可用性。相對於原子性而言，要求多個節點的數據副本都是一致的，這是一種硬狀態。

Eventual Consistency：最終一致

強調的數據更新操做，即軟狀態必須有個時間期限，在通過一段時間的同步以後，最終都可以達到一個一致的狀態。所以，最終一致性的本質是須要系統保證最終數據可以達到一致，而不須要實時保證系統數據的強一致性。時間期限長短取決於延時、負載、數據同步等各類因素。

BASE理論提出是基於大規模高可用可擴展的分佈式系統架構，不一樣於關係型數據庫事務特色(ACID)的強一致性模型，經過犧牲強一致性來獲取更高的可用性，並容許數據在一段時間內是不一致的，但最終達到一致狀態。實際的業務場景下事物(ACID)基本特性和BASE理論也是要權衡考慮。

二、柔性事務

遵循BASE理論，利用業務特色，在指按期限內讓事務保持最終一致性，柔性事務是一種思想，從根本上看，就是業務模式對於事務過程當中不一致性有必定的容忍度，能夠留出足夠的時間執行事務最終一致的方法。

三、PAXOS算法

Paxos算法一種保障分佈式系統最終一致性的共識算法，利用的是選舉策略，少數服從多數的思想。PAXOS不要求對全部節點作實時同步，實質上是考慮到了分區狀況下的可用性，經過減小完成一次事務須要的參與者個數，來保障系統的可用性。

例如：N個服務節點，有(N/2)+1個節點達成共識，則認爲系統達到了一致，而且按照Paxos原則，最終理論上也達到了一致，不會再改變，如此一來，只要保證有半數以上的服務存活，容許小部分服務掛掉，客戶能夠與大部分服務節點通訊，那麼就不會影響總體操做流程，也不需確保服務器所有處於工做狀態，容錯性很是好。操做影響的數據和結果隨後會被異步的同步到其餘節點上，從而保證最終一致性。

分佈式事務的各類具體實現案例，後續再說。

4、源代碼地址

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	架構設計：分佈式服務，庫表拆分模式詳解