本文先介紹傳統(tǒng)關系數(shù)據(jù)庫中事務的ACID特性德撬，再介紹分布式系統(tǒng)中的經(jīng)典理論——CAP定理和BASE理論蜓洪。

事務

事務的定義：

事務（Transaction）是由一系列對系統(tǒng)中數(shù)據(jù)進行訪問與更新的操作所組成的一個程序執(zhí)行邏輯單元（Unit）纤勒，狹義上的事務特指數(shù)據(jù)庫事務摇天。

事務的作用：

當多個應用程序并發(fā)訪問數(shù)據(jù)庫時恐仑，事務可以在這些應用程序之間提供一個隔離方法，以防止彼此的操作相互干擾坚冀。-事務為數(shù)據(jù)庫操作序列提供了一個從失敗中恢復到正常狀態(tài)的方法鉴逞，同時提供了數(shù)據(jù)庫即使在異常狀態(tài)下仍能保持數(shù)據(jù)一致性的方法司训。事務具有四個特性壳猜，分別是原子性（Atomicity）滑凉、一致性（Consistency）、隔離性（Isolation）和持久性（Durability）,簡稱為事務的ACID特性咒钟。

ACID

原子性

事務的原子性是指事務必須是一個原子的操作序列單元若未。事務中包含的各項操作在一次執(zhí)行過程中，要么全部執(zhí)行粗合，要么全部不執(zhí)行隙疚。任何一項操作失敗都將導致整個事務失敗，同時其他已經(jīng)被執(zhí)行的操作都將被撤銷并回滾供屉。只有所有的操作全部成功伶丐，整個事務才算是成功完成。

一致性

事務的一致性是指事務的執(zhí)行不能破壞數(shù)據(jù)庫數(shù)據(jù)的完整性和一致性撵割，一個事務在執(zhí)行前后啡彬，數(shù)據(jù)庫都必須處于一致性狀態(tài)故硅。換句話說，事務的執(zhí)行結果必須是使數(shù)據(jù)庫從一個一致性狀態(tài)轉(zhuǎn)變到另一個一致性狀態(tài)往踢。舉個例子銀行的轉(zhuǎn)賬操作就是一個事務徘层。假設A和B原來賬戶都有100元利职。此時A轉(zhuǎn)賬給B50元瘦癌，轉(zhuǎn)賬結束后，應該是A賬戶減去50元變成50元热押，B賬戶增加50元變成150元斤寇。A、B的賬戶總和還是200元牙寞。轉(zhuǎn)賬前后致盟，數(shù)據(jù)庫就是從一個一致性狀態(tài)（A100元馏锡，B100元，A杯道、B共200元）轉(zhuǎn)變到另一個一致性狀態(tài)（A50元党巾，B150元，A齿拂、B共200元）署海。假設轉(zhuǎn)賬結束后只扣了A賬戶，沒有增加B賬戶砸狞，這時數(shù)據(jù)庫就處于不一致的狀態(tài)。隔離性事務的隔離性是指在并發(fā)環(huán)境中刀森，并發(fā)的事務是相互隔離的，事務之間互不干擾埠偿。在標準的SQL規(guī)范中，定義的4個事務隔離級別琐凭，不同隔離級別對事務的處理不同浊服。4個隔離級別分別是：未授權讀取牙躺、授權讀取、可重復讀取和串行化孽拷。下表展示了不同隔離級別下事務訪問數(shù)據(jù)的差異 ? ??

以上4個級別的隔離性依次增強脓恕，分別解決不同的問題。事務隔離級別越高秋茫，就越能保證數(shù)據(jù)的完整性和一致性乃秀，但同時對并發(fā)性能的影響也越大。通常枢贿，對于絕大多數(shù)的應用來說刀脏，可以優(yōu)先考慮將數(shù)據(jù)庫系統(tǒng)的隔離級別設置為授權讀取，這能夠在避免臟讀的同時保證較好的并發(fā)性能危队。盡管這種事務隔離級別會導致不可重復讀钙畔、幻讀和第二類丟失更新等并發(fā)問題擎析，但較為科學的做法是在可能出現(xiàn)這類問題的個別場合中，由應用程序主動采用悲觀鎖或樂觀鎖來進行事務控制揍魂。持久性事務的持久性又稱為永久性现斋，是指一個事務一旦提交，對數(shù)據(jù)庫中對應數(shù)據(jù)的狀態(tài)變更就應該是永久性的瞬内。即使發(fā)生系統(tǒng)崩潰或機器宕機等故障限书，只要數(shù)據(jù)庫能夠重新啟動，那么一定能夠?qū)⑵浠謴偷绞聞粘晒Y束時的狀態(tài)能真。

分布式事務

事務在分布式計算領域也得到了廣泛的應用扰柠。在單機數(shù)據(jù)庫中，我們很容易能夠?qū)崿F(xiàn)一套滿足ACID特性的事務處理系統(tǒng)蝙泼，但是在分布式數(shù)據(jù)庫中裆装，數(shù)據(jù)分散在各臺不同的機器上，如何對這些數(shù)據(jù)進行分布式事務處理具有非常大的挑戰(zhàn)茎活。-分布式事務是指事務的參與者琢唾、支持事務的服務器采桃、資源服務器以及事務管理器分別位于分布式系統(tǒng)的不同節(jié)點之上。通常一個分布式事務會涉及對多個數(shù)據(jù)源或業(yè)務系統(tǒng)的操作工扎。舉個例子來說明分布式事務衔蹲。一個最典型的分布式事務場景是跨行的轉(zhuǎn)賬操作。該操作涉及調(diào)用兩個異地的銀行服務橱健。其中一個是本地銀行提供的取款服務，另一個是目標銀行提供的存款服務臼节，這兩個服務本身是無狀態(tài)且相互獨立的珊皿，共同構成了一個完整的分布式事務。取款和存款兩個步驟要么都執(zhí)行途凫，要么都不執(zhí)行溢吻。否則，如果從本地銀行取款成功犀盟，但是因為某種原因存款服務失敗了蝇狼，那么必須回滾到取款之前的狀態(tài)迅耘，否則就會導致數(shù)據(jù)不一致。從上面的例子可以看出纽哥，一個分布式事務可以看作是由多個分布式操作序列組成的栖秕，例如上面例子中的取款服務和存款服務，通持豢牵可以把這一系列分布式的操作序列稱為子事暑塑。由于分布式事務中事格，各個子事務的執(zhí)行是分布式的况毅，因此要實現(xiàn)一種能夠保證ACID特性的分布式事務處理系統(tǒng)就顯得格外復雜尔艇。

CAP定理

CAP定理：一個分布式系統(tǒng)不可能同時滿足一致性（C:Consistency）么鹤、可用性（A:Availability）和分區(qū)容錯性（P:Partition

tolerance）這三個基本要求蒸甜，最多只能滿足其中的兩項。

一致性

在分布式環(huán)境中窍荧，一致性是指數(shù)據(jù)在多個副本之間是否能夠保持一致的特性（這點跟ACID中的一致性含義不同）恨憎。對于一個將數(shù)據(jù)副本分布在不同節(jié)點上的分布式系統(tǒng)來說，如果對第一個節(jié)點的數(shù)據(jù)進行了更新操作并且更新成功后瓤荔，卻沒有使得第二個節(jié)點上的數(shù)據(jù)得到相應的更新钥组，于是在對第二個節(jié)點的數(shù)據(jù)進行讀取操作時程梦，獲取的依然是更新前的數(shù)據(jù)（稱為臟數(shù)據(jù)），這就是典型的分布式數(shù)據(jù)不一致情況郎逃。在分布式系統(tǒng)中拿撩，如果能夠做到針對一個數(shù)據(jù)項的更新操作執(zhí)行成功后，所有的用戶都能讀取到最新的值影暴，那么這樣的系統(tǒng)就被認為具有強一致性（或嚴格的一致性）探赫。

可用性

可用性是指系統(tǒng)提供的服務必須一直處于可用的狀態(tài)伦吠，對于用戶的每一個操作請求總是能夠*有限的時間內(nèi)返回結果魂拦，如果超過了這個時間范圍搁嗓，那么系統(tǒng)就被認為是不可用的腺逛。『有限的時間內(nèi)』是一個在系統(tǒng)設計之初就設定好的運行指標安疗，不同的系統(tǒng)會有很大的差別够委。比如對于一個在線搜索引擎來說，通常在0.5秒內(nèi)需要給出用戶搜索關鍵詞對應的檢索結果玉罐。而對應Hive來說厌小，一次正常的查詢時間可能在20秒到30秒之間⊙Ⅲ『返回結果』是可用性的另一個非常重要的指標埋泵，它要求系統(tǒng)在完成對用戶請求的處理后丽声，返回一個正常的響應結果浴井。正常的響應結果通常能夠明確地反映出對請求的處理結果，及成功或失敗撕氧，而不是一個讓用戶感到困惑的返回結果。讓我們再來看看上面提到的在線搜索引擎的例子，如果用戶輸入指定的搜索關鍵詞后，返回的結果是一個系統(tǒng)錯誤，比如"OutOfMemoryErroe"或"System

Has Crashed"等提示語，那么我們認為此時系統(tǒng)是不可用的浮入。

分區(qū)容錯性

分區(qū)容錯性要求一個分布式系統(tǒng)需要具備如下特性：分布式系統(tǒng)在遇到任何網(wǎng)絡分區(qū)故障的時候，仍然能夠保證對外提供滿足一致性和可用性的服務易迹，除非是整個網(wǎng)絡環(huán)境都發(fā)生了故障供炼。網(wǎng)絡分區(qū)是指在分布式系統(tǒng)中，不同的節(jié)點分布在不同的**子網(wǎng)絡**（機房或異地網(wǎng)絡等）中先嬉，由于一些特殊的原因?qū)е逻@些子網(wǎng)絡之間出現(xiàn)網(wǎng)絡不連通的狀況含懊，但各個子網(wǎng)絡的**內(nèi)部網(wǎng)絡是正常的**，從而導致整個系統(tǒng)的網(wǎng)絡環(huán)境被切分成了若干個孤立的區(qū)域。以上就是對CAP定理中一致性茁影、可用性和分區(qū)容錯性的講解愿待。既然一個分布式系統(tǒng)無法同時滿足上述三個要求要出，而只能滿足其中的兩項，因此在對CAP定理應用時况脆，我們就需要拋棄其中的一項，下表是拋棄CAP中任意一項特性的場景說明。

BASE是Basically

Available(基本可用）、Soft state(軟狀態(tài)）和Eventually consistent(最終一致性）三個短語的簡寫。BASE是對CAP中一致性和可用性權衡的結果嚎京，其來源于對大規(guī)陌暗郏互聯(lián)網(wǎng)系統(tǒng)分布式實踐的總結，是基于CAP定理逐步演化而來的，其核心思想是即使無法做到強一致性亲澡，但每個應用都可以根據(jù)自身的業(yè)務特點纫版，采用適當?shù)姆椒▉硎瓜到y(tǒng)達到最終一致性捎琐。接下來瑞凑，我們著重對BASE中的三要素進行講解籽御。

基本可用

基本可用是指分布式系統(tǒng)在出現(xiàn)不可預知故障的時候技掏，允許損失部分可用性——但請注意项鬼，這絕不等價于系統(tǒng)不可用。一下就是兩個"基本可用"的例子鸠真。-響應時間上的損失：正常情況下龄毡，一個在線搜索引擎需要在0.5秒之內(nèi)返回給用戶相應的查詢結果祭隔，但由于出現(xiàn)故障（比如系統(tǒng)部分機房發(fā)生斷電或斷網(wǎng)故障）疾渴，查詢結果的響應時間增加到了1~2秒丈牢。-功能上的損失：正常情況下申尼，在一個電子商務網(wǎng)站（比如淘寶）上購物师幕，消費者幾乎能夠順利地完成每一筆訂單疼鸟。但在一些節(jié)日大促購物高峰的時候（比如雙十一、雙十二）空镜，由于消費者的購物行為激增吴攒，為了保護系統(tǒng)的穩(wěn)定性（或者保證一致性），部分消費者可能會被引導到一個降級頁面署惯，如下：

軟狀態(tài)

軟狀態(tài)是指允許系統(tǒng)中的數(shù)據(jù)存在中間狀態(tài)泽台，并認為該中間狀態(tài)的存在不會影響系統(tǒng)的整體可用性矾缓，即允許系統(tǒng)在不同的數(shù)據(jù)副本之間進行數(shù)據(jù)同步的過程存在延時嗜闻。

最終一致性

最終一致性強調(diào)的是系統(tǒng)中所有的數(shù)據(jù)副本，在經(jīng)過一段時間的同步后样眠，最終能夠達到一個一致的狀態(tài)。因此辫秧，最終一致性的本質(zhì)是需要系統(tǒng)保證最終數(shù)據(jù)能夠達到一致盟戏，而不需要實時保證系統(tǒng)數(shù)據(jù)的強一致性甥桂。最終一致性是一種特殊的弱一致性：系統(tǒng)能夠保證在沒有其他新的更新操作的情況下黄选，數(shù)據(jù)最終一定能夠達到一致的狀態(tài)，因此所有客戶端對系統(tǒng)的數(shù)據(jù)訪問都能夠獲取到最新的值貌夕。同時民镜，在沒有發(fā)生故障的前提下殃恒，數(shù)據(jù)到達一致狀態(tài)的時間延遲辱揭，取決于網(wǎng)絡延遲问窃、系統(tǒng)負載和數(shù)據(jù)復制方案設計等因素。在實際工程實踐中嵌戈，最終一致性存在一下五類主要變種听皿。-因果一致性(Causal consistency)-讀己之所寫(Read your writes)-會話一致性(Session consistency)-單調(diào)讀一致性(Monotonic read consistency)-單調(diào)寫一致性(Monotonic write consistency)以上就是最終一致性的五種常見的變種尉姨，在實際系統(tǒng)實踐中，可以將其中的若干個變種互相結合起來九府，以構建一個具有最終一致性特性的分布式系統(tǒng)。

事實上肺蔚，最終一致性并不是只有那些大型分布式系統(tǒng)才涉及的特性宣羊，許多現(xiàn)代的關系型數(shù)據(jù)庫都采用了最終一致性模型笔链。在現(xiàn)代關系型數(shù)據(jù)庫中（比如MySQL和PostgreSQL）鉴扫，大多都會采用同步或異步方式來實現(xiàn)主備數(shù)據(jù)復制技術。在同步方式中炕婶，數(shù)據(jù)的復制過程通常是更新事務的一部分莱预，因此在事務完成后，主備數(shù)據(jù)庫的數(shù)據(jù)就會達到一致涯贞。而在異步方式中危喉，備庫的更新往往會存在延時宋渔，這取決于事務日志在主備數(shù)據(jù)庫之間傳輸?shù)臅r間長短。如果傳輸時間過長或者甚至在日志傳輸過程中出現(xiàn)異常導致無法及時將事務應用到備庫上辜限，那么很顯然皇拣，從備庫中讀取的數(shù)據(jù)將是舊的，因此就出現(xiàn)了數(shù)據(jù)不一致的情況薄嫡。當然氧急，無論是采用多次重試還是人為數(shù)據(jù)訂正，關系型數(shù)據(jù)庫還是能夠保證最終數(shù)據(jù)達到一致毫深，這就是系統(tǒng)提供最終一致性保證的經(jīng)典案例吩坝。

參考資料

《從Paxos到ZooKeeper——分布式一致性原理與實踐》

如果你想學習Java工程化、高性能及分布式哑蔫、高性能手素、深入淺出。性能調(diào)優(yōu)瘩蚪、Spring泉懦，MyBatis，Netty源碼分析和大數(shù)據(jù)等知識點可以來找我疹瘦。

而現(xiàn)在我就有一個平臺可以提供給你們學習崩哩，讓你在實踐中積累經(jīng)驗掌握原理。主要方向是JAVA架構師言沐。如果你想拿高薪邓嘹，想突破瓶頸，想跟別人競爭能取得優(yōu)勢的险胰，想進BAT但是有擔心面試不過的汹押，可以加我的Java架構進階群：554355695

注：加群要求

1、具有2-5工作經(jīng)驗的起便，面對目前流行的技術不知從何下手棚贾，需要突破技術瓶頸的可以加。

2榆综、在公司待久了妙痹，過得很安逸，但跳槽時面試碰壁鼻疮。需要在短時間內(nèi)進修怯伊、跳槽拿高薪的可以加。

3判沟、如果沒有工作經(jīng)驗耿芹，但基礎非常扎實，對java工作機制挪哄，常用設計思想吧秕，常用java開發(fā)框架掌握熟練的，可以加中燥。

4寇甸、覺得自己很牛B塘偎，一般需求都能搞定疗涉。但是所學的知識點沒有系統(tǒng)化，很難在技術領域繼續(xù)突破的可以加吟秩。

5.阿里Java高級大牛直播講解知識點咱扣，分享知識，多年工作經(jīng)驗的梳理和總結涵防，帶著大家全面闹伪、科學地建立自己的技術體系和技術認知！

6.小號加群一律不給過，謝謝偏瓤。