base cap 分布式_神一样的CAP理论被应用在何方？
對(duì)于開發(fā)或設(shè)計(jì)分布式系統(tǒng)的架構(gòu)師工程師來說，CAP 是必須要掌握的理論。
圖片來自 Pexels
But：這個(gè)文章的重點(diǎn)并不是討論 CAP 理論和細(xì)節(jié)，重點(diǎn)是說說 CAP 在微服務(wù)中的開發(fā)怎么起到一個(gè)指引作用，會(huì)通過幾個(gè)微服務(wù)開發(fā)的例子說明，盡量的去貼近開發(fā)。
CAP 定理又被稱為布魯爾定理，是加州大學(xué)計(jì)算機(jī)科學(xué)家埃里克·布魯爾提出來的猜想，后來被證明成為分布式計(jì)算領(lǐng)域公認(rèn)的定理。
不過布魯爾在出來 CAP 的時(shí)候并沒有對(duì) CAP 三者(Consistency，Availability，Partition tolerance)進(jìn)行詳細(xì)的定義，所以在網(wǎng)上也出現(xiàn)了不少對(duì) CAP 不同解讀的聲音。
CAP 定理
CAP 定理在發(fā)展中存在過兩個(gè)版本，我們以第二個(gè)版本為準(zhǔn)：在一個(gè)分布式系統(tǒng)中(指互相連接并共享數(shù)據(jù)的節(jié)點(diǎn)集合)中，當(dāng)涉及到讀寫操作時(shí)，只能保證一致性(Consistence)、可用性(Availability)、分區(qū)容錯(cuò)性(Partition Tolerance)三者中的兩個(gè)，另外一個(gè)必須被犧牲。
這個(gè)版本的 CAP 理論在探討分布式系統(tǒng)，更加強(qiáng)調(diào)兩點(diǎn)是互聯(lián)和共享數(shù)據(jù)，其實(shí)也是理清楚了第一個(gè)版本中三選二的一些缺陷。
分布式系統(tǒng)不一定都存在互聯(lián)和共享數(shù)據(jù)，例如 Memcached 集群相互間就沒有存在連接和共享數(shù)據(jù)。
所以 Memcached 集群這類的分布式系統(tǒng)并不在?CAP 理論討論的范圍，而像?MySQL 集群就是互聯(lián)和數(shù)據(jù)共享復(fù)制，因此?MySQL?集群是屬于 CAP 理論討論的對(duì)象。
一致性(Consistency)
一致性意思就是寫操作之后進(jìn)行讀操作無論在哪個(gè)節(jié)點(diǎn)都需要返回寫操作的值。
可用性(Availability)
非故障的節(jié)點(diǎn)在合理的時(shí)間內(nèi)返回合理的響應(yīng)。
分區(qū)容錯(cuò)性(Partition Tolerance)
當(dāng)網(wǎng)絡(luò)出現(xiàn)分區(qū)后，系統(tǒng)依然能夠繼續(xù)旅行社職責(zé)。
在分布式的環(huán)境下，網(wǎng)絡(luò)無法做到 100% 可靠，有可能出現(xiàn)故障，因此分區(qū)是一個(gè)必須的選項(xiàng)。
如果選擇了 CA 而放棄了 P，若發(fā)生分區(qū)現(xiàn)象，為了保證 C，系統(tǒng)需要禁止寫入，此時(shí)就與 A 發(fā)生沖突；如果是為了保證 A，則會(huì)出現(xiàn)正常的分區(qū)可以寫入數(shù)據(jù)，有故障的分區(qū)不能寫入數(shù)據(jù)，則與 C 就沖突了。
因此分布式系統(tǒng)理論上不可能選擇 CA 架構(gòu)，而必須選擇 CP 或 AP 架構(gòu)。
分布式事務(wù) BASE?理論
BASE 理論是對(duì) CAP 的延伸和補(bǔ)充，是對(duì) CAP 中的 AP 方案的一個(gè)補(bǔ)充，即使在選擇 AP 方案的情況下，如何更好的最終達(dá)到 C。
BASE 是基本可用，柔性狀態(tài)，最終一致性三個(gè)短語的縮寫，核心的思想是即使無法做到強(qiáng)一致性，但應(yīng)用可以采用適合的方式達(dá)到最終一致性。
CAP 在服務(wù)中實(shí)際的應(yīng)用例子
理解貌似講多了，項(xiàng)目的 CAP 可以參考下李運(yùn)華的《從零開始學(xué)架構(gòu)》的書里面的 21，22 章，比較詳細(xì)的描繪了 CAP 的理論細(xì)節(jié)和 CAP 的版本演化過程。
這里著重講解的是神一樣的 CAP 在我們的微服務(wù)中怎么去指導(dǎo)和應(yīng)用起來，大概會(huì)舉幾個(gè)平時(shí)常見的例子。服務(wù)注冊(cè)中心，是選擇 CA 還是選擇 CP？
服務(wù)注冊(cè)中心解決的問題
在討論 CAP 之前先明確下服務(wù)注冊(cè)中心主要是解決什么問題：
服務(wù)注冊(cè)：實(shí)例將自身服務(wù)信息注冊(cè)到注冊(cè)中心，這部分信息包括服務(wù)的主機(jī) IP 和服務(wù)的 Port，以及暴露服務(wù)自身狀態(tài)和訪問協(xié)議信息等。
服務(wù)發(fā)現(xiàn)：實(shí)例請(qǐng)求注冊(cè)中心所依賴的服務(wù)信息，服務(wù)實(shí)例通過注冊(cè)中心，獲取到注冊(cè)到其中的服務(wù)實(shí)例的信息，通過這些信息去請(qǐng)求它們提供的服務(wù)。
Dubbo 的 Zookeeper
Spring Cloud 的 Eureka，Consul
RocketMQ?的 nameServer
HDFS 的 nameNode
Zookeeper 選擇 CP
Zookeeper 保證 CP，即任何時(shí)刻對(duì) Zookeeper 的訪問請(qǐng)求能得到一致性的數(shù)據(jù)結(jié)果，同時(shí)系統(tǒng)對(duì)網(wǎng)絡(luò)分割具備容錯(cuò)性，但是它不能保證每次服務(wù)的可用性。從實(shí)際情況來分析，在使用 Zookeeper 獲取服務(wù)列表時(shí)，如果 ZK 正在選舉或者 ZK 集群中半數(shù)以上的機(jī)器不可用，那么將無法獲取數(shù)據(jù)。所以說，ZK 不能保證服務(wù)可用性。Eureka?選擇?AP
Eureka 保證 AP，Eureka 在設(shè)計(jì)時(shí)優(yōu)先保證可用性，每一個(gè)節(jié)點(diǎn)都是平等的。一部分節(jié)點(diǎn)掛掉不會(huì)影響到正常節(jié)點(diǎn)的工作，不會(huì)出現(xiàn)類似 ZK 的選舉 Leader 的過程，客戶端發(fā)現(xiàn)向某個(gè)節(jié)點(diǎn)注冊(cè)或連接失敗，會(huì)自動(dòng)切換到其他的節(jié)點(diǎn)。只要有一臺(tái) Eureka 存在，就可以保證整個(gè)服務(wù)處在可用狀態(tài)，只不過有可能這個(gè)服務(wù)上的信息并不是最新的信息。ZK?和 Eureka 的數(shù)據(jù)一致性問題
先要明確一點(diǎn)，Eureka 的創(chuàng)建初心就是為一個(gè)注冊(cè)中心，但是 ZK 更多是作為分布式協(xié)調(diào)服務(wù)的存在。只不過因?yàn)樗奶匦员?Dubbo 賦予了注冊(cè)中心，它的職責(zé)更多是保證數(shù)據(jù)(配置數(shù)據(jù)，狀態(tài)數(shù)據(jù))在管轄下的所有服務(wù)之間保持一致。所以這個(gè)就不難理解為何 ZK 被設(shè)計(jì)成 CP 而不是 AP，ZK 最核心的算法 ZAB，就是為了解決分布式系統(tǒng)下數(shù)據(jù)在多個(gè)服務(wù)之間一致同步的問題。更深層的原因，ZK 是按照 CP 原則構(gòu)建，也就是說它必須保持每一個(gè)節(jié)點(diǎn)的數(shù)據(jù)都保持一致。如果 ZK 下節(jié)點(diǎn)斷開或者集群中出現(xiàn)網(wǎng)絡(luò)分割(例如交換機(jī)的子網(wǎng)間不能互訪)，那么 ZK 會(huì)將它們從自己的管理范圍中剔除，外界不能訪問這些節(jié)點(diǎn)，即使這些節(jié)點(diǎn)是健康的可以提供正常的服務(wù)，所以導(dǎo)致這些節(jié)點(diǎn)請(qǐng)求都會(huì)丟失。而 Eureka 則完全沒有這方面的顧慮，它的節(jié)點(diǎn)都是相對(duì)獨(dú)立，不需要考慮數(shù)據(jù)一致性的問題，這個(gè)應(yīng)該是 Eureka 的誕生就是為了注冊(cè)中心而設(shè)計(jì)。相對(duì) ZK 來說剔除了 Leader 節(jié)點(diǎn)選取和事務(wù)日志機(jī)制，這樣更有利于維護(hù)和保證 Eureka 在運(yùn)行的健壯性。
再來看看，數(shù)據(jù)不一致性在注冊(cè)服務(wù)中會(huì)給 Eureka 帶來什么問題，無非就是某一個(gè)節(jié)點(diǎn)被注冊(cè)的服務(wù)多，某個(gè)節(jié)點(diǎn)注冊(cè)的服務(wù)少，在某一個(gè)瞬間可能導(dǎo)致某些 IP 節(jié)點(diǎn)被調(diào)用數(shù)多，某些 IP 節(jié)點(diǎn)調(diào)用數(shù)少的問題。也有可能存在一些本應(yīng)該被刪除而沒被刪除的臟數(shù)據(jù)。
服務(wù)注冊(cè)應(yīng)該選擇 AP 還是?CP
對(duì)于服務(wù)注冊(cè)來說，針對(duì)同一個(gè)服務(wù)，即使注冊(cè)中心的不同節(jié)點(diǎn)保存的服務(wù)注冊(cè)信息不相同，也并不會(huì)造成災(zāi)難性的后果。對(duì)于服務(wù)消費(fèi)者來說，能消費(fèi)才是最重要的，就算拿到的數(shù)據(jù)不是最新的數(shù)據(jù)，消費(fèi)者本身也可以進(jìn)行嘗試失敗重試。總比為了追求數(shù)據(jù)的一致性而獲取不到實(shí)例信息整個(gè)服務(wù)不可用要好。所以，對(duì)于服務(wù)注冊(cè)來說，可用性比數(shù)據(jù)一致性更加的重要，選擇 AP。分布式鎖，是選擇 CA 還是選擇 CP？
這里實(shí)現(xiàn)分布式鎖的方式選取了三種：基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖
基于 Redis 實(shí)現(xiàn)分布式鎖
基于 Zookeeper?實(shí)現(xiàn)分布式鎖
基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖
構(gòu)建表結(jié)構(gòu)：
利用表的 UNIQUE KEY idx_lock(method_lock)作為唯一主鍵，當(dāng)進(jìn)行上鎖時(shí)進(jìn)行 Insert 動(dòng)作，數(shù)據(jù)庫成功錄入則以為上鎖成功，當(dāng)數(shù)據(jù)庫報(bào)出 Duplicate entry 則表示無法獲取該鎖。
不過這種方式對(duì)于單主卻無法自動(dòng)切換主從的 MySQL 來說，基本就無法實(shí)現(xiàn)?P?分區(qū)容錯(cuò)性(MySQL?自動(dòng)主從切換在目前并沒有十分完美的解決方案)。可以說這種方式強(qiáng)依賴于數(shù)據(jù)庫的可用性，數(shù)據(jù)庫寫操作是一個(gè)單點(diǎn)，一旦數(shù)據(jù)庫掛掉，就導(dǎo)致鎖的不可用。這種方式基本不在 CAP 的一個(gè)討論范圍。基于 Redis 實(shí)現(xiàn)分布式鎖
Redis 單線程串行處理天然就是解決串行化問題，用來解決分布式鎖是再適合不過。實(shí)現(xiàn)方式：
setnx?key?value?Expire_time獲取到鎖?返回?1?，?獲取失敗?返回?0
為了解決數(shù)據(jù)庫鎖的無主從切換的問題，可以選擇 Redis 集群，或者是 Sentinel 哨兵模式，實(shí)現(xiàn)主從故障轉(zhuǎn)移，當(dāng) Master 節(jié)點(diǎn)出現(xiàn)故障，哨兵會(huì)從 Slave 中選取節(jié)點(diǎn)，重新變成新的 Master 節(jié)點(diǎn)。
哨兵模式故障轉(zhuǎn)移是由 Sentinel 集群進(jìn)行監(jiān)控判斷，當(dāng) Maser 出現(xiàn)異常即復(fù)制中止，重新推選新 Slave 成為 Master，Sentinel 在重新進(jìn)行選舉并不在意主從數(shù)據(jù)是否復(fù)制完畢具備一致性。所以 Redis 的復(fù)制模式是屬于 AP 的模式。保證可用性，在主從復(fù)制中“主”有數(shù)據(jù)，但是可能“從”還沒有數(shù)據(jù)。這個(gè)時(shí)候，一旦主掛掉或者網(wǎng)絡(luò)抖動(dòng)等各種原因，可能會(huì)切換到“從”節(jié)點(diǎn)，這個(gè)時(shí)候可能會(huì)導(dǎo)致兩個(gè)業(yè)務(wù)線程同時(shí)獲取得兩把鎖。
這個(gè)過程如下：業(yè)務(wù)線程?-1 向主節(jié)點(diǎn)請(qǐng)求鎖
業(yè)務(wù)線程?-1 獲取鎖
業(yè)務(wù)線程 -1 獲取到鎖并開始執(zhí)行業(yè)務(wù)
這個(gè)時(shí)候 Redis 剛生成的鎖在主從之間還未進(jìn)行同步
Redis?這時(shí)候主節(jié)點(diǎn)掛掉了
Redis?的從節(jié)點(diǎn)升級(jí)為主節(jié)點(diǎn)
業(yè)務(wù)線程?-2 想新的主節(jié)點(diǎn)請(qǐng)求鎖
業(yè)務(wù)線程 -2 獲取到新的主節(jié)點(diǎn)返回的鎖
業(yè)務(wù)線程?-2 獲取到鎖開始執(zhí)行業(yè)務(wù)
這個(gè)時(shí)候業(yè)務(wù)線程 -1 和業(yè)務(wù)線程 -2 同時(shí)在執(zhí)行任務(wù)
基于 Zookeeper 實(shí)現(xiàn)分布式鎖
剛剛也分析過，Redis 其實(shí)無法確保數(shù)據(jù)的一致性，先來看 Zookeeper 是否適合作為我們需要的分布式鎖。首先 ZK 的模式是 CP 模型，也就是說，當(dāng) ZK 鎖提供給我們進(jìn)行訪問的時(shí)候，在 ZK 集群中能確保這把鎖在 ZK 的每一個(gè)節(jié)點(diǎn)都存在。
這個(gè)實(shí)際上是 ZK 的 Leader 通過二階段提交寫請(qǐng)求來保證的，這個(gè)也是 ZK 的集群規(guī)模大了的一個(gè)瓶頸點(diǎn)。①ZK 鎖實(shí)現(xiàn)的原理
說 ZK 的鎖問題之前先看看 Zookeeper 中幾個(gè)特性，這幾個(gè)特性構(gòu)建了 ZK 的一把分布式鎖。ZK 的特性如下：有序節(jié)點(diǎn)：當(dāng)在一個(gè)父目錄下如 /lock 下創(chuàng)建 有序節(jié)點(diǎn)，節(jié)點(diǎn)會(huì)按照嚴(yán)格的先后順序創(chuàng)建出自節(jié)點(diǎn) lock000001，lock000002，lock0000003，以此類推，有序節(jié)點(diǎn)能嚴(yán)格保證各個(gè)自節(jié)點(diǎn)按照排序命名生成。
臨時(shí)節(jié)點(diǎn)：客戶端建立了一個(gè)臨時(shí)節(jié)點(diǎn)，在客戶端的會(huì)話結(jié)束或會(huì)話超時(shí)，Zookepper 會(huì)自動(dòng)刪除該節(jié)點(diǎn) ID。
事件監(jiān)聽：在讀取數(shù)據(jù)時(shí)，我們可以對(duì)節(jié)點(diǎn)設(shè)置監(jiān)聽，當(dāng)節(jié)點(diǎn)的數(shù)據(jù)發(fā)生變化(1 節(jié)點(diǎn)創(chuàng)建 2 節(jié)點(diǎn)刪除 3 節(jié)點(diǎn)數(shù)據(jù)變成 4 自節(jié)點(diǎn)變成)時(shí)，Zookeeper 會(huì)通知客戶端。
業(yè)務(wù)線程?-1，業(yè)務(wù)線程?-2 分別向 ZK 的 /lock 目錄下，申請(qǐng)創(chuàng)建有序的臨時(shí)節(jié)點(diǎn)。
業(yè)務(wù)線程?-1 搶到?/lock0001 的文件，也就是在整個(gè)目錄下最小序的節(jié)點(diǎn)，也就是線程 -1 獲取到了鎖。
業(yè)務(wù)線程?-2 只能搶到?/lock0002 的文件，并不是最小序的節(jié)點(diǎn)，線程 2 未能獲取鎖。
業(yè)務(wù)線程?-1 與 lock0001 建立了連接，并維持了心跳，維持的心跳也就是這把鎖的租期。
當(dāng)業(yè)務(wù)線程?-1 完成了業(yè)務(wù)，將釋放掉與 ZK 的連接，也就是釋放了這把鎖。
②ZK 分布式鎖的代碼實(shí)現(xiàn)
ZK 官方提供的客戶端并不支持分布式鎖的直接實(shí)現(xiàn)，我們需要自己寫代碼去利用 ZK 的這幾個(gè)特性去進(jìn)行實(shí)現(xiàn)。
究竟該用 CP?還是 AP 的分布式鎖
首先得了解清楚我們使用分布式鎖的場(chǎng)景，為何使用分布式鎖，用它來幫我們解決什么問題，先聊場(chǎng)景后聊分布式鎖的技術(shù)選型。無論是 Redis，ZK，例如 Redis 的 AP 模型會(huì)限制很多使用場(chǎng)景，但它卻擁有了幾者中最高的性能。Zookeeper 的分布式鎖要比 Redis 可靠很多，但他繁瑣的實(shí)現(xiàn)機(jī)制導(dǎo)致了它的性能不如 Redis，而且 ZK 會(huì)隨著集群的擴(kuò)大而性能更加下降。簡(jiǎn)單來說，先了解業(yè)務(wù)場(chǎng)景，后進(jìn)行技術(shù)選型。分布式事務(wù)，是怎么從 ACID?解脫，投身?CAP/BASE
如果說到事務(wù)，ACID 是傳統(tǒng)數(shù)據(jù)庫常用的設(shè)計(jì)理念，追求強(qiáng)一致性模型，關(guān)系數(shù)據(jù)庫的 ACID 模型擁有高一致性+可用性，所以很難進(jìn)行分區(qū)。在微服務(wù)中 ACID 已經(jīng)是無法支持，我們還是回到 CAP 去尋求解決方案，不過根據(jù)上面的討論，CAP 定理中，要么只能 CP，要么只能 AP。如果我們追求數(shù)據(jù)的一致性而忽略可用性這個(gè)在微服務(wù)中肯定是行不通的，如果我們追求可用性而忽略一致性，那么在一些重要的數(shù)據(jù)(例如支付，金額)肯定出現(xiàn)漏洞百出，這個(gè)也是無法接受。所以我們既要一致性，也要可用性。
都要是無法實(shí)現(xiàn)的，但我們能不能在一致性上作出一些妥協(xié)，不追求強(qiáng)一致性，轉(zhuǎn)而追求最終一致性，所以引入 BASE 理論。在分布式事務(wù)中，BASE 最重要是為 CAP 提出了最終一致性的解決方案，BASE 強(qiáng)調(diào)犧牲高一致性，從而獲取可用性，數(shù)據(jù)允許在一段時(shí)間內(nèi)不一致，只要保證最終一致性就可以了。實(shí)現(xiàn)最終一致性
弱一致性：系統(tǒng)不能保證后續(xù)訪問返回更新的值。需要在一些條件滿足之后，更新的值才能返回。從更新操作開始，到系統(tǒng)保證任何觀察者總是看到更新的值的這期間被稱為不一致窗口。最終一致性：這是弱一致性的特殊形式；存儲(chǔ)系統(tǒng)保證如果沒有對(duì)某個(gè)對(duì)象的新更新操作，最終所有的訪問將返回這個(gè)對(duì)象的最后更新的值。BASE 模型
BASE 模型是傳統(tǒng) ACID 模型的反面，不同于 ACID，BASE 強(qiáng)調(diào)犧牲高一致性，從而獲得可用性，數(shù)據(jù)允許在一段時(shí)間內(nèi)的不一致，只要保證最終一致就可以了。BASE 模型反 ACID 模型，完全不同 ACID 模型，犧牲高一致性，獲得可用性或可靠性：Basically Available 基本可用。支持分區(qū)失敗(e.g. sharding碎片劃分?jǐn)?shù)據(jù)庫)Soft state 軟狀態(tài)，狀態(tài)可以有一段時(shí)間不同步，異步。Eventually consistent 最終一致，最終數(shù)據(jù)是一致的就可以了，而不是時(shí)時(shí)一致。分布式事務(wù)
在分布式系統(tǒng)中，要實(shí)現(xiàn)分布式事務(wù)，無外乎幾種解決方案。方案各有不同，不過其實(shí)都是遵循 BASE 理論，是最終一致性模型：兩階段提交(2PC)
補(bǔ)償事務(wù)(TCC)
本地消息表
MQ?事務(wù)消息
①兩階段提交(2PC)
還有一個(gè)數(shù)據(jù)庫的 XA 事務(wù)，不過目前在真正的互聯(lián)網(wǎng)中實(shí)際的應(yīng)用基本很少，兩階段提交就是使用 XA 原理。在 XA 協(xié)議中分為兩階段：事務(wù)管理器要求每個(gè)涉及到事務(wù)的數(shù)據(jù)庫預(yù)提交(Precommit)此操作，并反映是否可以提交。
事務(wù)協(xié)調(diào)器要求每個(gè)數(shù)據(jù)庫提交數(shù)據(jù)，或者回滾數(shù)據(jù)。
②補(bǔ)償事務(wù)(TCC)
TCC 是服務(wù)化的兩階段編程模型，每個(gè)業(yè)務(wù)服務(wù)都必須實(shí)現(xiàn) Try，Confirm，Cancel?三個(gè)方法，這三個(gè)方式可以對(duì)應(yīng)到 SQL 事務(wù)中 Lock，Commit，Rollback。
相比兩階段提交，TCC 解決了幾個(gè)問題：同步阻塞，引入了超時(shí)機(jī)制，超時(shí)后進(jìn)行補(bǔ)償，并不會(huì)像兩階段提交鎖定了整個(gè)資源，將資源轉(zhuǎn)換為業(yè)務(wù)邏輯形式，粒度變小。因?yàn)橛辛搜a(bǔ)償機(jī)制，可以由業(yè)務(wù)活動(dòng)管理器進(jìn)行控制，保證數(shù)據(jù)一致性。Try 階段：Try 只是一個(gè)初步的操作，進(jìn)行初步的確認(rèn)，它的主要職責(zé)是完成所有業(yè)務(wù)的檢查，預(yù)留業(yè)務(wù)資源。Confirm 階段：Confirm 是在 Try 階段檢查執(zhí)行完畢后，繼續(xù)執(zhí)行的確認(rèn)操作，必須滿足冪等性操作，如果 Confirm 中執(zhí)行失敗，會(huì)有事務(wù)協(xié)調(diào)器觸發(fā)不斷的執(zhí)行，直到滿足為止。Cancel 是取消執(zhí)行：在 Try 沒通過并釋放掉 Try 階段預(yù)留的資源，也必須滿足冪等性，跟 Confirm 一樣有可能被不斷執(zhí)行。一個(gè)下訂單，生成訂單扣庫存的例子：
接下來看看，我們的下單扣減庫存的流程怎么加入 TCC：
在 Try 的時(shí)候，會(huì)讓庫存服務(wù)預(yù)留 N 個(gè)庫存給這個(gè)訂單使用，讓訂單服務(wù)產(chǎn)生一個(gè)“未確認(rèn)”訂單，同時(shí)產(chǎn)生這兩個(gè)預(yù)留的資源。在 Confirm 的時(shí)候，會(huì)使用在 Try 預(yù)留的資源，在 TCC 事務(wù)機(jī)制中認(rèn)為，如果在 Try 階段能正常預(yù)留的資源，那么在 Confirm 一定能完整的提交。
在 Try 的時(shí)候，有任務(wù)一方為執(zhí)行失敗，則會(huì)執(zhí)行 Cancel 的接口操作，將在 Try 階段預(yù)留的資源進(jìn)行釋放。這個(gè)并不是重點(diǎn)要論 TCC 事務(wù)是怎么實(shí)現(xiàn)，重點(diǎn)還是討論分布式事務(wù)在 CAP+BASE 理論的應(yīng)用。實(shí)現(xiàn)可以參考：
https://github.com/changmingxie/tcc-transaction③本地消息表
本地消息表這個(gè)方案最初是 eBay 提出的，eBay 的完整方案：
https://queue.acm.org/detail.cfm?id=1394128本地消息表這種實(shí)現(xiàn)方式應(yīng)該是業(yè)界使用最多的，其核心思想是將分布式事務(wù)拆分成本地事務(wù)進(jìn)行處理。
對(duì)于本地消息隊(duì)列來說，核心就是將大事務(wù)轉(zhuǎn)變?yōu)樾∈聞?wù)，還是用上面下訂單扣庫存的例子說明：當(dāng)我們?nèi)?chuàng)建訂單的時(shí)候，我們新增一個(gè)本地消息表，把創(chuàng)建訂單和扣減庫存寫入到本地消息表，放在同一個(gè)事務(wù)(依靠數(shù)據(jù)庫本地事務(wù)保證一致性)。
配置一個(gè)定時(shí)任務(wù)去輪詢這個(gè)本地事務(wù)表，掃描這個(gè)本地事務(wù)表，把沒有發(fā)送出去的消息，發(fā)送給庫存服務(wù)，當(dāng)庫存服務(wù)收到消息后，會(huì)進(jìn)行減庫存，并寫入服務(wù)器的事務(wù)表，更新事務(wù)表的狀態(tài)。
庫存服務(wù)器通過定時(shí)任務(wù)或直接通知訂單服務(wù)，訂單服務(wù)在本地消息表更新狀態(tài)。
④MQ 事務(wù)
RocketMQ 在 4.3 版本已經(jīng)正式宣布支持分布式事務(wù)，在選擇 RokcetMQ 做分布式事務(wù)請(qǐng)務(wù)必選擇 4.3 以上的版本。RocketMQ 中實(shí)現(xiàn)了分布式事務(wù)，實(shí)際上是對(duì)本地消息表的一個(gè)封裝，將本地消息表移動(dòng)到了 MQ 內(nèi)部。
事務(wù)消息作為一種異步確保型事務(wù)， 將兩個(gè)事務(wù)分支通過 MQ 進(jìn)行異步解耦，RocketMQ 事務(wù)消息的設(shè)計(jì)流程同樣借鑒了兩階段提交理論。整體交互流程如下圖所示：
MQ 事務(wù)是對(duì)本地消息表的一層封裝，將本地消息表移動(dòng)到了 MQ 內(nèi)部，所以也是基于 BASE 理論，是最終一致性模式，對(duì)強(qiáng)一致性要求不那么高的事務(wù)適用，同時(shí) MQ 事務(wù)將整個(gè)流程異步化了，也非常適合在高并發(fā)情況下使用。RocketMQ?選擇同步/異步刷盤，同步/異步復(fù)制，背后的?CP?和 AP?思考
雖然同步刷盤/異步刷盤，同步/異步復(fù)制，并沒有對(duì) CAP 直接的應(yīng)用，但在配置的過程中也一樣涉及到可用性和一致性的考慮。同步刷盤/異步刷盤
RocketMQ 的消息是可以做到持久化的，數(shù)據(jù)會(huì)持久化到磁盤，RocketMQ 為了提高性能，盡可能保證磁盤的順序?qū)懭搿Ｏ⒃?Producer 寫入 RocketMQ 的時(shí)候，有兩種寫入磁盤方式：異步刷盤：消息快速寫入到內(nèi)存的 Pagecache，就立馬返回寫成功狀態(tài)，當(dāng)內(nèi)存的消息累計(jì)到一定程度的時(shí)候，會(huì)觸發(fā)統(tǒng)一的寫磁盤操作。這種方式可以保證大吞吐量，但也存在著消息可能未存入磁盤丟失的風(fēng)險(xiǎn)。
同步刷盤：消息快速寫入內(nèi)存的 Pagecahe，立刻通知刷盤線程進(jìn)行刷盤，等待刷盤完成之后，喚醒等待的線程，返回消息寫成功的狀態(tài)。
同步復(fù)制/異步復(fù)制
一個(gè) Broker 組有?Master?和 Slave，消息需要從?Master 復(fù)制到 Slave?上，所以有同步和異步兩種復(fù)制方式：同步復(fù)制：是等 Master 和 Slave 均寫成功后才反饋給客戶端寫成功狀態(tài)。
異步復(fù)制：是只要 Master 寫成功即可反饋給客戶端寫成功狀態(tài)。
值得一提的是 Lazy+Primary/Copy 的復(fù)制協(xié)議在實(shí)際生產(chǎn)環(huán)境中是非常實(shí)用的。
RocketMQ 的設(shè)置要結(jié)合業(yè)務(wù)場(chǎng)景，合理設(shè)置刷盤方式和主從復(fù)制方式，尤其是 SYNC_FLUSH 方式，由于頻繁的觸發(fā)寫磁盤動(dòng)作，會(huì)明顯降低性能。通常情況下，應(yīng)該把 Master 和 Slave 設(shè)置成 ASYNC_FLUSH 的刷盤方式，主從之間配置成 SYNC_MASTER 的復(fù)制方式，這樣即使有一臺(tái)機(jī)器出故障，仍然可以保證數(shù)據(jù)不丟。總結(jié)
在微服務(wù)的構(gòu)建中，永遠(yuǎn)都逃離不了 CAP 理論，因?yàn)榫W(wǎng)絡(luò)永遠(yuǎn)不穩(wěn)定，硬件總會(huì)老化，軟件可能出現(xiàn) Bug，所以分區(qū)容錯(cuò)性在微服務(wù)中是躲不過的命題。可以這么說，只要是分布式，只要是集群都面臨著 AP 或者 CP 的選擇，但你很貪心的時(shí)候，既要一致性又要可用性，那只能對(duì)一致性作出一點(diǎn)妥協(xié)，也就是引入了 BASE 理論，在業(yè)務(wù)允許的情況下實(shí)現(xiàn)最終一致性。
究竟是選 AP 還是選 CP，真的在于對(duì)業(yè)務(wù)的了解，例如金錢，庫存相關(guān)會(huì)優(yōu)先考慮 CP 模型，例如社區(qū)發(fā)帖相關(guān)可以優(yōu)先選擇 AP 模型，這個(gè)說白了基于對(duì)業(yè)務(wù)的了解是一個(gè)選擇和妥協(xié)的過程。作者：陳于喆
簡(jiǎn)介：十余年的開發(fā)和架構(gòu)經(jīng)驗(yàn)，國(guó)內(nèi)較早一批微服務(wù)開發(fā)實(shí)施者。曾任職國(guó)內(nèi)互聯(lián)網(wǎng)公司網(wǎng)易和唯品會(huì)高級(jí)研發(fā)工程師，后在創(chuàng)業(yè)公司擔(dān)任技術(shù)總監(jiān)/架構(gòu)師，目前在洋蔥集團(tuán)任職技術(shù)研發(fā)副總監(jiān)。
編輯：陶家龍、孫淑娟
征稿：有投稿、尋求報(bào)道意向技術(shù)人請(qǐng)聯(lián)絡(luò) editor@51cto.com
精彩文章推薦：
我只是下了個(gè)訂單，鬼知道我在微服務(wù)里經(jīng)歷了什么？沒看這篇干貨，別說你會(huì)使用“緩存”想實(shí)現(xiàn)高可用？先搞定負(fù)載均衡原理總結(jié)
以上是生活随笔為你收集整理的base cap 分布式_神一样的CAP理论被应用在何方？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 远达环保是碳中和龙头吗 带你了解这家公
- 下一篇： 自动挂载ios_开机自动挂载iso