分布式事务概览
傳統(tǒng)的事務
事務(Transaction)是訪問并可能更新數(shù)據(jù)庫中各種數(shù)據(jù)項的一個程序執(zhí)行單元(unit)。在關系數(shù)據(jù)庫中，一個事務由一組SQL語句組成。事務應該具有4個屬性：原子性、一致性、隔離性、持久性。這四個屬性通常稱為ACID特性。
- 原子性：一個事務是一個不可分割的工作單位，事務中包括的操作要么全部完成，要么全部取消
- 一致性：事務使數(shù)據(jù)庫從一個一致性狀態(tài)轉換為另一個一致性狀態(tài)，事務的中間狀態(tài)不可被觀察到。
- 隔離性：一個事務內部的操作及使用的數(shù)據(jù)對并發(fā)中的其它事務是隔離的。
- 持久性：一個事務一旦被提交，其對數(shù)據(jù)庫中數(shù)據(jù)的改變是永久性的，不因其它故障而受影響。
集中式數(shù)據(jù)庫與分布式數(shù)據(jù)庫
ACID
以一個學生管理系統(tǒng)為例，可以看到對于這個學生成績管理系統(tǒng)，不同的系統(tǒng)使用角色，對它有不同的要求：
那么傳統(tǒng)的事務
ACID屬性，是如何幫助我們做到滿足這些需求的呢？
數(shù)據(jù)量變大
而實際上，當我們考慮更大的數(shù)據(jù)量的時候，會發(fā)現(xiàn)，依賴于傳統(tǒng)集中式數(shù)據(jù)庫并無法很好地滿足我們對系統(tǒng)的需求。當數(shù)據(jù)量變大，第一個要面對的問題是數(shù)據(jù)再也無法只放在一臺機器上了，數(shù)據(jù)量的變大，意味著會有越來越多的客戶端來查詢這個數(shù)據(jù)庫，那么就會出現(xiàn)查詢的瓶頸，并且如果數(shù)據(jù)數(shù)非常重要的話，那么這些數(shù)據(jù)時丟不起的，而如果僅依賴于集中式數(shù)據(jù)庫，那么當這個集中式數(shù)據(jù)庫發(fā)生一些致命性的狀況的時候，數(shù)據(jù)可能丟失。總而言之，對于集中式數(shù)據(jù)庫來說，如果它出現(xiàn)了什么問題：不可查、丟數(shù)據(jù)等。那么其實意味著整個業(yè)務系統(tǒng)都陷入了不可用的狀態(tài)。
總結下來，集中式數(shù)據(jù)庫在通信、系統(tǒng)可靠性、可擴展性、性能瓶頸以及設計管理上，存在著明顯的缺點：
- 集中數(shù)據(jù)庫會有多個成績錄入員，因為集中數(shù)據(jù)庫只存在于某個服務器上，而成績錄入員卻是分散在全國各地的，因此會造成額外的通信開銷。
- 由于集中式數(shù)據(jù)庫所有的數(shù)據(jù)都存在一個點上，那么一旦這個點發(fā)生故障，就會導致整個成績管理系統(tǒng)停止運作，系統(tǒng)的可靠性差。
- 隨著數(shù)據(jù)量的變大，錄入的客戶端變多，查詢的客戶端變多，那么存儲系統(tǒng)本身的性能可能就會成為瓶頸，包括 CPU計算能力，IO吞吐能力，存儲能力，都有可能成為瓶頸。
- 可擴展性差，正由于集中式數(shù)據(jù)庫存在著性能差的問題，因此只能通過升級單機硬件能力的方式，實現(xiàn)數(shù)據(jù)庫服務能力擴展，比如原來采用 MySQL 單機數(shù)據(jù)庫，遇到訪問瓶頸時更換磁盤，訪問量更高時就需要考慮使用 Oracle 的商用解決方案、高端的存儲設備、高端小型機，也就是 IOE 架構，甚至升級 IOE 設備，以換取更高的擴展和服務能力，這個過程就會存在設備升級和數(shù)據(jù)遷移的成本，其可擴展性的代價會面臨巨大的成本問題。此外，根據(jù)摩爾定律，單機硬件能力的升級，并不能換來等比的效率加速比例，也就是說，增加多一倍的CPU核數(shù)，并不能帶來一倍的性能提升，這個提升并不是線性的。
- 當一個系統(tǒng)的功能變得越來越復雜，例如說b不僅記錄學生的成績，還記錄學生的獎懲歷史，出勤情況，而數(shù)據(jù)庫仍然只有一個點的情況下，集中數(shù)據(jù)庫上承載的業(yè)務類型越來越多，導致管理困難。
傳統(tǒng)集中式數(shù)據(jù)庫雖然能夠很好地保證業(yè)務一致性，但其面臨高速增長的訪問量和數(shù)據(jù)量時存在性能和處理能力上的瓶頸。
數(shù)據(jù)分布式存儲
分布式數(shù)據(jù)庫雖然引進了復雜性例如分布式事務的問題，但是分布式數(shù)據(jù)庫能解決集中式數(shù)據(jù)庫的大多數(shù)痛點。
分布式數(shù)據(jù)庫與集中式數(shù)據(jù)庫的區(qū)別主要在數(shù)據(jù)分布和可擴展性兩方面：
- 分布式數(shù)據(jù)庫的數(shù)據(jù)分散存儲，集中式數(shù)據(jù)庫的數(shù)據(jù)集中存儲。
- 分布式數(shù)據(jù)庫的擴展高效并且性價比高，而集中式數(shù)據(jù)庫不能無限擴容并且擴容存在著成本導致的性價比的問題。
總結起來，分布式數(shù)據(jù)庫具有以下的特點：
- 數(shù)據(jù)分布性，數(shù)據(jù)可以分布在不同的機器上，不同地理位置上。
- 數(shù)據(jù)統(tǒng)一性，雖然數(shù)據(jù)存放在不同的機器上，不同的地理位置上，但從整體上來看，它的系統(tǒng)邏輯應該是一致的
- 數(shù)據(jù)的透明性，雖然數(shù)據(jù)分散了，但是無論是查詢還是更新，它們都應該有統(tǒng)一的入口
- 數(shù)據(jù)的安全性，單個數(shù)據(jù)節(jié)點如果出現(xiàn)錯誤，它不應該影響其它節(jié)點，從而數(shù)據(jù)庫整體的安全性
- 數(shù)據(jù)的可擴展性，當現(xiàn)有集群稱為瓶頸時，分布式數(shù)據(jù)庫系統(tǒng)可以通過擴容來解決可擴展性的問題
- 數(shù)據(jù)的自治性，雖然數(shù)據(jù)分散存儲，但每一個節(jié)點它都應該要能夠獨立管理自己的數(shù)據(jù)，同時又不影響整體的統(tǒng)一性。
分布式事務
在高速增長的訪問量和數(shù)據(jù)量的背景下，為了解決單機性能瓶頸以及可擴展性等問題，數(shù)據(jù)庫分庫分表拆分和服務化（微服務）的運用越來越廣泛。完成一個業(yè)務功能，可能需要橫跨多個服務或者橫跨多個數(shù)據(jù)庫節(jié)點；也就是說，需要操作的資源位于多個資源服務器上，從業(yè)務的角度來看，需要保證對多個資源服務器的操作，要么全部成功，要么全部失敗。從本質上來說，分布式事務要保證不同資源服務器上的數(shù)據(jù)一致性。
場景
典型的分布式事務場景主要有跨庫事務、分庫分表以及跨服務事務。
跨庫事務
分庫分表
當對數(shù)據(jù)庫通過中間件代理的形式進行水平拆分后，不可避免的會在一個事務中操作多個分片節(jié)點
跨服務
在服務化的架構下，完成業(yè)務功能可能涉及到對多個服務的調用，而這些服務分別會操作不同的數(shù)據(jù)庫。需要保證跨服務對數(shù)據(jù)庫的操作要么都成功，要么都失敗，這是服務化場景下面臨的分布式問題。
X/Open DTP模型與XA規(guī)范
DTP 模型
X/Open DTP(X/Open Distributed Transaction Processing Reference Model) 是X/Open 這個組織定義的一套分布式事務的標準，也就是了定義了規(guī)范和API接口，由廠商進行具體的實現(xiàn)。
模型元素
- 應用程序(Application Program ，簡稱AP)：用于定義事務邊界(即定義事務的開始和結束)，并且在事務邊界內對資源進行操作。
- 資源管理器(Resource Manager，簡稱RM)：如數(shù)據(jù)庫、文件系統(tǒng)等，并提供訪問資源的方式。
- 事務管理器(Transaction Manager ，簡稱TM)：負責分配事務唯一標識，監(jiān)控事務的執(zhí)行進度，并負責事務的提交、回滾等。
- 通信資源管理器(Communication Resource Manager，簡稱CRM)：控制一個TM域(TM domain)內或者跨TM域的分布式應用之間的通信。
- 通信協(xié)議(Communication Protocol，簡稱CP)：提供CRM提供的分布式應用節(jié)點之間的底層通信服務。
一個DTP模型實例，至少有3個組成部分：AP、RMs、TM。如下所示：
AP通過TM來聲明一個全局事務，然后操作不同的RM上的資源，最后通知TM來提交或者回滾全局事務。AP 可以和 TM 以及 RM 通信，TM 和 RM 互相之間可以通信，DTP模型里面定義了XA接口，TM 和 RM 通過XA接口進行雙向通信，例如:TM通知RM提交事務或者回滾事務，RM把提交結果通知給TM。AP和RM之間則通過RM提供的Native API 進行資源控制，這個沒有進行約API和規(guī)范，各個廠商自己實現(xiàn)自己的資源控制，比如Oracle自己的數(shù)據(jù)庫驅動程序。
XA 規(guī)范
在DTP本地模型實例中，由AP、RMs和TM組成，不需要其他元素。AP、RM和TM之間，彼此都需要進行交互，如下圖所示：
上圖中(1)表示AP-RM的交互接口，(2)表示AP-TM的交互接口，(3)表示RM-TM的交互接口
XA規(guī)范的最主要的作用是，就是定義了RM-TM的交互接口
XA規(guī)范中定義的RM 和 TM交互的接口如下圖所示：
二階段提交
XA規(guī)范除了定義的RM-TM交互的接口(XA Interface)之外，還對兩階段提交協(xié)議進行了優(yōu)化。 兩階段協(xié)議(two-phase commit)是在OSI TP標準中提出的；在DTP參考模型中，指定了全局事務的提交要使用two-phase commit協(xié)議；而XA規(guī)范只是定義了兩階段提交協(xié)議中需要使用到的接口，也就是上述提到的RM-TM交互的接口，因為兩階段提交過程中的參與方，只有TM和RMs。
- 階段1
TM通知各個RM準備提交它們的事務分支。如果RM判斷自己進行的工作可以被提交，那就就對工作內容進行持久化，再給TM肯定答復；要是發(fā)生了其他情況，那給TM的都是否定答復。在發(fā)送了否定答復并回滾了已經的工作后，RM就可以丟棄這個事務分支信息。
- 階段2
TM根據(jù)階段1各個RM prepare的結果，決定是提交還是回滾事務。如果所有的RM都prepare成功，那么TM通知所有的RM進行提交；如果有RM prepare失敗的話，則TM通知所有RM回滾自己的事務分支。
二階段提交優(yōu)化
XA規(guī)范對兩階段提交協(xié)議有2點優(yōu)化：
- 只讀斷言
在階段1中，RM可以斷言“我這邊不涉及數(shù)據(jù)增刪改”來答復TM的prepare請求，從而讓這個RM脫離當前的全局事務，從而免去了Phase 2。
這種優(yōu)化發(fā)生在其他RM都完成prepare之前的話，使用了只讀斷言的RM早于AP其他動作（比如說這個RM返回那些只讀數(shù)據(jù)給AP）前，就釋放了相關數(shù)據(jù)的上下文（比如讀鎖之類的），這時候其他全局事務或者本地事務就有機會去改變這些數(shù)據(jù)，結果就是無法保障整個系統(tǒng)的可序列化特性，有臟讀的風險。
- 一階段提交
如果需要增刪改的數(shù)據(jù)都在同一個RM上，TM可以使用一階段提交跳過兩階段提交中的階段1，直接執(zhí)行階段2。
二階段提交缺點
如果對操作讀很敏感，我們需要將事務隔離級別設置為SERIALIZABLE。而對于分布式事務來說，更是如此，可重復讀隔離級別不足以保證分布式事務一致性。
一旦協(xié)調者TM發(fā)生故障。參與者RM會一直阻塞下去。尤其在第二階段，協(xié)調者發(fā)生故障，那么所有的參與者還都處于鎖定事務資源的狀態(tài)中，而無法繼續(xù)完成事務操作。（如果是協(xié)調者掛掉，可以重新選舉一個協(xié)調者，但是無法解決因為協(xié)調者宕機導致的參與者處于阻塞狀態(tài)的問題）
在二階段提交的階段二中，當協(xié)調者向參與者發(fā)送commit請求之后，發(fā)生了局部網絡異常或者在發(fā)送commit請求過程中協(xié)調者發(fā)生了故障，這回導致只有一部分參與者接受到了commit請求。而在這部分參與者接到commit請求之后就會執(zhí)行commit操作。但是其他部分未接到commit請求的機器則無法執(zhí)行事務提交。于是整個分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)不一致性的現(xiàn)象。
三階段提交
由于二階段提交存在著諸如同步阻塞、單點問題等缺陷，所以，研究者們在二階段提交的基礎上做了改進，提出了三階段提交。
三階段提交（3PC)，是二階段提交（2PC）的改進版本，與兩階段提交不同的是，三階段提交有兩個改動點。
- CanCommit 階段
3PC的CanCommit階段其實和2PC的準備階段很像。協(xié)調者向參與者發(fā)送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。
- PreCommit 階段
協(xié)調者根據(jù)參與者的反應情況來決定是否可以繼續(xù)事務的PreCommit操作。根據(jù)響應情況，有以下兩種可能。
假如協(xié)調者從所有的參與者獲得的反饋都是Yes響應，那么就會執(zhí)行事務的預執(zhí)行。
假如有任何一個參與者向協(xié)調者發(fā)送了No響應，或者等待超時之后，協(xié)調者都沒有接到參與者的響應，那么就執(zhí)行事務的中斷。
- doCommit階段
該階段進行真正的事務提交，也可以分為以下兩種情況。
情況1：執(zhí)行提交
情況2：中斷事務（協(xié)調者沒有接收到參與者發(fā)送的ACK響應）
在doCommit階段，如果參與者無法及時接收到來自協(xié)調者的doCommit或者rebort請求時，會在等待超時之后，會繼續(xù)進行事務的提交。當進入第三階段時，說明參與者在第二階段已經收到了PreCommit請求，那么協(xié)調者產生PreCommit請求的前提條件是他在第二階段開始之前，收到所有參與者的CanCommit響應都是Yes。當進入第三階段時，由于網絡超時等原因，雖然參與者沒有收到commit或者abort響應，但是他有理由相信：成功提交的幾率很大。
相對于2PC，3PC主要解決的單點故障問題，并減少阻塞，因為一旦參與者無法及時收到來自協(xié)調者的信息之后，他會默認執(zhí)行commit。而不會一直持有事務資源并處于阻塞狀態(tài)。但是這種機制也會導致數(shù)據(jù)一致性問題，因為，由于網絡原因，協(xié)調者發(fā)送的abort響應沒有及時被參與者接收到，那么參與者在等待超時之后執(zhí)行了commit操作。這樣就和其他接到abort命令并執(zhí)行回滾的參與者之間存在數(shù)據(jù)不一致的情況。
無論是二階段提交還是三階段提交都無法徹底解決分布式的一致性問題。
CAP理論與BASE柔性事務
CAP 理論
2000年7月，加州大學伯克利分校的 Eric Brewer 教授在分布式計算原則研究會議上提出 CAP 猜想。直到 2002 年，又麻省理工學院的 Seth Gilbert 和 Nancy Lynch 從理論上證明了 CAP 理論，從而讓 CAP 理論正式成為分布式計算領域的公認定理。
CAP理論：一個分布式系統(tǒng)最多只能同時滿足一致性（consistency）、可用性（Availability）、分區(qū)容錯性（partition-tolerance）這三項中的兩項。
{% asset_img cap.jpg CAP理論模型 %}
指更新操作成功并返回客戶端完成后，所有節(jié)點在同一時間的數(shù)據(jù)完全一致。
指系統(tǒng)提供的服務必須一直處于可用的狀態(tài)，對于用戶的每一個操作請求總是能夠在有限的時間內返回結果。
指分布式系統(tǒng)在遇到某節(jié)點或網絡分區(qū)故障的時候，仍然能對外提供滿足一致性和可用性的服務。
BASE 理論
一個分布式系統(tǒng)無法同時滿足一致性、可用性、分區(qū)容錯性三個特點，需要對其進行取舍。對于一個分布式系統(tǒng)而言，分區(qū)容錯性是一個最基本的要求，分布式系統(tǒng)中的組件必然需要被部署到不同的節(jié)點，網絡問題又是一個必定會出現(xiàn)的異常情況，因此分區(qū)容錯性也就成為了一個分布式系統(tǒng)必然需要面對和解決的問題。
eBay的架構師Dan Pritchett源于對大規(guī)模分布式系統(tǒng)的實踐總結，在ACM上發(fā)表文章提出BASE理論。
BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（Strong Consistency，CAP的一致性就是強一致性），但應用可以采用適合的方式達到最終一致性（Eventual Consitency）。
BASE是指Basically Available（基本可用）、Soft state（柔性狀態(tài)）和Eventually consistent（最終一致性）
指分布式系統(tǒng)在出現(xiàn)不可預知故障的時候，允許損失部分可用性。
指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)，并認為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性。
強調的是所有的數(shù)據(jù)更新操作，在經過一段時間的同步之后，最終都能夠達到一個一致的狀態(tài)。
BASE理論面向的是大型高可用可擴展的分布式系統(tǒng)，通過犧牲一致性獲得高可用性。
柔性事務解決方案一般有：最大努力通知、可靠消息最終一致性以及TCC。
參考資料
Distributed Transaction Processing: Reference Model, Version 3
Distributed Transaction Processing:The XA Specification
Atomic Distributed Transactions: a RESTful Design
田守枝的技術博客
總結
- 上一篇： 用C#获取硬盘序列号,CPU序列号,网卡
- 下一篇： Webhook与Jenkins自动构建(