如果這是第二次看到我的文章，歡迎訂閱z哥的公眾號（跨界架構師）哦~
每周五11：45 按時送達维咸。當然了剂买，也會時不時加個餐～
這次準備開啟一個新的系列來寫了惠爽，聊聊分布式系統(tǒng)中的關注點。節(jié)奏不會排的太緊湊瞬哼，計劃兩周一更吧婚肆。
????????本文是本系列的第三篇。與前兩篇《不知道是不是最通俗易懂的《數(shù)據(jù)一致性》剖析了》坐慰、《煩人的數(shù)據(jù)不一致到底怎么解決较性？——通過“共識”達成數(shù)據(jù)一致性》形成完整的「數(shù)據(jù)一致性」合集。
一结胀、為什么需要事務
? ? ? ? 如果說「共識」解決的是「水平」問題赞咙，那么「事務」解決的是「垂直」問題。是如何讓一條繩上的螞蚱共同起舞糟港？
? ? ? ? 事務只是一個計算機術語攀操，而事務的體現(xiàn)形式其實在我們生活中也無處不在。任何我們認為應該是這樣的事情秸抚，去確保它達到預期的過程就是「事務」速和。 往小了說，我們平時在走路的時候剥汤，向前擺動左手的同時抬右腿颠放，如果不是這樣的話就是不一致，別人會說你走路不協(xié)調(diào)吭敢。所以我們小時候父母會通過各種方式教會我們這個碰凶，這些各式各樣的方式就好比我們在軟件開發(fā)中去實施「事務」一樣，一題是多解的鹿驼。
二欲低、事務的來源
? ? ? ? 提到事務不得不提到「XA規(guī)范」[1]，這是分布式還沒大行其道的時期蠢沿，被大多數(shù)的數(shù)據(jù)庫作為其內(nèi)部分布式事務實現(xiàn)的接口標準伸头。
? ? ? ? 「XA規(guī)范」就是上圖中「RM」和「TM」的交互規(guī)范和接口定義舷蟀。僅僅是定義了xa_和ax_系列的函數(shù)原型以及功能描述恤磷、約束和實施規(guī)范等，并不包括建議的實現(xiàn)方式野宜。后面會提到的兩階段提交（2PC）是「TM」協(xié)調(diào)「RM」們完成事務的方法扫步。
? ? ? ? 所以其實可以說，事務起源于數(shù)據(jù)庫匈子，輝煌于分布式系統(tǒng)河胎。在摩爾定律還適用的時候，軟件系統(tǒng)為了承載更大的流量或者說用戶數(shù)虎敦，開始運用「分治」的思想來設計游岳。然后隨著互聯(lián)網(wǎng)的蓬勃發(fā)展政敢，B/S應用大行其道的背景下，分布式系統(tǒng)越來越常見胚迫。并且隨著一個個巨無霸互聯(lián)網(wǎng)公司的出現(xiàn)喷户，越來越被鼓吹和傳頌。
一輪明月的背后是一個陰暗面访锻，從來不讓人看見褪尝。
? ? ? ? 能被吹捧的永遠是有益的一面，再加上耀眼的數(shù)據(jù)：多少TPS期犬、多少Q(mào)PS河哑，更抓人眼球。但是這背后為了讓「分治」后的系統(tǒng)能夠盡可能的像單個個體一樣運作龟虎，各類專家學者們通過多年研究璃谨，才有了如今的各種著名理論和解決方案。
三遣总、分布式系統(tǒng)中的事務問題
? ? ? ? 正如前面所說睬罗，事務問題其實一直存在轨功，只是在分布式系統(tǒng)中被放大了旭斥。并且隨著系統(tǒng)拆分的粒度越細，問題的復雜度成指數(shù)上升古涧。
? ? ? ? 分布式系統(tǒng)的事務垂券，不得不提到被廣為流傳的兩個理論：「CAP」、「BASE」羡滑。
? ? ? ? 「CAP」理論由Eric Brewer在2000年PODC會議上提出[2]菇爪，所以還被稱為Brewer定理。是Eric Brewer在Inktomi期間研發(fā)搜索引擎柒昏、分布式web緩存時得出的一個猜想：
It is impossible for a web service to provide the three following guarantees : Consistency, Availability and Partition-tolerance.
? ? ? ? 后來Seth Gilbert和Nancy Lynch對其進行了證明[3]凳宙，成為我們熟知的「CAP」定理（感謝園友@bangerlee的信息收集）。
? ? ? ? 對职祷，就是下面這張經(jīng)典的圖氏涩。
■ 一致性(consistency)：這里的一致性指是「線性一致性」有梆。（關于線性一致性的解釋是尖，點我可閱讀）
■?可用性(availability)：每個請求都在一定時限內(nèi)得到響應。
■?分區(qū)容忍性(partition-tolerance)：這應該是這三點中最晦澀的泥耀。允許丟失以一個節(jié)點發(fā)給另一個節(jié)點的任意多的消息饺汹。只要是分布式系統(tǒng)，這項是無法逃避的痰催，因為網(wǎng)絡兜辞、硬件說不準啥時候就出問題了迎瞧。
? ? ? ? 舉個不是特別嚴謹?shù)睦樱@就好比要實現(xiàn)一個系統(tǒng)不能產(chǎn)生BUG（C）逸吵，并且10天內(nèi)完成上線（A）夹攒，以及需要多人團隊一起協(xié)作進行（P）。我們做開發(fā)的也很清楚這三者是無法兼得的胁塞。況且只要是一個組織咏尝，團隊協(xié)作是無法避免的，正如這里的分區(qū)容忍性一樣啸罢，比如得考慮人員請假的問題编检。剩下的2項，如果說可以達到?jīng)]有BUG的話扰才，那就是時間無限延長允懂，但也只是無限趨近于0，并不能達到真正的0衩匣，因為沒有人可以保證發(fā)現(xiàn)了所有的BUG蕾总。
? ? ? ? 「BASE」理論是由時任ebay架構師的Dan Pritchett提出的[4]，本質(zhì)上就是對「線性一致性」的弱化琅捏。弱化的方式正如本集合的第一篇文章中所提到的「順序一致性」和「最終一致性」生百。（關于這兩種一致性的解釋，點我可閱讀）
? ? ? ? 「BASE」理論解釋如下：
基本可用(Basically Available)柄延。分布式系統(tǒng)在出現(xiàn)故障時蚀浆，允許損失部分可用功能，保證核心功能可用搜吧。
軟狀態(tài)(Soft State)市俊。狀態(tài)可以有一段時間不同步，且這個狀態(tài)不影響系統(tǒng)可用性滤奈。
最終一致(Eventually Consistent)摆昧。確保最終數(shù)據(jù)能夠一致，而不是時時保持強一致蜒程。
? ? ? ? 「BASE」理論的提出并不是取代「CAP」理論绅你，讓我們在實際的工作中就可以完全的撇開「線性一致性」。并不是這樣搞糕，而是引導我們可以區(qū)分核心和非核心勇吊，然后分別對待，核心部分還是需要用CAP理論來保證「線性一致性」窍仰。為什么要區(qū)別對待汉规？根本上還是無法容忍「線性一致性」帶來的巨大的性能損耗，因為它是反可伸縮性的。但是只要涉及到Money之類的高敏感數(shù)據(jù)的操作部分针史，還是必須保證「線性一致性」晶伦。
? ? ? ? 還是上面的例子，我們側重于降低核心功能的BUG啄枕，不花過多精力在非核心功能上（BA）婚陪。我們允許產(chǎn)生不影響核心功能的BUG（S），但是必須最終要修復（E）频祝。
四泌参、分布式事務的解決方案
? ? ? ? 如果說「CAP」理論和「BASE」理論是「道」，那么圍繞這兩個理論演化的解決方案就是「術」常空。對我們來說沽一，在實際的運用中根據(jù)所處的場景找到最合適的，是我們最重要的事漓糙。
? ? ? ? 以「CAP」為基礎的強一致性解決方案都會引入一個類似“協(xié)調(diào)器”的東西來作為全局事務的掌控者铣缠，可以來看一下。
01? 兩階段提交（2PC）[5]
? ? ? ? 印象中左耳朵耗子（陳皓）之前拿西方結婚時的儀式做過一個形象的比喻蝗蛙。大致好像是牧師分別詢問男女雙方“你愿意嗎？”相當于這里的「請求提交」醉鳖，得到的“yes”相當于「是」這個答復捡硅。然后再要求給對方帶上戒指，這個要求就相當于這里的「提交」辐棒，帶完戒指之后的反饋就是「ACK」病曾。
? ? ? ? 另外值得注意的是，參與者在答復「是」之前會將自己的內(nèi)部資源變?yōu)樽枞麪顟B(tài)漾根。因此如果在產(chǎn)生阻塞后協(xié)調(diào)者出問題，那么這些被阻塞的資源有可能就一直不被釋放了鲫竞，需要額外的介入辐怕。
? ? ? ? 2PC相對來說是最簡單的事務模型，但缺點也更多从绘。其它缺點諸如：在某些場景下的數(shù)據(jù)不一致（參與者與協(xié)調(diào)者共同與「提交」環(huán)節(jié)掛了）寄疏、阻塞范圍過大等問題。
02? 三階段提交（3PC）[6]
? ? ? ? 3PC的出現(xiàn)就是通過增加復雜度（性能也因此降低）來解決或優(yōu)化2PC中的一部分問題陕截。本質(zhì)的變化就是在2PC的「請求提交」之后增加了一個「準備提交」環(huán)節(jié)，以增加每個參與者需要等待其它的參與者確認后方可進行具體的操作批什。
■?「阻塞」這個動作延后到這個「準備提交」環(huán)節(jié)再做农曲，使得阻塞范圍縮小為2PC的2/3（圖中背景黃色和綠色部分）。正如上面的例子，在交換戒指之前增加了把戒指交給牧師的動作乳规。
■?同時還解決了協(xié)調(diào)者的單點問題形葬。故障恢復或者新接替的協(xié)調(diào)者，可以利用「準備提交」產(chǎn)生的狀態(tài)結果暮的，來作為參與者和協(xié)調(diào)者在「提交」出現(xiàn)故障恢復后的界定依據(jù)笙以。還是前面的例子，夸張點冻辩，交換戒指的時候我失憶了猖腕，意識恢復后我只要看到牧師手掌上托著戒指或者我的手上已經(jīng)被戴好了戒指，就知道我的妻子已經(jīng)答應了恨闪，我只要繼續(xù)給她做帶戒指這個事就好了谈息。
■?新引入了timeout機制，在發(fā)生超時執(zhí)行默認約定凛剥，避免了永久阻塞侠仇，也因此對多個參與者下的100%數(shù)據(jù)一致性作出了妥協(xié)。比如犁珠，協(xié)調(diào)者在向參與者A發(fā)送「doCommit」時timeout了逻炊，會引發(fā)廣播「abort」，但是這個「abort」又未能投遞到參與者B犁享，導致參與者B執(zhí)行了「ACK」后的timeout默認約定「commit」余素。
03? TCC
? ? ? ? 在國內(nèi)，由于阿里的光環(huán)加持下TCC好像更火炊昆，風頭蓋過了2PC和3PC桨吊。其本質(zhì)上是另辟蹊徑達到了和3PC類似的效果。
■?通過運用本地事務代替了全局事務视乐，使得可以不需要協(xié)調(diào)者的存在，避免了協(xié)調(diào)者的單點問題敢茁。
■?3PC中協(xié)調(diào)者的另一個作用：故障恢復后的數(shù)據(jù)一致性佑淀。在TTC里通過事務日志來確保。
? ? ? 這個概念最初是由Pat Helland于2007年提出的[7]彰檬，那時還叫「Tentative-Confirmation-Cancellation」伸刃，在2008年的軟件開發(fā)2.0技術大會上支付寶CTO（程立）將其在國內(nèi)推廣開來。
? ? ? ? 以上這三種就是主流的DTS（Distributed Transaction Service）框架逢倍。值得一提的是捧颅，不管是3PC還是TCC，只要涉及到故障恢復或者重試機制较雕，那么「冪等性」問題必須要提上來了碉哑。比如3PC中「提交」階段某個參與者和協(xié)調(diào)者同時掛了，但是這個參與者在掛之前已經(jīng)做了commit操作。那么故障恢復后其實沒人知道它是否執(zhí)行過了commit谭梗，協(xié)調(diào)者只會為了能100%確保commit指令被送達忘晤，又會發(fā)起一次commit通知，這時候如果沒有做好「冪等性」就會發(fā)生重復commit的問題激捏。
? ? ? ? 下面聊聊以「BASE」理論為基礎的解決方案设塔。
01? 異步消息——本地消息表
? ? ? ? 這種實現(xiàn)方式的思路，源于ebay远舅，與提出BASE理論在同一篇論文中[4]闰蛔。設計思想是將遠程分布式事務拆分成一系列的本地事務，借助關系型數(shù)據(jù)庫中的表即可實現(xiàn)图柏。
02? 異步消息——不支持事務的MQ
? ? ? ? 其實大部分的MQ都是不支持事務的序六，所以我們需要自己想辦法解決可能出現(xiàn)的MQ消息未能成功投遞出去的問題。有個便宜可以撿的是蚤吹，如果需投遞的MQ消息條數(shù)僅有1的話例诀，可以將本地事務的commit放于消息投遞之后即可避免此問題。偽代碼如下：
try{? ? beginTrans();? ?
? ? modifyLocalData1();
? ? modifyLocalData2();? ?
? ? deliverMessageToMQ();? ?
? ? commitTrans();
}catch(Exception ex){? ?
? ? rollbackTrans();
}
03? 異步消息——支持事務的MQ
? ? ? ?據(jù)我所知裁着，目前唯一支持事務的MQ框架是RockerMQ繁涂，并且于近期才開源了事務部分實現(xiàn)，《RocketMQ 4.3正式發(fā)布二驰，支持分布式事務》（http://www.infoq.com/cn/news/2018/08/rocketmq-4.3-release）扔罪。這樣的確能省很多事~哮幢，直接放一張阿里方面給出的圖感受一下實現(xiàn)細節(jié)创肥。
? ? ? ? 不過其實有一個疑點我沒有去驗證控漠，有知道的小伙伴們可以留言下矗积，就是RocketMQ是否有防止consumer（上圖中的訂閱方）在消費完成后發(fā)送的ACK丟失的機制全肮。如果能達到這點，對于consumer內(nèi)部的方法冪等性需求就低了很多漠魏。
04? Saga
? ? ? ? Saga是1987年就提出的概念[8]倔矾，核心是：
■?將一個分布式事務拆分為多個本地事務，并且擊鼓傳花給下一個柱锹，不用阻塞本地事務等待響應。且允許嵌套至多一層子事務丰包。
■?除了最后一個參與者之外禁熏，都需要定義一個「回滾」接口，便于在遇到無法進行下去的情況下撤銷之前上游系統(tǒng)的修改邑彪。當然這里的撤銷除了Update還可以是沖抵類的操作瞧毙。
? ? ? ? Saga原則上是個鏈式的「長活事務」，整個處理耗時可能會很長。所以可以通過增加save point（保存點宙彪，類似于游戲里的存檔）矩动，便于故障恢復和提速，如向前恢復（重試）和向后恢復（回滾）释漆。不過悲没，也可以并行多個子事務，但一般在運用中心節(jié)點的Saga模式中男图，如圖示姿。
? ? ? ? 只是在我們打破了鏈式規(guī)則后必須要額外確保執(zhí)行了「回滾」之后再接收到「正向請求」，等于“請求無效”的效果逊笆。中心節(jié)點模式還有一個比較大的好處是能夠更好的避免事務之間的循環(huán)依賴關系栈戳。
05? Gossip協(xié)議
? ? ? ? 額外提一下，這個其實是一個具體的难裆、運用BASE理論實現(xiàn)的協(xié)議子檀，借由Cassandra的熱火而讓更多人知道了。這協(xié)議一般會用于數(shù)據(jù)復制乃戈、P2P拓撲構造褂痰、故障探測等。
? ? ? ? 看這些案例我們可以發(fā)現(xiàn)偏化，基于「CAP」的解決方案都是在線的脐恩，而「Base」是允許離線的。好比前者是侦讨，累倒了必須得馬上爬起來繼續(xù)干貨驶冒，要不然就是失敗。而后者是韵卤，慢慢來骗污，只要最終能干完。
? ? ? ? 不管怎樣沈条，如果每個解決方案中增加「重試」和「回滾」會大大提升程序的自我修正能力需忿，以降低需要人為介入的比例。識別是否需要人為介入的方式就是類似于「對賬」的機制蜡歹，這個機制就是兜底的屋厘。最后還需要做一道選擇題來防止混亂：確保參與者的接口符合「冪等性」，或者在中間件里做到「正好一次(Exactly-once)」月而。
? ? ? ? 這些基于「BASE」的解決方案都是可以作為「CAP」解決方案出現(xiàn)問題時的PlanB來用的汗洒，起到補充作用。當然父款，如非必要溢谤，可以優(yōu)先考慮基于「BASE」的方案瞻凤，畢竟這才是天然易伸縮的，自然也能帶來更好的性能世杀。
五阀参、結語
? ? ? ? 解決方案如此多，所以不管我們是架構師瞻坝、還是在成為架構師的路上蛛壳，甚至在日常生活中，都需要養(yǎng)成Balance的習慣湿镀，找到那個最適合的方案炕吸。
? ? ? ? 最后還有一招終極大法 —— 減少冗余。
是亦彼也勉痴，彼亦是也赫模，彼亦一是非，此亦一是非蒸矛。
? ? ? ? ——莊子
? ? ? ? 「事物都具有兩面性」瀑罗，所以，在選擇走向分布式之前雏掠，慎重考慮下是否有必要斩祭，以免給自己徒增麻煩。
? ? ? ? 論文可后臺直接回復關鍵字“一致性”乡话，打包下載摧玫。下篇將開啟「高可用」主題，敬請期待~
? 公眾號后臺回復“一致性”關鍵字绑青，可打包下載喲~
[1] Distributed TP: The XA Specification , X/Open Company Ltd. , 1991
鏈接：https://publications.opengroup.org/c193
[2] Harvest, Yield, and Scalable Tolerant Systems, Armando Fox , Eric Brewer, 1999
鏈接：https://cs.uwaterloo.ca/~brecht/servers/readings-new2/harvest-yield.pdf
[3] Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web, Seth Gilbert, Nancy Lynch, 2002
鏈接：https://pdfs.semanticscholar.org/24ce/ce61e2128780072bc58f90b8ba47f624bc27.pdf
[4] Base: An Acid Alternative, Dan Pritchett, 2008
鏈接：http://delivery.acm.org/10.1145/1400000/1394128/p48-pritchett.pdf
[5] Consensus Protocols: Two-Phase Commit, Henry Robinson, 2008
鏈接：http://the-paper-trail.org/blog/consensus-protocols-two-phase-commit/
[6] Consensus Protocols: Three-phase Commit, Henry Robinson, 2008
鏈接：http://the-paper-trail.org/blog/consensus-protocols-three-phase-commit/
[7] Life beyond Distributed Transactions:an Apostate’s Opinion, 2007
鏈接：https://cs.brown.edu/courses/cs227/archives/2012/papers/weaker/cidr07p15.pdf
[8] Sagas, Hector Garcaa-Molrna? & Kenneth Salem, 1987
鏈接：https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf
?作者：Zachary（個人微信號：Zachary-ZF）
微信公眾號（首發(fā)）：跨界架構師诬像。<-- 點擊查閱近期熱門文章
如果你是初級程序員，想提升但不知道如何下手闸婴。又或者做程序員多年坏挠，陷入了一些瓶頸想拓寬一下視野。歡迎關注我的公眾號「跨界架構師」邪乍，回復「技術」降狠，送你一份我長期收集和整理的思維導圖。
如果你是運營庇楞，面對不斷變化的市場束手無策榜配。又或者想了解主流的運營策略，以豐富自己的“倉庫”吕晌。歡迎關注我的公眾號「跨界架構師」芥牌，回復「運營」，送你一份我長期收集和整理的思維導圖聂使。
定期發(fā)表原創(chuàng)內(nèi)容：架構設計丨分布式系統(tǒng)丨產(chǎn)品丨運營丨一些深度思考壁拉。
