現今互聯網界，分布式系統和微服務架構盛行，一個簡單操作，在服務端非常可能是由多個服務和資料庫實體協同完成的，在互聯網金融等一致性要求較高的場景下，多個獨立操作之間的一致性問題顯得格外棘手，隨著業務的快速發展、業務復雜度越來越高，幾乎每個公司的系統都會從單體走向分布式，特別是轉向微服務架構，隨之而來就必然遇到分布式事務這個難題，本文會介紹分布式事務的一些相關概念，

分布式事務的概念

資料庫事務

資料庫事務的目的

資料庫事務（簡稱：事務）是資料庫管理系統執行程序中的一個邏輯單位，由一個有限的資料庫操作序列構成，資料庫事務通常包含了一個序列的對資料庫的讀/寫操作，包含有以下兩個目的：

• 為資料庫操作序列提供了一個從失敗中恢復到正常狀態的方法，同時提供了資料庫即使在例外狀態下仍能保持一致性的方法，
• 當多個應用程式在并發訪問資料庫時，可以在這些應用程式之間提供一個隔離方法，以防止彼此的操作互相干擾，

當事務被提交給了資料庫管理系統（DBMS），則DBMS需要確保該事務中的所有操作都成功完成且其結果被永久保存在資料庫中，如果事務中有的操作沒有成功完成，則事務中的所有操作都需要回滾，回到事務執行前的狀態；同時，該事務對資料庫或者其他事務的執行無影響，所有的事務都好像在獨立的運行，

ACID特性

資料庫事務擁有以下四個特性，習慣上被稱之為ACID特性：

1. 原子性(Atomicity):事務中的所有操作作為一個整體像原子一樣不可分割，要么全部成功,要么全部失敗，
2. 一致性(Consistency):事務的執行結果必須使資料庫從一個一致性狀態到另一個一致性狀態，一致性狀態是指:1.系統的狀態滿足資料的完整性約束(主碼,參照完整性,check約束等) 2.系統的狀態反應資料庫本應描述的現實世界的真實狀態,比如轉賬前后兩個賬戶的金額總和應該保持不變，
3. 隔離性(Isolation):并發執行的事務不會相互影響,其對資料庫的影響和它們串行執行時一樣，比如多個用戶同時往一個賬戶轉賬,最后賬戶的結果應該和他們按先后次序轉賬的結果一樣，
4. 持久性(Durability):事務一旦提交,其對資料庫的更新就是持久的，任何事務或系統故障都不會導致資料丟失，

資料庫的并發控制

影響資料庫ACID實作的因素有兩個：并發和系統故障，相應地，資料庫系統通過并發控制技術和日志恢復技術來實作資料庫的ACID特性，

并發控制技術是實作事務隔離性以及不同隔離級別的關鍵,實作方式有很多,按照其對可能沖突的操作采取的不同策略可以分為樂觀并發控制和悲觀并發控制兩大類，

• 樂觀并發控制:對于并發執行可能沖突的操作,假定其不會真的沖突,允許并發執行,直到真正發生沖突時才去解決沖突,比如讓事務回滾，
• 悲觀并發控制:對于并發執行可能沖突的操作,假定其必定發生沖突,通過讓事務等待(鎖)或者中止(時間戳排序)的方式使并行的操作串行執行，

其實作方式有多種： 基于封鎖的并發控制、基于時間戳的并發控制、基于有效性檢查的并發控制、基于快照隔離的并發控制.

資料庫日志

資料庫運行程序中可能會出現故障,這些故障包括事務故障和系統故障兩大類

• 事務故障:比如非法輸入,系統出現死鎖,導致事務無法繼續執行，
• 系統故障:比如由于軟體漏洞或硬體錯誤導致系統崩潰或中止，

這些故障可能會對事務和資料庫狀態造成破壞,因而必須提供一種技術來對各種故障進行恢復,保證資料庫一致性,事務的原子性以及持久性，資料庫通常以日志的方式記錄資料庫的操作從而在故障時進行恢復,因而可以稱之為日志恢復技術，資料庫日志包含undo和redo日志，

分布式事務場景

當我們的單個資料庫的性能產生瓶頸的時候，我們可能會對資料庫進行磁區，這里所說的磁區指的是物理磁區，磁區之后可能不同的庫就處于不同的服務器上了，這個時候單個資料庫的ACID已經不能適應這種情況了，而在這種ACID的集群環境下，再想保證集群的ACID幾乎是很難達到，或者即使能達到那么效率和性能會大幅下降，最為關鍵的是再很難擴展新的磁區了，這個時候如果再追求集群的ACID會導致我們的系統變得很差，這時我們就需要引入一個新的理論原則來適應這種集群的情況，就是CAP原則或者叫CAP定理？

CAP定理

CAP定理是由加州大學伯克利分校Eric Brewer教授提出來的，他指出WEB服務無法同時滿足一下3個屬性：

• 一致性（Consistency）:（等同于所有節點訪問同一份最新的資料副本）
• 可用性（Availability）:（每次請求都能獲取到非錯的回應——但是不保證獲取的資料為最新資料）
• 磁區容錯性（Partition tolerance）:（以實際效果而言，磁區相當于對通信的時限要求，系統如果不能在時限內達成資料一致性，就意味著發生了磁區的情況，必須就當前操作在C和A之間做出選擇，）

根據定理，分布式系統只能滿足三項中的兩項而不可能滿足全部三項，理解CAP理論的最簡單方式是想象兩個節點分處磁區兩側，允許至少一個節點更新狀態會導致資料不一致，即喪失了C性質，如果為了保證資料一致性，將磁區一側的節點設定為不可用，那么又喪失了A性質，除非兩個節點可以互相通信，才能既保證C又保證A，這又會導致喪失P性質，

因此在進行分布式架構設計時，必須做出取舍，當前一般是通過分布式快取中各節點的最終一致性來提高系統的性能，通過使用多節點之間的資料異步復制技術來實作集群化的資料一致性，通常使用類似 memcached 之類的 NOSQL 作為實作手段，雖然 memcached 也可以是分布式集群環境的，但是對于一份資料來說，它總是存盤在某一臺 memcached 服務器上，如果發生網路故障或是服務器死機，則存盤在這臺服務器上的所有資料都將不可訪問，由于資料是存盤在記憶體中的，重啟服務器，將導致資料全部丟失，當然也可以自己實作一套機制，用來在分布式 memcached 之間進行資料的同步和持久化，但是實作難度是非常大的，

磁區容錯性（Partition tolerance）

大多數分布式系統都分布在多個子網路，每個子網路就叫做一個區（partition），磁區容錯的意思是，區間通信可能失敗，比如，一臺服務器放在中國，另一臺服務器放在美國，這就是兩個區，它們之間可能無法通信，

圖中，P1和P2是兩臺跨區的服務器，P1向P2發送一條訊息，P2可能無法收到，系統設計的時候，必須考慮到這種情況，一般來說，磁區容錯無法避免，因此可以認為CAP的P總是成立，CAP定理告訴我們，剩下的C和A無法同時做到，

一致性（Consistency）

一致性意味著寫操作之后的讀操作，必須回傳該值，舉例來說，某條記錄是v1=1，用戶向P1發起一個寫操作，將其改為v1=10,接下來，用戶的讀操作就會得到v1=10，這就叫一致性，

問題是，用戶有可能向P2發起讀操作，由于P2的值沒有發生變化，因此回傳的是 v0，P1和P2讀操作的結果不一致，這就不滿足一致性了，

為了讓P2也能變為v1=10，就要在P1寫操作的時候，讓P1向P2發送一條訊息，要求P2也改成v1=10，

可用性（Availability）

可用性是指只要收到用戶的請求，服務器就必須給出回應，
用戶可以選擇向P1或P2發起讀操作，不管是哪臺服務器，只要收到請求，就必須告訴用戶v1的值，否則就不滿足可用性，

一致性和可用性的矛盾

一致性和可用性，為什么不可能同時成立？答案很簡單，因為可能通信失敗（即出現磁區容錯），

如果保證P2的一致性，那么P1必須在寫操作時，鎖定P2的讀操作和寫操作，只有資料同步后，才能重新開放讀寫，鎖定期間，P2不能讀寫，沒有可用性，如果保證P2的可用性，那么勢必不能鎖定P2，所以一致性不成立，綜上所述，P2無法同時做到一致性和可用性，系統設計時只能選擇一個目標，如果追求一致性，那么無法保證所有節點的可用性；如果追求所有節點的可用性，那就沒法做到一致性，

那么在什么場合，可用性高于一致性？舉例來說，發布一張網頁到 CDN，多個服務器有這張網頁的副本，后來發現一個錯誤，需要更新網頁，這時只能每個服務器都更新一遍，一般來說，網頁的更新不是特別強調一致性，短時期內，一些用戶拿到老版本，另一些用戶拿到新版本，問題不會特別大，當然，所有人最終都會看到新版本，所以，這個場合就是可用性高于一致性，

常見產品

Ereka->ereka是SpringCloud系列用來做服務注冊和發現的組件，作為服務發現的一個實作，在設計的時候就更考慮了可用性，保證了AP，

Zookeeper->Zookeeper在實作上犧牲了可用性，保證了一致性（單調一致性）和磁區容錯性，也即：CP，所以這也是SpringCloud拋棄了zookeeper而選擇Ereka的原因，

Zookeeper當master掛了，會在30-120s進行leader選舉，這點類似于redis的哨兵機制，在選舉期間Zookeeper是不可用的，這么長時間不能進行服務注冊，是無法忍受的，別說30s，5s都不能忍受，這時Zookeeper集群會癱瘓，這也是Zookeeper的CP，保持節點的一致性，犧牲了A/高可用，而Eureka不會，即使Eureka有部分掛掉，還有其他節點可以使用的，他們保持平級的關系，只不過資訊有可能不一致，這就是AP，犧牲了C/一致性，

BASE理論

如前文中說CAP定理是三個單詞的縮寫，BASE也是一樣，是由Basically Available(基本可用)，Soft state（軟狀態）,和 Eventually consistent（最終一致性）三個短語的縮寫，

為什么要BASE理論

CAP定理只能三選二，CAP理論表明，對于一個分布式系統而言，它是無法同時滿足Consistency(強一致性)、Availability(可用性) 和Partition tolerance(磁區容忍性) 這三個條件的，最多只能滿足其中兩個，

磁區容錯必須選，對于互聯網來說，由于網路環境是不可信的，所以磁區容錯性（P）必須滿足

為了用戶體驗，先選可用性，現在只能在一致性和可用性之間做選擇，大部分情況下，大家都會選擇犧牲一部分的一致性來保證可用性，因為你不回傳給用戶資料，這體驗也太差了，寧可拒絕服務也不能說能訪問卻沒有資料，當然，嚴格場景下，比如支付場景，強一致性是必須要滿足，這另說，

但是放棄了一致性的系統又失去了存在的意義，好了，我們只能放棄一致性，但是我們真這樣做了，將一致性放棄了，現在這個系統回傳的資料你敢信嗎？沒有一致性，系統中的資料也就從根本上變得不可信了，那這資料拿來有什么用，那這個系統也就沒有任何價值，根本沒用，

如上所述，由于我們三者都無法拋棄，但CAP定理限制了我們三者無法同時滿足，這種情況，我們會選擇盡量靠近CAP定理，即盡量讓C、A、P都滿足，在此大勢所趨下，出現了BASE定理，

核心思想

強一致性（Strong consistency）無法得到保障時（磁區容錯和可用性滿足系統），我們可以根據業務自身的特點，采用適當的方式來達到最終一致性（Eventual consistency），

基本可用(Basically Available)

基本可用是相對于正常的系統來說的,常見如下情況

回應時間上的損失：正常情況下的搜索引擎0.5秒即回傳給用戶結果，而基本可用看的搜索結果可能要1秒，2秒甚至3秒，如下圖中所示，本來用戶可以從redis用10ms讀取到資料，但是有些情況下為了保證一致性，需要從MySql花費1s讀取資料，用戶以更長的時間代價拿到了資料，

功能上的損失：在一個電商網站上，正常情況下，用戶可以順利完成每一筆訂單，但是到了促銷時間，可能為了應對并發，保護購物系統的穩定性，部分用戶會被引導到一個降級頁面，

軟狀態

軟狀態是相對原子性來說的

原子性（硬狀態）-> 要求多個節點的資料副本都是一致的,這是一種"硬狀態"，我們在之前學習過硬狀態，指的就是ACID的原子性，如下圖所示，硬狀態只有在訂單狀態、積分發送成功、倉庫出單成功，即三者同時成功的情況才算支付成功，

軟狀態（弱狀態）-> 允許系統中的資料存在中間狀態,并認為該狀態不影響系統的整體可用性,即允許系統在多個不同節點的資料副本存在資料延遲，軟狀態不需要完全符合ACID的原子性先把訂單狀態改成已支付成功，然后告訴用戶已經成功了，剩下在異步發送mq訊息通知積分服務和倉庫服務，即使消費失敗,MQ訊息也會重新發送（重試），

最終一致性(Eventually consistent)

弱一致性和強一致性相對，系統并不保證連續行程或者執行緒的訪問都會回傳最新的更新過的值，系統在資料寫入成功之后，不承諾立即可以讀到最新寫入的值，也不會具體的承諾多久之后可以讀到，但會 盡可能保證在某個時間級別（比如秒級別）之后，可以讓資料達到一致性狀態，最終一致性是弱一致性的特定形式，

強一致性與弱一致性:其實只有兩類資料一致性，強一致性與弱一致性，強一致性也叫做線性一致性，除此以外，所有其他的一致性都是弱一致性的特殊情況，所謂強一致性，即復制是同步的，弱一致性，即復制是異步的，

用戶更新網站頭像，在某個時間點，用戶向主庫發送更新請求，不久之后主庫就收到了請求，在某個時刻，主庫又會將資料變更轉發給自己的從庫，最后，主庫通知用戶更新成功，

如果在回傳“更新成功”并使新頭像對其他用戶可見之前，主庫需要等待從庫的確認，確保從庫已經收到寫入操作，那么復制是同步的，即強一致性，如果主庫寫入成功后，不等待從庫的回應，直接回傳“更新成功”，則復制是異步的，即弱一致性，

強一致性可以保證從庫有與主庫一致的資料，如果主庫突然宕機，我們仍可以保證資料完整，但如果從庫宕機或網路阻塞，主庫就無法完成寫入操作，

在實踐中，我們通常使一個從庫是同步的，而其他的則是異步的，如果這個同步的從庫出現問題，則使另一個異步從庫同步，這可以確保永遠有兩個節點擁有完整資料：主庫和同步從庫， 這種配置稱為半同步，

X/Open DTP模型與XA規范

X/Open，即現在的open group，是一個獨立的組織，主要負責制定各種行業技術標準，官網地址：http://www.opengroup.org/，X/Open組織主要由各大知名公司或者廠商進行支持，這些組織不光遵循X/Open組織定義的行業技術標準，也參與到標準的制定，下圖展示了open group目前主要成員(官網截圖)：

DTP 參考模型：Distributed Transaction Processing: Reference Model

DTP XA規范： Distributed Transaction Processing: The XA Specification

參考檔案

維基百科——資料庫事務
維基百科——CAP定理
資料庫事務的概念及其實作原理
詳解分布式BASE定理
面試必問：分布式事務六種解決方案
漫畫：什么是分布式事務？
聊聊分布式事務，再說說解決方案
分布式事務？No, 最終一致性
CAP 定理的含義
分布式事務概述

我是御狐神，歡迎大家關注我的微信公眾號:wzm2zsd

本文最先發布至微信公眾號，著作權所有，禁止轉載！

標籤：Java

上一篇：OA系統模塊設計方案

下一篇：第二章 大話MQ訊息中間件+JMS+AMQP核心知識 （2）