面試官：聊聊分布式事務(wù)，再說說解決方案！

來源：http://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html

前言

數(shù)據(jù)庫(kù)事務(wù)

分布式理論

當(dāng)我們的單個(gè)數(shù)據(jù)庫(kù)的性能產(chǎn)生瓶頸的時(shí)候，我們可能會(huì)對(duì)數(shù)據(jù)庫(kù)進(jìn)行分區(qū)，這里所說的分區(qū)指的是物理分區(qū)，分區(qū)之后可能不同的庫(kù)就處于不同的服務(wù)器上了，這個(gè)時(shí)候單個(gè)數(shù)據(jù)庫(kù)的ACID已經(jīng)不能適應(yīng)這種情況了，而在這種ACID的集群環(huán)境下，再想保證集群的ACID幾乎是很難達(dá)到，或者即使能達(dá)到那么效率和性能會(huì)大幅下降，最為關(guān)鍵的是再很難擴(kuò)展新的分區(qū)了，這個(gè)時(shí)候如果再追求集群的ACID會(huì)導(dǎo)致我們的系統(tǒng)變得很差，這時(shí)我們就需要引入一個(gè)新的理論原則來適應(yīng)這種集群的情況，就是 CAP 原則或者叫CAP定理，那么CAP定理指的是什么呢？

CAP定理

• 一致性(Consistency) ：客戶端知道一系列的操作都會(huì)同時(shí)發(fā)生(生效)
• 可用性(Availability) ：每個(gè)操作都必須以可預(yù)期的響應(yīng)結(jié)束

• 分區(qū)容錯(cuò)性(Partition tolerance) ：即使出現(xiàn)單個(gè)組件無法可用,操作依然可以完成

MySQL從5.5版本開始支持，SQL Server 2005 開始支持，Oracle 7 開始支持。

其中，XA 是一個(gè)兩階段提交協(xié)議，該協(xié)議分為以下兩個(gè)階段：

• 第一階段：事務(wù)協(xié)調(diào)器要求每個(gè)涉及到事務(wù)的數(shù)據(jù)庫(kù)預(yù)提交(precommit)此操作，并反映是否可以提交.
• 第二階段：事務(wù)協(xié)調(diào)器要求每個(gè)數(shù)據(jù)庫(kù)提交數(shù)據(jù)。

BASE理論

• Basically Available（基本可用）
• Soft state（軟狀態(tài)）
• Eventually consistent（最終一致性）

分布式事務(wù)

兩階段提交（2PC）

和上一節(jié)中提到的數(shù)據(jù)庫(kù)XA事務(wù)一樣，兩階段提交就是使用XA協(xié)議的原理，我們可以從下面這個(gè)圖的流程來很容易的看出中間的一些比如commit和abort的細(xì)節(jié)。

補(bǔ)償事務(wù)（TCC）

• Try 階段主要是對(duì)業(yè)務(wù)系統(tǒng)做檢測(cè)及資源預(yù)留
• Confirm 階段主要是對(duì)業(yè)務(wù)系統(tǒng)做確認(rèn)提交，Try階段執(zhí)行成功并開始執(zhí)行 Confirm階段時(shí)，默認(rèn) Confirm階段是不會(huì)出錯(cuò)的。即：只要Try成功，Confirm一定成功。

• Cancel 階段主要是在業(yè)務(wù)執(zhí)行錯(cuò)誤，需要回滾的狀態(tài)下執(zhí)行的業(yè)務(wù)取消，預(yù)留資源釋放。

本地消息表（異步確保）

基本思路就是：

MQ 事務(wù)消息

優(yōu)點(diǎn)： 實(shí)現(xiàn)了最終一致性，不需要依賴本地?cái)?shù)據(jù)庫(kù)事務(wù)。

Sagas 事務(wù)模型

他們的執(zhí)行順序如上圖所示，所以當(dāng)發(fā)生失敗時(shí)，會(huì)依次進(jìn)行取消的補(bǔ)償操作。

SagaBuilder saga = SagaBuilder.newSaga("trip")
        .activity("Reserve car", ReserveCarAdapter.class) 
        .compensationActivity("Cancel car", CancelCarAdapter.class) 
        .activity("Book hotel", BookHotelAdapter.class) 
        .compensationActivity("Cancel hotel", CancelHotelAdapter.class) 
        .activity("Book flight", BookFlightAdapter.class) 
        .compensationActivity("Cancel flight", CancelFlightAdapter.class) 
        .end()
        .triggerCompensationOnAnyError();

camunda.getRepositoryService().createDeployment() 
        .addModelInstance(saga.getModel()) 
        .deploy();

優(yōu)缺點(diǎn)這里我們就不說了，因?yàn)檫@個(gè)理論比較新，目前市面上還沒有什么解決方案，即使是 Java 領(lǐng)域，我也沒有搜索的太多有用的信息。

分布式事務(wù)解決方案：CAP

最最最夸張的是，你以為你看其他節(jié)點(diǎn)的數(shù)據(jù)要登錄到其他節(jié)點(diǎn)的Dashboard控制臺(tái)看？錯(cuò)了，你隨便打開其中任意一個(gè)節(jié)點(diǎn)的Dashboard，點(diǎn)一下就可以切換到你想看的節(jié)點(diǎn)的控制臺(tái)界面了，就像你看本地的數(shù)據(jù)一樣，他們是完全去中心化的。

• CAP 同時(shí)支持 RabbitMQ，Kafka 等消息隊(duì)列
• CAP 同時(shí)支持 SQL Server, MySql, PostgreSql 等數(shù)據(jù)庫(kù)
• CAP Dashboard 同時(shí)支持中文和英文界面雙語言，媽媽再也不用擔(dān)心我看不懂了
• CAP 提供了豐富的接口可以供擴(kuò)展，什么序列化了，自定義處理了，自定義發(fā)送了統(tǒng)統(tǒng)不在話下
• CAP 基于MIT開源，你可以盡管拿去做二次開發(fā)。（記得保留MIT的License）

總結(jié)

通過本文我們了解到兩個(gè)分布式系統(tǒng)的理論，他們分別是CAP和BASE 理論，同時(shí)我們也總結(jié)并對(duì)比了幾種分布式分解方案的優(yōu)缺點(diǎn)，分布式事務(wù)本身是一個(gè)技術(shù)難題，是沒有一種完美的方案應(yīng)對(duì)所有場(chǎng)景的，具體還是要根據(jù)業(yè)務(wù)場(chǎng)景去抉擇吧。然后我們介紹了一種基于本地消息的的分布式事務(wù)解決方案CAP。

— 【 THE END 】—
本公眾號(hào)全部博文已整理成一個(gè)目錄，請(qǐng)?jiān)诠娞?hào)里回復(fù)「m」獲取！
最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊(cè)》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫(kù)、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點(diǎn)“在看”，關(guān)注公眾號(hào)并回復(fù) PDF 領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
文章有幫助的話，在看，轉(zhuǎn)發(fā)吧。
謝謝支持喲 (*^__^*）