來(lái)源：http://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html

前言

開(kāi)始我們今天的話(huà)題，說(shuō)說(shuō)分布式事務(wù)，或者說(shuō)是我眼中的分布式事務(wù)，因?yàn)槊總€(gè)人可能對(duì)其的理解都不一樣。
分布式事務(wù)是企業(yè)集成中的一個(gè)技術(shù)難點(diǎn)，也是每一個(gè)分布式系統(tǒng)架構(gòu)中都會(huì)涉及到的一個(gè)東西，特別是在微服務(wù)架構(gòu)中，幾乎可以說(shuō)是無(wú)法避免，本文就分布式事務(wù)來(lái)簡(jiǎn)單聊一下。

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

在說(shuō)分布式事務(wù)之前，我們先從數(shù)據(jù)庫(kù)事務(wù)說(shuō)起。數(shù)據(jù)庫(kù)事務(wù)可能大家都很熟悉，在開(kāi)發(fā)過(guò)程中也會(huì)經(jīng)常使用到。但是即使如此，可能對(duì)于一些細(xì)節(jié)問(wèn)題，很多人仍然不清楚。比如很多人都知道數(shù)據(jù)庫(kù)事務(wù)的幾個(gè)特性：原子性(Atomicity )、一致性( Consistency )、隔離性或獨(dú)立性( Isolation)和持久性(Durabilily)，簡(jiǎn)稱(chēng)就是ACID。但是再往下比如問(wèn)到隔離性指的是什么的時(shí)候可能就不知道了，或者是知道隔離性是什么但是再問(wèn)到數(shù)據(jù)庫(kù)實(shí)現(xiàn)隔離的都有哪些級(jí)別，或者是每個(gè)級(jí)別他們有什么區(qū)別的時(shí)候可能就不知道了。本文并不打算介紹這些數(shù)據(jù)庫(kù)事務(wù)的這些東西，有興趣可以搜索一下相關(guān)資料。不過(guò)有一個(gè)知識(shí)點(diǎn)我們需要了解，就是假如數(shù)據(jù)庫(kù)在提交事務(wù)的時(shí)候突然斷電，那么它是怎么樣恢復(fù)的呢？為什么要提到這個(gè)知識(shí)點(diǎn)呢？因?yàn)榉植际较到y(tǒng)的核心就是處理各種異常情況，這也是分布式系統(tǒng)復(fù)雜的地方，因?yàn)榉植际降木W(wǎng)絡(luò)環(huán)境很復(fù)雜，這種“斷電”故障要比單機(jī)多很多，所以我們?cè)谧龇植际较到y(tǒng)的時(shí)候，最先考慮的就是這種情況。這些異?？赡苡?機(jī)器宕機(jī)、網(wǎng)絡(luò)異常、消息丟失、消息亂序、數(shù)據(jù)錯(cuò)誤、不可靠的TCP、存儲(chǔ)數(shù)據(jù)丟失、其他異常等等...我們接著說(shuō)本地事務(wù)數(shù)據(jù)庫(kù)斷電的這種情況，它是怎么保證數(shù)據(jù)一致性的呢？我們使用SQL Server來(lái)舉例，我們知道我們?cè)谑褂?SQL Server 數(shù)據(jù)庫(kù)是由兩個(gè)文件組成的，一個(gè)數(shù)據(jù)庫(kù)文件和一個(gè)日志文件，通常情況下，日志文件都要比數(shù)據(jù)庫(kù)文件大很多。數(shù)據(jù)庫(kù)進(jìn)行任何寫(xiě)入操作的時(shí)候都是要先寫(xiě)日志的，同樣的道理，我們?cè)趫?zhí)行事務(wù)的時(shí)候數(shù)據(jù)庫(kù)首先會(huì)記錄下這個(gè)事務(wù)的redo操作日志，然后才開(kāi)始真正操作數(shù)據(jù)庫(kù)，在操作之前首先會(huì)把日志文件寫(xiě)入磁盤(pán)，那么當(dāng)突然斷電的時(shí)候，即使操作沒(méi)有完成，在重新啟動(dòng)數(shù)據(jù)庫(kù)時(shí)候，數(shù)據(jù)庫(kù)會(huì)根據(jù)當(dāng)前數(shù)據(jù)的情況進(jìn)行undo回滾或者是redo前滾，這樣就保證了數(shù)據(jù)的強(qiáng)一致性。接著，我們就說(shuō)一下分布式事務(wù)。

分布式理論

當(dāng)我們的單個(gè)數(shù)據(jù)庫(kù)的性能產(chǎn)生瓶頸的時(shí)候，我們可能會(huì)對(duì)數(shù)據(jù)庫(kù)進(jìn)行分區(qū)，這里所說(shuō)的分區(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è)新的理論原則來(lái)適應(yīng)這種集群的情況，就是 CAP 原則或者叫CAP定理，那么CAP定理指的是什么呢？

CAP定理

CAP定理是由加州大學(xué)伯克利分校Eric Brewer教授提出來(lái)的，他指出WEB服務(wù)無(wú)法同時(shí)滿(mǎn)足以下3個(gè)屬性：

• 一致性(Consistency) ：客戶(hù)端知道一系列的操作都會(huì)同時(shí)發(fā)生(生效)
• 可用性(Availability) ：每個(gè)操作都必須以可預(yù)期的響應(yīng)結(jié)束
• 分區(qū)容錯(cuò)性(Partition tolerance) ：即使出現(xiàn)單個(gè)組件無(wú)法可用,操作依然可以完成

具體地講在分布式系統(tǒng)中，在任何數(shù)據(jù)庫(kù)設(shè)計(jì)中，一個(gè)Web應(yīng)用至多只能同時(shí)支持上面的兩個(gè)屬性。顯然，任何橫向擴(kuò)展策略都要依賴(lài)于數(shù)據(jù)分區(qū)。因此，設(shè)計(jì)人員必須在一致性與可用性之間做出選擇。這個(gè)定理在迄今為止的分布式系統(tǒng)中都是適用的！?為什么這么說(shuō)呢？這個(gè)時(shí)候有同學(xué)可能會(huì)把數(shù)據(jù)庫(kù)的2PC（兩階段提交）搬出來(lái)說(shuō)話(huà)了。OK，我們就來(lái)看一下數(shù)據(jù)庫(kù)的兩階段提交。對(duì)數(shù)據(jù)庫(kù)分布式事務(wù)有了解的同學(xué)一定知道數(shù)據(jù)庫(kù)支持的2PC，又叫做 XA Transactions。

MySQL從5.5版本開(kāi)始支持，SQL Server 2005 開(kāi)始支持，Oracle 7 開(kāi)始支持。

其中，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ù)。

其中，如果有任何一個(gè)數(shù)據(jù)庫(kù)否決此次提交，那么所有數(shù)據(jù)庫(kù)都會(huì)被要求回滾它們?cè)诖耸聞?wù)中的那部分信息。這樣做的缺陷是什么呢? 咋看之下我們可以在數(shù)據(jù)庫(kù)分區(qū)之間獲得一致性。如果CAP 定理是對(duì)的，那么它一定會(huì)影響到可用性。如果說(shuō)系統(tǒng)的可用性代表的是執(zhí)行某項(xiàng)操作相關(guān)所有組件的可用性的和。那么在兩階段提交的過(guò)程中，可用性就代表了涉及到的每一個(gè)數(shù)據(jù)庫(kù)中可用性的和。我們假設(shè)兩階段提交的過(guò)程中每一個(gè)數(shù)據(jù)庫(kù)都具有99.9%的可用性，那么如果兩階段提交涉及到兩個(gè)數(shù)據(jù)庫(kù)，這個(gè)結(jié)果就是99.8%。根據(jù)系統(tǒng)可用性計(jì)算公式，假設(shè)每個(gè)月43200分鐘，99.9%的可用性就是43157分鐘, 99.8%的可用性就是43114分鐘，相當(dāng)于每個(gè)月的宕機(jī)時(shí)間增加了43分鐘。以上，可以驗(yàn)證出來(lái)，CAP定理從理論上來(lái)講是正確的，CAP我們先看到這里，等會(huì)再接著說(shuō)。

BASE理論

在分布式系統(tǒng)中，我們往往追求的是可用性，它的重要程序比一致性要高，那么如何實(shí)現(xiàn)高可用性呢？前人已經(jīng)給我們提出來(lái)了另外一個(gè)理論，就是BASE理論，它是用來(lái)對(duì)CAP定理進(jìn)行進(jìn)一步擴(kuò)充的。BASE理論指的是：

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

BASE理論是對(duì)CAP中的一致性和可用性進(jìn)行一個(gè)權(quán)衡的結(jié)果，理論的核心思想就是：我們無(wú)法做到強(qiáng)一致，但每個(gè)應(yīng)用都可以根據(jù)自身的業(yè)務(wù)特點(diǎn)，采用適當(dāng)?shù)姆绞絹?lái)使系統(tǒng)達(dá)到最終一致性（Eventual consistency）。有了以上理論之后，我們來(lái)看一下分布式事務(wù)的問(wèn)題。

分布式事務(wù)

在分布式系統(tǒng)中，要實(shí)現(xiàn)分布式事務(wù)，無(wú)外乎那幾種解決方案。

兩階段提交（2PC）

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

兩階段提交這種解決方案屬于犧牲了一部分可用性來(lái)?yè)Q取的一致性。在實(shí)現(xiàn)方面，在 .NET 中，可以借助 TransactionScop 提供的 API 來(lái)編程實(shí)現(xiàn)分布式系統(tǒng)中的兩階段提交，比如WCF中就有實(shí)現(xiàn)這部分功能。不過(guò)在多服務(wù)器之間，需要依賴(lài)于DTC來(lái)完成事務(wù)一致性，Windows下微軟搞的有MSDTC服務(wù)，Linux下就比較悲劇了。另外說(shuō)一句，TransactionScop 默認(rèn)不能用于異步方法之間事務(wù)一致，因?yàn)槭聞?wù)上下文是存儲(chǔ)于當(dāng)前線(xiàn)程中的，所以如果是在異步方法，需要顯式的傳遞事務(wù)上下文。優(yōu)點(diǎn)：?盡量保證了數(shù)據(jù)的強(qiáng)一致，適合對(duì)數(shù)據(jù)強(qiáng)一致要求很高的關(guān)鍵領(lǐng)域。（其實(shí)也不能100%保證強(qiáng)一致）。缺點(diǎn)：?實(shí)現(xiàn)復(fù)雜，犧牲了可用性，對(duì)性能影響較大，不適合高并發(fā)高性能場(chǎng)景，如果分布式系統(tǒng)跨接口調(diào)用，目前 .NET 界還沒(méi)有實(shí)現(xiàn)方案。

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

TCC 其實(shí)就是采用的補(bǔ)償機(jī)制，其核心思想是：針對(duì)每個(gè)操作，都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)和補(bǔ)償（撤銷(xiāo)）操作。它分為三個(gè)階段：

• Try 階段主要是對(duì)業(yè)務(wù)系統(tǒng)做檢測(cè)及資源預(yù)留
• Confirm 階段主要是對(duì)業(yè)務(wù)系統(tǒng)做確認(rèn)提交，Try階段執(zhí)行成功并開(kāi)始執(zhí)行 Confirm階段時(shí)，默認(rèn) Confirm階段是不會(huì)出錯(cuò)的。即：只要Try成功，Confirm一定成功。
• Cancel 階段主要是在業(yè)務(wù)執(zhí)行錯(cuò)誤，需要回滾的狀態(tài)下執(zhí)行的業(yè)務(wù)取消，預(yù)留資源釋放。

舉個(gè)例子，假如Bob 要向 Smith 轉(zhuǎn)賬，思路大概是：我們有一個(gè)本地方法，里面依次調(diào)用 1、首先在 Try 階段，要先調(diào)用遠(yuǎn)程接口把 Smith 和 Bob 的錢(qián)給凍結(jié)起來(lái)。2、在 Confirm 階段，執(zhí)行遠(yuǎn)程調(diào)用的轉(zhuǎn)賬的操作，轉(zhuǎn)賬成功進(jìn)行解凍。3、如果第2步執(zhí)行成功，那么轉(zhuǎn)賬成功，如果第二步執(zhí)行失敗，則調(diào)用遠(yuǎn)程凍結(jié)接口對(duì)應(yīng)的解凍方法 (Cancel)。優(yōu)點(diǎn)：?跟2PC比起來(lái)，實(shí)現(xiàn)以及流程相對(duì)簡(jiǎn)單了一些，但數(shù)據(jù)的一致性比2PC也要差一些缺點(diǎn)：?缺點(diǎn)還是比較明顯的，在2,3步中都有可能失敗。TCC屬于應(yīng)用層的一種補(bǔ)償方式，所以需要程序員在實(shí)現(xiàn)的時(shí)候多寫(xiě)很多補(bǔ)償?shù)拇a，在一些場(chǎng)景中，一些業(yè)務(wù)流程可能用TCC不太好定義及處理。

本地消息表（異步確保）

本地消息表這種實(shí)現(xiàn)方式應(yīng)該是業(yè)界使用最多的，其核心思想是將分布式事務(wù)拆分成本地事務(wù)進(jìn)行處理，這種思路是來(lái)源于ebay。我們可以從下面的流程圖中看出其中的一些細(xì)節(jié)：

基本思路就是：

消息生產(chǎn)方，需要額外建一個(gè)消息表，并記錄消息發(fā)送狀態(tài)。消息表和業(yè)務(wù)數(shù)據(jù)要在一個(gè)事務(wù)里提交，也就是說(shuō)他們要在一個(gè)數(shù)據(jù)庫(kù)里面。然后消息會(huì)經(jīng)過(guò)MQ發(fā)送到消息的消費(fèi)方。如果消息發(fā)送失敗，會(huì)進(jìn)行重試發(fā)送。消息消費(fèi)方，需要處理這個(gè)消息，并完成自己的業(yè)務(wù)邏輯。此時(shí)如果本地事務(wù)處理成功，表明已經(jīng)處理成功了，如果處理失敗，那么就會(huì)重試執(zhí)行。如果是業(yè)務(wù)上面的失敗，可以給生產(chǎn)方發(fā)送一個(gè)業(yè)務(wù)補(bǔ)償消息，通知生產(chǎn)方進(jìn)行回滾等操作。生產(chǎn)方和消費(fèi)方定時(shí)掃描本地消息表，把還沒(méi)處理完成的消息或者失敗的消息再發(fā)送一遍。如果有靠譜的自動(dòng)對(duì)賬補(bǔ)賬邏輯，這種方案還是非常實(shí)用的。這種方案遵循BASE理論，采用的是最終一致性，筆者認(rèn)為是這幾種方案里面比較適合實(shí)際業(yè)務(wù)場(chǎng)景的，即不會(huì)出現(xiàn)像2PC那樣復(fù)雜的實(shí)現(xiàn)(當(dāng)調(diào)用鏈很長(zhǎng)的時(shí)候，2PC的可用性是非常低的)，也不會(huì)像TCC那樣可能出現(xiàn)確認(rèn)或者回滾不了的情況。優(yōu)點(diǎn)：?一種非常經(jīng)典的實(shí)現(xiàn)，避免了分布式事務(wù)，實(shí)現(xiàn)了最終一致性。在 .NET中 有現(xiàn)成的解決方案。缺點(diǎn)：?消息表會(huì)耦合到業(yè)務(wù)系統(tǒng)中，如果沒(méi)有封裝好的解決方案，會(huì)有很多雜活需要處理。

MQ 事務(wù)消息

有一些第三方的MQ是支持事務(wù)消息的，比如RocketMQ，他們支持事務(wù)消息的方式也是類(lèi)似于采用的二階段提交，但是市面上一些主流的MQ都是不支持事務(wù)消息的，比如 RabbitMQ 和 Kafka 都不支持。以阿里的 RocketMQ 中間件為例，其思路大致為：第一階段Prepared消息，會(huì)拿到消息的地址。第二階段執(zhí)行本地事務(wù)，第三階段通過(guò)第一階段拿到的地址去訪(fǎng)問(wèn)消息，并修改狀態(tài)。也就是說(shuō)在業(yè)務(wù)方法內(nèi)要想消息隊(duì)列提交兩次請(qǐng)求，一次發(fā)送消息和一次確認(rèn)消息。如果確認(rèn)消息發(fā)送失敗了RocketMQ會(huì)定期掃描消息集群中的事務(wù)消息，這時(shí)候發(fā)現(xiàn)了Prepared消息，它會(huì)向消息發(fā)送者確認(rèn)，所以生產(chǎn)方需要實(shí)現(xiàn)一個(gè)check接口，RocketMQ會(huì)根據(jù)發(fā)送端設(shè)置的策略來(lái)決定是回滾還是繼續(xù)發(fā)送確認(rèn)消息。這樣就保證了消息發(fā)送與本地事務(wù)同時(shí)成功或同時(shí)失敗。

遺憾的是，RocketMQ并沒(méi)有 .NET 客戶(hù)端。優(yōu)點(diǎn)：?實(shí)現(xiàn)了最終一致性，不需要依賴(lài)本地?cái)?shù)據(jù)庫(kù)事務(wù)。

缺點(diǎn)：?實(shí)現(xiàn)難度大，主流MQ不支持，沒(méi)有.NET客戶(hù)端，RocketMQ事務(wù)消息部分代碼也未開(kāi)源。

Sagas 事務(wù)模型

Saga事務(wù)模型又叫做長(zhǎng)時(shí)間運(yùn)行的事務(wù)（Long-running-transaction）, 它是由普林斯頓大學(xué)的H.Garcia-Molina等人提出，它描述的是另外一種在沒(méi)有兩階段提交的的情況下解決分布式系統(tǒng)中復(fù)雜的業(yè)務(wù)事務(wù)問(wèn)題。我們這里說(shuō)的是一種基于 Sagas 機(jī)制的工作流事務(wù)模型，這個(gè)模型的相關(guān)理論目前來(lái)說(shuō)還是比較新的，以至于百度上幾乎沒(méi)有什么相關(guān)資料。該模型其核心思想就是拆分分布式系統(tǒng)中的長(zhǎng)事務(wù)為多個(gè)短事務(wù)，或者叫多個(gè)本地事務(wù)，然后由 Sagas 工作流引擎負(fù)責(zé)協(xié)調(diào)，如果整個(gè)流程正常結(jié)束，那么就算是業(yè)務(wù)成功完成，如果在這過(guò)程中實(shí)現(xiàn)失敗，那么Sagas工作流引擎就會(huì)以相反的順序調(diào)用補(bǔ)償操作，重新進(jìn)行業(yè)務(wù)回滾。比如我們一次關(guān)于購(gòu)買(mǎi)旅游套餐業(yè)務(wù)操作涉及到三個(gè)操作，他們分別是預(yù)定車(chē)輛，預(yù)定賓館，預(yù)定機(jī)票，他們分別屬于三個(gè)不同的遠(yuǎn)程接口。可能從我們程序的角度來(lái)說(shuō)他們不屬于一個(gè)事務(wù)，但是從業(yè)務(wù)角度來(lái)說(shuō)是屬于同一個(gè)事務(wù)的。

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

因?yàn)殚L(zhǎng)事務(wù)被拆分了很多個(gè)業(yè)務(wù)流，所以 Sagas 事務(wù)模型最重要的一個(gè)部件就是工作流或者你也可以叫流程管理器（Process Manager），工作流引擎和Process Manager雖然不是同一個(gè)東西，但是在這里，他們的職責(zé)是相同的。在選擇工作流引擎之后，最終的代碼也許看起來(lái)是這樣的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)這里我們就不說(shuō)了，因?yàn)檫@個(gè)理論比較新，目前市面上還沒(méi)有什么解決方案，即使是 Java 領(lǐng)域，我也沒(méi)有搜索的太多有用的信息。

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

上面介紹的那些分布式事務(wù)的處理方案你在其他地方或許也可以看到，但是并沒(méi)有相關(guān)的實(shí)際代碼或者是開(kāi)源代碼，所以算不上什么干貨，下面就放干貨了。在 .NET 領(lǐng)域，似乎沒(méi)有什么現(xiàn)成的關(guān)于分布式事務(wù)的解決方案，或者說(shuō)是有但未開(kāi)源。據(jù)筆者了解，有一些公司內(nèi)部其實(shí)是有這種解決方案的，但是也是作為公司的一個(gè)核心產(chǎn)品之一，并未開(kāi)源...鑒于以上原因，所以博主就打算自己寫(xiě)一個(gè)并且開(kāi)源出來(lái)，所以從17年初就開(kāi)始做這個(gè)事情，然后花了大半年的時(shí)間在一直不斷完善，就是下面這個(gè) CAP。Github CAP：這里的 CAP 就不是 CAP 理論了，而是一個(gè) .NET 分布式事務(wù)解決方案的名字。詳細(xì)介紹：http://www.cnblogs.com/savorboard/p/cap.html相關(guān)文檔：http://www.cnblogs.com/savorboard/p/cap-document.html夸張的是，這個(gè)解決方案是具有可視化界面（Dashboard）的，你可以很方面的看到哪些消息執(zhí)行成功，哪些消息執(zhí)行失敗，到底是發(fā)送失敗還是處理失敗，一眼便知。最夸張的是，這個(gè)解決方案的可視化界面還提供了實(shí)時(shí)動(dòng)態(tài)圖表，這樣不但可以看到實(shí)時(shí)的消息發(fā)送及處理情況，連當(dāng)前的系統(tǒng)處理消息的速度都可以看到，還可以看到過(guò)去24小時(shí)內(nèi)的歷史消息吞吐量。最最夸張的是，這個(gè)解決方案的還幫你集成了 Consul 做分布式節(jié)點(diǎn)發(fā)現(xiàn)和注冊(cè)還有心跳檢查，你隨時(shí)可以看到其他的節(jié)點(diǎn)的狀況。最最最夸張的是，你以為你看其他節(jié)點(diǎn)的數(shù)據(jù)要登錄到其他節(jié)點(diǎn)的Dashboard控制臺(tái)看？錯(cuò)了，你隨便打開(kāi)其中任意一個(gè)節(jié)點(diǎn)的Dashboard，點(diǎn)一下就可以切換到你想看的節(jié)點(diǎn)的控制臺(tái)界面了，就像你看本地的數(shù)據(jù)一樣，他們是完全去中心化的。

你以為這些就夠了？不，遠(yuǎn)遠(yuǎn)不止：

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

你完全可以把 CAP 當(dāng)做一個(gè) EventBus 來(lái)使用，CAP具有優(yōu)秀的消息處理能力，不要擔(dān)心瓶頸會(huì)在CAP，那是永遠(yuǎn)不可能， 因?yàn)槟汶S時(shí)可以在配置中指定CAP處理的消息使用的進(jìn)程數(shù)， 只要你的數(shù)據(jù)庫(kù)配置足夠高...2號(hào)傳送門(mén)：https://github.com/dotnetcore/CAP

總結(jié)

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