[[187682]]

1 背景

一致性是一個抽象的、具有多重含義的計算機術(shù)語，在不同應(yīng)用場景下，有不同的定義和含義。在傳統(tǒng)的IT時代，一致性通常指強一致性，強一致性通常體現(xiàn)在你中有我、我中有你、渾然一體;而在互聯(lián)網(wǎng)時代，一致性的含義遠遠超出了它原有的含義，在我們討論互聯(lián)網(wǎng)時代的一致性之前，我們先了解一下互聯(lián)網(wǎng)時代的特點，互聯(lián)網(wǎng)時代信息量巨大、需要計算能力巨大，不但對用戶響應(yīng)速度要求快，而且吞吐量指標(biāo)也要向外擴展(既：水平伸縮)，于是單節(jié)點的服務(wù)器無法滿足需求，服務(wù)節(jié)點開始池化，想想那個經(jīng)典的故事，一只筷子一折就斷，一把筷子怎么都折不斷，可見人多力量大的思想是多么的重要，但是人多也不一定能解決所有事情，還得進行有序、合理的分配任務(wù)，進行有效的管理，于是互聯(lián)網(wǎng)時代談?wù)撟疃嗟脑掝}就是拆分，拆分一般分為“水平拆分”和“垂直拆分”(大家不要對應(yīng)到數(shù)據(jù)庫或者緩存拆分，這里主要表達一種邏輯)。這里，“水平拆分”指的是同一個功能由于單機節(jié)點無法滿足性能需求，需要擴展成為多節(jié)點，多個節(jié)點具有一致的功能，組成一個服務(wù)池，一個節(jié)點服務(wù)一部分的請求量，團結(jié)起來共同處理大規(guī)模高并發(fā)的請求量。“垂直拆分”指的是按照功能拆分，秉著“專業(yè)的人干專業(yè)的事兒”的原則，把一個復(fù)雜的功能拆分到多個單一的簡單的元功能，不同的元功能組合在一起，和未拆分前完成的功能是一致的，由于每個元功能職責(zé)單一、功能簡單，讓維護和變更都變得更簡單、安全，更易于產(chǎn)品版本的迭代，在這樣的一個互聯(lián)網(wǎng)的時代和環(huán)境，一致性指分布式服務(wù)化系統(tǒng)之間的弱一致性，包括應(yīng)用系統(tǒng)一致性和數(shù)據(jù)一致性。

無論是水平拆分還是垂直拆分，都解決了特定場景下的特定問題，凡事有好的一面，都會有壞的一面，拆分后的系統(tǒng)或者服務(wù)化的系統(tǒng)***的問題就是一致性問題，這么多個具有元功能的模塊，或者同一個功能池中的多個節(jié)點之間，如何保證他們的信息是一致的、工作步伐是一致的、狀態(tài)是一致的、互相協(xié)調(diào)有序的工作呢?

本文根據(jù)作者在互聯(lián)網(wǎng)企業(yè)的實際項目經(jīng)驗，對服務(wù)化系統(tǒng)中最難解決的一致性問題進行研究和探討，試圖從實踐經(jīng)驗中找到規(guī)律，抽象出模式，分享給大家，希望對大家的項目實施有所幫助，在對實踐的總結(jié)中也會對相關(guān)的一致性術(shù)語做最樸實的解釋，希望能幫助大家徹底理解一致性的本質(zhì)，并能將其應(yīng)用到實踐，解決讀者現(xiàn)實中遇到的服務(wù)化系統(tǒng)的一致性問題，本文使用理論與實踐相結(jié)合的方法，突出在實踐中解決問題的模式，因此叫做《分布式服務(wù)化系統(tǒng)一致性的“***實干”》。

2 問題

本節(jié)列舉不一致會導(dǎo)致的種種問題，這也包括一例生活中的問題。

案例1：買房

假如你想要享受生活的隨意，只想買個兩居，不想讓房貸有太大壓力，而你媳婦卻想要買個三居，還得帶花園的，那么你們就不一致了，不一致導(dǎo)致生活不愉快、不協(xié)調(diào)，嚴重情況下還會吵架，可見生活中的不一致問題影響很大。

案例2：轉(zhuǎn)賬

轉(zhuǎn)賬是經(jīng)典的不一致案例，設(shè)想一下銀行為你處理一筆轉(zhuǎn)賬，扣減你賬戶上的余額，然后增加別人賬戶的余額;如果扣減你的賬戶余額成功，增加別人賬戶余額失敗，那么你就會損失這筆資金。反過來，如果扣減你的賬戶余額失敗，增加別人賬戶余額成功，那么銀行就會損失這筆資金，銀行需要賠付。對于資金處理系統(tǒng)來說，上面任何一種場景都是不允許發(fā)生的，一旦發(fā)生就會有資金損失，后果是不堪設(shè)想的，嚴重情況會讓一個公司瞬間倒閉。

案例3：下訂單和扣庫存

電商系統(tǒng)中也有一個經(jīng)典的案例，下訂單和扣庫存如何保持一致，如果先下訂單，扣庫存失敗，那么將會導(dǎo)致超賣;如果下訂單沒有成功，扣庫存成功，那么會導(dǎo)致少賣。兩種情況都會導(dǎo)致運營成本的增加，嚴重情況下需要賠付。

案例4：同步超時

服務(wù)化的系統(tǒng)間調(diào)用常常因為網(wǎng)絡(luò)問題導(dǎo)致系統(tǒng)間調(diào)用超時，即使是網(wǎng)絡(luò)很好的機房，在億次流量的基數(shù)下，同步調(diào)用超時也是家常便飯。系統(tǒng)A同步調(diào)用系統(tǒng)B超時，系統(tǒng)A可以明確得到超時反饋，但是無法確定系統(tǒng)B是否已經(jīng)完成了預(yù)定的功能或者沒有完成預(yù)定的功能。于是，系統(tǒng)A就迷茫了，不知道應(yīng)該繼續(xù)做什么，如何反饋給使用方。(曾經(jīng)的一個B2B產(chǎn)品的客戶要求接口超時重新通知他們，這個在技術(shù)上是難以實現(xiàn)的，因為服務(wù)器本身可能并不知道自己超時，可能會繼續(xù)正常的返回數(shù)據(jù)，只是客戶端并沒有接受到結(jié)果罷了，因此這不是一個合理的解決方案)。

案例5：異步回調(diào)超時

此案例和上一個同步超時案例類似，不過這個場景使用了異步回調(diào)，系統(tǒng)A同步調(diào)用系統(tǒng)B發(fā)起指令，系統(tǒng)B采用受理模式，受理后則返回受理成功，然后系統(tǒng)B異步通知系統(tǒng)A。在這個過程中，如果系統(tǒng)A由于某種原因遲遲沒有收到回調(diào)結(jié)果，那么兩個系統(tǒng)間的狀態(tài)就不一致，互相認知不同會導(dǎo)致系統(tǒng)間發(fā)生錯誤，嚴重情況下會影響核心事務(wù)，甚至?xí)?dǎo)致資金損失。

案例6：掉單

分布式系統(tǒng)中，兩個系統(tǒng)協(xié)作處理一個流程，分別為對方的上下游，如果一個系統(tǒng)中存在一個請求，通常指訂單，另外一個系統(tǒng)不存在，則導(dǎo)致掉單，掉單的后果很嚴重，有時候也會導(dǎo)致資金損失。

案例7：系統(tǒng)間狀態(tài)不一致

這個案例與上面掉單案例類似，不同的是兩個系統(tǒng)間都存在請求，但是請求的狀態(tài)不一致。

案例8：緩存和數(shù)據(jù)庫不一致

交易相關(guān)系統(tǒng)基本離不開關(guān)系型數(shù)據(jù)庫，依賴關(guān)系型數(shù)據(jù)庫提供的ACID特性(后面介紹)，但是在大規(guī)模高并發(fā)的互聯(lián)網(wǎng)系統(tǒng)里，一些特殊的場景對讀的性能要求極高，服務(wù)于交易的數(shù)據(jù)庫難以抗住大規(guī)模的讀流量，通常需要在數(shù)據(jù)庫前墊緩存，那么緩存和數(shù)據(jù)庫之間的數(shù)據(jù)如何保持一致性?是要保持強一致呢還是弱一致性呢?

案例9：本地緩存節(jié)點間不一致

一個服務(wù)池上的多個節(jié)點為了滿足較高的性能需求，需要使用本地緩存，使用了本地緩存，每個節(jié)點都會有一份緩存數(shù)據(jù)的拷貝，如果這些數(shù)據(jù)是靜態(tài)的、不變的，那永遠都不會有問題，但是如果這些數(shù)據(jù)是半靜態(tài)的或者常被更新的，當(dāng)被更新的時候，各個節(jié)點更新是有先后順序的，在更新的瞬間，各個節(jié)點的數(shù)據(jù)是不一致的，如果這些數(shù)據(jù)是為某一個開關(guān)服務(wù)的，想象一下重復(fù)的請求走進了不同的節(jié)點(在failover或者補償導(dǎo)致的場景下，重復(fù)請求是一定會發(fā)生的，也是服務(wù)化系統(tǒng)必須處理的)，一個請求走了開關(guān)打開的邏輯，同時另外一個請求走了開關(guān)關(guān)閉的邏輯，這導(dǎo)致請求被處理兩次，最壞的情況下會導(dǎo)致災(zāi)難性的后果，就是資金損失。

案例10：緩存數(shù)據(jù)結(jié)構(gòu)不一致

這個案例會時有發(fā)生，某系統(tǒng)需要種某一數(shù)據(jù)結(jié)構(gòu)的緩存，這一數(shù)據(jù)結(jié)構(gòu)有多個數(shù)據(jù)元素組成，其中，某個數(shù)據(jù)元素都需要從數(shù)據(jù)庫中或者服務(wù)中獲取，如果一部分數(shù)據(jù)元素獲取失敗，由于程序處理不正確，仍然將不完全的數(shù)據(jù)結(jié)構(gòu)存入緩存，那么緩存的消費者消費的時候很有可能因為沒有合理處理異常情況而出錯。

3 模式

3.1 生活中不一致問題的解決

大家回顧一下上一節(jié)列舉的生活中的案例1-買房，如果置身事外來看，解決這種不一致的辦法有兩個，一個是避免不一致的發(fā)生，如果已經(jīng)是媳婦了就不好辦了:)，還有一種方法就是慢慢的補償，先買個兩居，然后慢慢的等資金充裕了再換三居，買比特幣賺了再換帶花園的房子，于是問題最終被解決了，最終大家處于一致的狀態(tài)，都開心了。這樣可以解決案例1的問題，很自然由于有了過渡的方法，問題在不經(jīng)意間就消失了，可見“過渡”也是解決一致性問題的一個模式。

從案例1的解決方案來看，我們要解決一致性問題，一個最直接最簡單的方法就是保持強一致性，對于案例1的情況，盡量避免在結(jié)婚前兩個人能夠互相了解達成一致，避免不一致問題的發(fā)生;不過有些事情事已至此，發(fā)生了就是發(fā)生了，出現(xiàn)了不一致的問題，我們應(yīng)該考慮去補償，盡***的努力從不一致狀態(tài)修復(fù)到一致狀態(tài)，避免損失全部或者一部分，也不失為一個好方法。

因此，避免不一致是上策，出現(xiàn)了不一致及時發(fā)現(xiàn)及時修復(fù)是中策，有問題不積極解決留給他人解決是下策。

3.2 酸堿平衡理論

ACID在英文中的意思是“酸”，BASE的意識是“堿”，這一段講的是“酸堿平衡”的故事。

1. ACID(酸)

如何保證強一致性呢?計算機專業(yè)的童鞋在學(xué)習(xí)關(guān)系型數(shù)據(jù)庫的時候都學(xué)習(xí)了ACID原理，這里對ACID做個簡單的介紹。如果想全面的學(xué)習(xí)ACID原理，請參考ACID。

關(guān)系型數(shù)據(jù)庫天生就是解決具有復(fù)雜事務(wù)場景的問題，關(guān)系型數(shù)據(jù)庫完全滿足ACID的特性。

ACID指的是：

• A: Atomicity，原子性
• C: Consistency，一致性
• I: Isolation，隔離性
• D: Durability，持久性

具有ACID的特性的數(shù)據(jù)庫支持強一致性，強一致性代表數(shù)據(jù)庫本身不會出現(xiàn)不一致，每個事務(wù)是原子的，或者成功或者失敗，事物間是隔離的，互相完全不影響，而且最終狀態(tài)是持久落盤的，因此，數(shù)據(jù)庫會從一個明確的狀態(tài)到另外一個明確的狀態(tài)，中間的臨時狀態(tài)是不會出現(xiàn)的，如果出現(xiàn)也會及時的自動的修復(fù)，因此是強一致的。

3個典型的關(guān)系型數(shù)據(jù)庫Oracle、Mysql、Db2都能保證強一致性，Oracle和Mysql使用多版本控制協(xié)議實現(xiàn)，而DB2使用改進的兩階段提交協(xié)議來實現(xiàn)。

如果你在為交易相關(guān)系統(tǒng)做技術(shù)選型，交易的存儲應(yīng)該只考慮關(guān)系型數(shù)據(jù)庫，對于核心系統(tǒng)，如果需要較好的性能，可以考慮使用更強悍的硬件，這種向上擴展(升級硬件)雖然成本較高，但是是最簡單粗暴有效的方式，另外，Nosql完全不適合交易場景，Nosql主要用來做數(shù)據(jù)分析、ETL、報表、數(shù)據(jù)挖掘、推薦、日志處理等非交易場景。

前面提到的案例2-轉(zhuǎn)賬和案例3-下訂單和扣庫存都可以利用關(guān)系型數(shù)據(jù)庫的強一致性解決。

然而，前面提到，互聯(lián)網(wǎng)項目多數(shù)具有大規(guī)模高并發(fā)的特性，必須應(yīng)用拆分的理念，對高并發(fā)的壓力采取“大而化小、小而化了”的方法，否則難以滿足動輒億級流量的需求，即使使用關(guān)系型數(shù)據(jù)庫，單機也難以滿足存儲和TPS上的需求。為了保證案例2-轉(zhuǎn)賬可以利用關(guān)系型數(shù)據(jù)庫的強一致性，在拆分的時候盡量的把轉(zhuǎn)賬相關(guān)的賬戶放入一個數(shù)據(jù)庫分片，對于案例3，盡量的保證把訂單和庫存放入同一個數(shù)據(jù)庫分片，這樣通過關(guān)系型數(shù)據(jù)庫自然就解決了不一致的問題。

然而，有些時候事與愿違，由于業(yè)務(wù)規(guī)則的限制，無法將相關(guān)的數(shù)據(jù)分到同一個數(shù)據(jù)庫分片，這個時候我們就需要實現(xiàn)最終一致性。

對于案例2-轉(zhuǎn)賬場景，假設(shè)賬戶數(shù)量巨大，對賬戶存儲進行了拆分，關(guān)系型數(shù)據(jù)庫一共分了8個實例，每個實例8個庫，每個庫8個表，共512張表，假如要轉(zhuǎn)賬的兩個賬戶正好落在了一個庫里，那么可以依賴關(guān)系型數(shù)據(jù)庫的事務(wù)保持強一致性。

如果要轉(zhuǎn)賬的兩個賬戶正好落在了不同的庫里，轉(zhuǎn)賬操作是無法封裝在同一個數(shù)據(jù)庫事務(wù)中的，這個時候會發(fā)生一個庫的賬戶扣減余額成功，另外一個庫的賬戶增加余額失敗的情況。

對于這種情況，我們需要繼續(xù)探討解決之道，CAP原理和BASE原理，BASE原理通過記錄事務(wù)的中間的臨時狀態(tài)，實現(xiàn)最終一致性。

2. CAP(帽子理論)

如果想深入的學(xué)習(xí)CAP理論，請參考CAP。

由于對系統(tǒng)或者數(shù)據(jù)進行了拆分，我們的系統(tǒng)不再是單機系統(tǒng)，而是分布式系統(tǒng)，針對分布式系的帽子理論包含三個元素：

• C：Consistency，一致性, 數(shù)據(jù)一致更新，所有數(shù)據(jù)變動都是同步的
• A：Availability，可用性, 好的響應(yīng)性能，完全的可用性指的是在任何故障模型下，服務(wù)都會在有限的時間處理響應(yīng)
• P：Partition tolerance，分區(qū)容錯性，可靠性

帽子理論證明，任何分布式系統(tǒng)只可同時滿足二點，沒法三者兼顧。關(guān)系型數(shù)據(jù)庫由于關(guān)系型數(shù)據(jù)庫是單節(jié)點的，因此，不具有分區(qū)容錯性，但是具有一致性和可用性，而分布式的服務(wù)化系統(tǒng)都需要滿足分區(qū)容錯性，那么我們必須在一致性和可用性中進行權(quán)衡，具體表現(xiàn)在服務(wù)化系統(tǒng)處理的異常請求在某一個時間段內(nèi)可能是不完全的，但是經(jīng)過自動的或者手工的補償后，達到了最終的一致性。

3. BASE(堿)

BASE理論解決CAP理論提出了分布式系統(tǒng)的一致性和可用性不能兼得的問題，如果想全面的學(xué)習(xí)BASE原理，請參考Eventual consistency。

BASE在英文中有“堿”的意思，對應(yīng)本節(jié)開頭的ACID在英文中“酸”的意思，基于這兩個名詞提出了酸堿平衡的結(jié)論，簡單來說是在不同的場景下，可以分別利用ACID和BASE來解決分布式服務(wù)化系統(tǒng)的一致性問題。

BASE模型與ACID模型截然不同，滿足CAP理論，通過犧牲強一致性，獲得可用性，一般應(yīng)用在服務(wù)化系統(tǒng)的應(yīng)用層或者大數(shù)據(jù)處理系統(tǒng)，通過達到最終一致性來盡量滿足業(yè)務(wù)的絕大部分需求。

BASE模型包含個三個元素：

• BA：Basically Available，基本可用
• S：Soft State，軟狀態(tài)，狀態(tài)可以有一段時間不同步
• E：Eventually Consistent，最終一致，最終數(shù)據(jù)是一致的就可以了，而不是時時保持強一致

BASE模型的軟狀態(tài)是實現(xiàn)BASE理論的方法，基本可用和最終一致是目標(biāo)。按照BASE模型實現(xiàn)的系統(tǒng)，由于不保證強一致性，系統(tǒng)在處理請求的過程中，可以存在短暫的不一致，在短暫的不一致窗口請求處理處在臨時狀態(tài)中，系統(tǒng)在做每步操作的時候，通過記錄每一個臨時狀態(tài)，在系統(tǒng)出現(xiàn)故障的時候，可以從這些中間狀態(tài)繼續(xù)未完成的請求處理或者退回到原始狀態(tài)，***達到一致的狀態(tài)。

以案例1-轉(zhuǎn)賬為例，我們把用戶A給用戶B轉(zhuǎn)賬分成四個階段，***個階段用戶A準(zhǔn)備轉(zhuǎn)賬，第二個階段從用戶A賬戶扣減余額，第三個階段對用戶B增加余額，第四個階段完成轉(zhuǎn)賬。系統(tǒng)需要記錄操作過程中每一步驟的狀態(tài)，一旦系統(tǒng)出現(xiàn)故障，系統(tǒng)能夠自動發(fā)現(xiàn)沒有完成的任務(wù)，然后，根據(jù)任務(wù)所處的狀態(tài)，繼續(xù)執(zhí)行任務(wù)，最終完成任務(wù)，達到一致的最終狀態(tài)。

在實際應(yīng)用中，上面這個過程通常是通過持久化執(zhí)行任務(wù)的狀態(tài)和環(huán)境信息，一旦出現(xiàn)問題，定時任務(wù)會撈取未執(zhí)行完的任務(wù)，繼續(xù)未執(zhí)行完的任務(wù)，直到執(zhí)行完成為止，或者取消已經(jīng)完成的部分操作回到原始狀態(tài)。這種方法在任務(wù)完成每個階段的時候，都要更新數(shù)據(jù)庫中任務(wù)的狀態(tài)，這在大規(guī)模高并發(fā)系統(tǒng)中不會有太好的性能，一個更好的辦法是用Write-Ahead Log(寫前日志)，這和數(shù)據(jù)庫的Bin Log(操作日志)相似，在做每一個操作步驟，都先寫入日志，如果操作遇到問題而停止的時候，可以讀取日志按照步驟進行恢復(fù)，并且繼續(xù)執(zhí)行未完成的工作，***達到一致。寫前日志可以利用機械硬盤的追加寫而達到較好性能，因此，這是一種專業(yè)化的實現(xiàn)方式，多數(shù)業(yè)務(wù)系系統(tǒng)還是使用數(shù)據(jù)庫記錄的字段來記錄任務(wù)的執(zhí)行狀態(tài)，也就是記錄中間的“軟狀態(tài)”，一個任務(wù)的狀態(tài)流轉(zhuǎn)一般可以通過數(shù)據(jù)庫的行級鎖來實現(xiàn)，這比使用Write-Ahead Log實現(xiàn)更簡單、更快速。

有了BASE理論作為基礎(chǔ)，我們對復(fù)雜的分布式事務(wù)進行拆解，對其中的每一步驟都記錄其狀態(tài)，有問題的時候可以根據(jù)記錄的狀態(tài)來繼續(xù)執(zhí)行任務(wù)，達到最終的一致，通過這個方法我們可以解決案例2-轉(zhuǎn)賬和案例3-下訂單和扣庫存中遇到的問題。

4. 酸堿平衡的總結(jié)

1. 使用向上擴展(強悍的硬件)運行專業(yè)的關(guān)系型數(shù)據(jù)庫(例如：Oracle或者DB2)能夠保證強一致性，錢能解決的問題就不是問題
2. 如果錢是問題，可以對廉價硬件運行的開源關(guān)系型數(shù)據(jù)庫(例如：Mysql)進行分片，將相關(guān)的數(shù)據(jù)分到數(shù)據(jù)庫的同一個片，仍然能夠使用關(guān)系型數(shù)據(jù)庫保證事務(wù)
3. 如果業(yè)務(wù)規(guī)則限制，無法將相關(guān)的數(shù)據(jù)分到同一個片，就需要實現(xiàn)最終一致性，通過記錄事務(wù)的軟狀態(tài)(中間狀態(tài)、臨時狀態(tài))，一旦處于不一致，可以通過系統(tǒng)自動化或者人工干預(yù)來修復(fù)不一致的情況

3.3 分布式一致性協(xié)議

國際開放標(biāo)準(zhǔn)組織Open Group定義了DTS(分布式事務(wù)處理模型)，模型中包含4個角色：應(yīng)用程序、事務(wù)管理器、資源管理器、通信資源管理器四部分。事務(wù)處理器是統(tǒng)管全局的管理者，資源處理器和通信資源處理器是事務(wù)的參與者。

J2EE規(guī)范也包含此分布式事務(wù)處理模型的規(guī)范，并在所有的AppServer中進行實現(xiàn)，J2EE規(guī)范中定義了TX協(xié)議和XA協(xié)議，TX協(xié)議定義應(yīng)用程序與事務(wù)管理器之間的接口，而XA協(xié)議定義了事務(wù)管理器與資源處理器之間的接口，在過去，大家使用AppServer，例如：Websphere、Weblogic、Jboss等配置數(shù)據(jù)源的時候會看見類似XADatasource的數(shù)據(jù)源，這就是實現(xiàn)了DTS的關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)源。企業(yè)級開發(fā)JEE中，關(guān)系型數(shù)據(jù)庫、JMS服務(wù)扮演資源管理器的角色，而EJB容器則扮演事務(wù)管理器的角色。

下面我們就介紹兩階段提交協(xié)議、三階段提交協(xié)議以及阿里巴巴提出的TCC，它們都是根據(jù)DTS這一思想演變出來的。

1. 兩階段提交協(xié)議

上面描述的JEE的XA協(xié)議就是根據(jù)兩階段提交來保證事務(wù)的完整性，并實現(xiàn)分布式服務(wù)化的強一致性。

兩階段提交協(xié)議把分布式事務(wù)分成兩個過程，一個是準(zhǔn)備階段，一個是提交階段，準(zhǔn)備階段和提交階段都是由事務(wù)管理器發(fā)起的，為了接下來講解方便，我們把事務(wù)管理器稱為協(xié)調(diào)者，把資管管理器稱為參與者。

兩階段如下：

1. 準(zhǔn)備階段：協(xié)調(diào)者向參與者發(fā)起指令，參與者評估自己的狀態(tài)，如果參與者評估指令可以完成，參與者會寫redo或者undo日志(這也是前面提起的Write-Ahead Log的一種)，然后鎖定資源，執(zhí)行操作，但是并不提交
2. 提交階段：如果每個參與者明確返回準(zhǔn)備成功，也就是預(yù)留資源和執(zhí)行操作成功，協(xié)調(diào)者向參與者發(fā)起提交指令，參與者提交資源變更的事務(wù)，釋放鎖定的資源;如果任何一個參與者明確返回準(zhǔn)備失敗，也就是預(yù)留資源或者執(zhí)行操作失敗，協(xié)調(diào)者向參與者發(fā)起中止指令，參與者取消已經(jīng)變更的事務(wù)，執(zhí)行undo日志，釋放鎖定的資源

兩階段提交協(xié)議成功場景示意圖如下：

兩階段提交協(xié)議

我們看到兩階段提交協(xié)議在準(zhǔn)備階段鎖定資源，是一個重量級的操作，并能保證強一致性，但是實現(xiàn)起來復(fù)雜、成本較高，不夠靈活，更重要的是它有如下致命的問題：

阻塞：從上面的描述來看，對于任何一次指令必須收到明確的響應(yīng)，才會繼續(xù)做下一步，否則處于阻塞狀態(tài)，占用的資源被一直鎖定，不會被釋放

單點故障：如果協(xié)調(diào)者宕機，參與者沒有了協(xié)調(diào)者指揮，會一直阻塞，盡管可以通過選舉新的協(xié)調(diào)者替代原有協(xié)調(diào)者，但是如果之前協(xié)調(diào)者在發(fā)送一個提交指令后宕機，而提交指令僅僅被一個參與者接受，并且參與者接收后也宕機，新上任的協(xié)調(diào)者無法處理這種情況

腦裂：協(xié)調(diào)者發(fā)送提交指令，有的參與者接收到執(zhí)行了事務(wù)，有的參與者沒有接收到事務(wù)，就沒有執(zhí)行事務(wù)，多個參與者之間是不一致的

上面所有的這些問題，都是需要人工干預(yù)處理，沒有自動化的解決方案，因此兩階段提交協(xié)議在正常情況下能保證系統(tǒng)的強一致性，但是在出現(xiàn)異常情況下，當(dāng)前處理的操作處于錯誤狀態(tài)，需要管理員人工干預(yù)解決，因此可用性不夠好，這也符合CAP協(xié)議的一致性和可用性不能兼得的原理。

2. 三階段提交協(xié)議

三階段提交協(xié)議是兩階段提交協(xié)議的改進版本。它通過超時機制解決了阻塞的問題，并且把兩個階段增加為三個階段：

詢問階段：協(xié)調(diào)者詢問參與者是否可以完成指令，協(xié)調(diào)者只需要回答是還是不是，而不需要做真正的操作，這個階段超時導(dǎo)致中止

準(zhǔn)備階段：如果在詢問階段所有的參與者都返回可以執(zhí)行操作，協(xié)調(diào)者向參與者發(fā)送預(yù)執(zhí)行請求，然后參與者寫redo和undo日志，執(zhí)行操作，但是不提交操作;如果在詢問階段任何參與者返回不能執(zhí)行操作的結(jié)果，則協(xié)調(diào)者向參與者發(fā)送中止請求，這里的邏輯與兩階段提交協(xié)議的的準(zhǔn)備階段是相似的，這個階段超時導(dǎo)致成功

提交階段：如果每個參與者在準(zhǔn)備階段返回準(zhǔn)備成功，也就是預(yù)留資源和執(zhí)行操作成功，協(xié)調(diào)者向參與者發(fā)起提交指令，參與者提交資源變更的事務(wù)，釋放鎖定的資源;如果任何一個參與者返回準(zhǔn)備失敗，也就是預(yù)留資源或者執(zhí)行操作失敗，協(xié)調(diào)者向參與者發(fā)起中止指令，參與者取消已經(jīng)變更的事務(wù)，執(zhí)行undo日志，釋放鎖定的資源，這里的邏輯與兩階段提交協(xié)議的提交階段一致

三階段提交協(xié)議成功場景示意圖如下：

三階段提交協(xié)議

然而，這里與兩階段提交協(xié)議有兩個主要的不同：

增加了一個詢問階段，詢問階段可以確保盡可能早的發(fā)現(xiàn)無法執(zhí)行操作而需要中止的行為，但是它并不能發(fā)現(xiàn)所有的這種行為，只會減少這種情況的發(fā)生

在準(zhǔn)備階段以后，協(xié)調(diào)者和參與者執(zhí)行的任務(wù)中都增加了超時，一旦超時，協(xié)調(diào)者和參與者都繼續(xù)提交事務(wù)，默認為成功，這也是根據(jù)概率統(tǒng)計上超時后默認成功的正確性***

三階段提交協(xié)議與兩階段提交協(xié)議相比，具有如上的優(yōu)點，但是一旦發(fā)生超時，系統(tǒng)仍然會發(fā)生不一致，只不過這種情況很少見罷了，好處就是至少不會阻塞和永遠鎖定資源。

3. TCC

上面兩節(jié)講解了兩階段提交協(xié)議和三階段提交協(xié)議，實際上他們能解決案例2-轉(zhuǎn)賬和案例3-下訂單和扣庫存中的分布式事務(wù)的問題，但是遇到極端情況，系統(tǒng)會發(fā)生阻塞或者不一致的問題，需要運營或者技術(shù)人工解決。無論兩階段還是三階段方案中都包含多個參與者、多個階段實現(xiàn)一個事務(wù)，實現(xiàn)復(fù)雜，性能也是一個很大的問題，因此，在互聯(lián)網(wǎng)高并發(fā)系統(tǒng)中，鮮有使用兩階段提交和三階段提交協(xié)議的場景。

阿里巴巴提出了新的TCC協(xié)議，TCC協(xié)議將一個任務(wù)拆分成Try、Confirm、Cancel，正常的流程會先執(zhí)行Try，如果執(zhí)行沒有問題，再執(zhí)行Confirm，如果執(zhí)行過程中出了問題，則執(zhí)行操作的逆操Cancel，從正常的流程上講，這仍然是一個兩階段的提交協(xié)議，但是，在執(zhí)行出現(xiàn)問題的時候，有一定的自我修復(fù)能力，如果任何一個參與者出現(xiàn)了問題，協(xié)調(diào)者通過執(zhí)行操作的逆操作來取消之前的操作，達到最終的一致狀態(tài)。

可以看出，從時序上，如果遇到極端情況下TCC會有很多問題的，例如，如果在Cancel的時候一些參與者收到指令，而一些參與者沒有收到指令，整個系統(tǒng)仍然是不一致的，這種復(fù)雜的情況，系統(tǒng)首先會通過補償?shù)姆绞?，嘗試自動修復(fù)的，如果系統(tǒng)無法修復(fù)，必須由人工參與解決。

從TCC的邏輯上看，可以說TCC是簡化版的三階段提交協(xié)議，解決了兩階段提交協(xié)議的阻塞問題，但是沒有解決極端情況下會出現(xiàn)不一致和腦裂的問題。然而，TCC通過自動化補償手段，會把需要人工處理的不一致情況降到到最少，也是一種非常有用的解決方案，根據(jù)線人，阿里在內(nèi)部的一些中間件上實現(xiàn)了TCC模式。

我們給出一個使用TCC的實際案例，在秒殺的場景，用戶發(fā)起下單請求，應(yīng)用層先查詢庫存，確認商品庫存還有余量，則鎖定庫存，此時訂單狀態(tài)為待支付，然后指引用戶去支付，由于某種原因用戶支付失敗，或者支付超時，系統(tǒng)會自動將鎖定的庫存解鎖供其他用戶秒殺。

TCC協(xié)議使用場景示意圖如下：

TCC

總結(jié)一下，兩階段提交協(xié)議、三階段提交協(xié)議、TCC協(xié)議都能保證分布式事務(wù)的一致性，他們保證的分布式系統(tǒng)的一致性從強到弱，TCC達到的目標(biāo)是最終一致性，其中任何一種方法都可以不同程度的解決案例2：轉(zhuǎn)賬、案例3：下訂單和扣庫存的問題，只是實現(xiàn)的一致性的級別不一樣而已，對于案例4：同步超時可以通過TCC的理念解決，如果同步調(diào)用超時，調(diào)用方可以使用fastfail策略，返回調(diào)用方的使用方失敗的結(jié)果，同時調(diào)用服務(wù)的逆向cancel操作，保證服務(wù)的最終一致性。

3.4 保證最終一致性的模式

在大規(guī)模高并發(fā)服務(wù)化系統(tǒng)中，一個功能被拆分成多個具有單一功能的元功能，一個流程會有多個系統(tǒng)的多個元功能組合實現(xiàn)，如果使用兩階段提交協(xié)議和三階段提交協(xié)議，確實能解決系統(tǒng)間一致性問題，除了這兩個協(xié)議帶來的自身的問題，這些協(xié)議的實現(xiàn)比較復(fù)雜、成本比較高，最重要的是性能并不好，相比來看，TCC協(xié)議更簡單、容易實現(xiàn)，但是TCC協(xié)議由于每個事務(wù)都需要執(zhí)行Try，再執(zhí)行Confirm，略微顯得臃腫，因此，在現(xiàn)實的系統(tǒng)中，底線要求僅僅需要能達到最終一致性，而不需要實現(xiàn)專業(yè)的、復(fù)雜的一致性協(xié)議，實現(xiàn)最終一致性有一些非常有效的、簡單粗暴的模式，下面就介紹這些模式及其應(yīng)用場景。

1. 查詢模式

任何一個服務(wù)操作都需要提供一個查詢接口，用來向外部輸出操作執(zhí)行的狀態(tài)。服務(wù)操作的使用方可以通過查詢接口，得知服務(wù)操作執(zhí)行的狀態(tài)，然后根據(jù)不同狀態(tài)來做不同的處理操作。

為了能夠?qū)崿F(xiàn)查詢，每個服務(wù)操作都需要有唯一的流水號標(biāo)識，也可使用此次服務(wù)操作對應(yīng)的資源ID來標(biāo)志，例如：請求流水號、訂單號等。

首先，單筆查詢操作是必須提供的，我們也鼓勵使用單筆訂單查詢，這是因為每次調(diào)用需要占用的負載是可控的，批量查詢則根據(jù)需要來提供，如果使用了批量查詢，需要有合理的分頁機制，并且必須限制分頁的大小，以及對批量查詢的QPS需要有容量評估和流控等。

查詢模式的示意圖如下：

查詢模式

對于案例4：同步超時、案例5：異步回調(diào)超時、案例6：掉單、案例7：系統(tǒng)間狀態(tài)不一致，我們都需要使用查詢模式來了解被調(diào)用服務(wù)的處理情況，來決定下一步做什么：補償未完成的操作還是回滾已經(jīng)完成的操作。

2. 補償模式

有了上面的查詢模式，在任何情況下，我們都能得知具體的操作所處的狀態(tài)，如果整個操作處于不正常的狀態(tài)，我們需要修正操作中有問題的子操作，這可能需要重新執(zhí)行未完成的子操作，后者取消已經(jīng)完成的子操作，通過修復(fù)使整個分布式系統(tǒng)達到一致，為了讓系統(tǒng)最終一致而做的努力都叫做補償。

對于服務(wù)化系統(tǒng)中同步調(diào)用的操作，業(yè)務(wù)操作發(fā)起的主動方在還沒有得到業(yè)務(wù)操作執(zhí)行方的明確返回或者調(diào)用超時，場景可參考案例4：同步超時，這個時候業(yè)務(wù)發(fā)起的主動方需要及時的調(diào)用業(yè)務(wù)執(zhí)行方獲得操作執(zhí)行的狀態(tài)，這里使用查詢模式，獲得業(yè)務(wù)操作的執(zhí)行方的狀態(tài)后，如果業(yè)務(wù)執(zhí)行方已經(jīng)完預(yù)設(shè)的工作，則業(yè)務(wù)發(fā)起方給業(yè)務(wù)的使用方返回成功，如果業(yè)務(wù)操作的執(zhí)行方的狀態(tài)為失敗或者未知，則會立即告訴業(yè)務(wù)的使用方失敗，然后調(diào)用業(yè)務(wù)操作的逆向操作，保證操作不被執(zhí)行或者回滾已經(jīng)執(zhí)行的操作，讓業(yè)務(wù)的使用方、業(yè)務(wù)發(fā)起的主動方、業(yè)務(wù)的操作方最終達成一致的狀態(tài)。

補償模式的示意圖如下：

補償模式

補償操作根據(jù)發(fā)起形式分為：

1. 自動恢復(fù)：程序根據(jù)發(fā)生不一致的環(huán)境，通過繼續(xù)未完成的操作，或者回滾已經(jīng)完成的操作，自動來達到一致
2. 通知運營：如果程序無法自動恢復(fù)，并且設(shè)計時考慮到了不一致的場景，可以提供運營功能，通過運營手工進行補償
3. 通知技術(shù)：如果很不巧，系統(tǒng)無法自動回復(fù)，又沒有運營功能，那必須通過技術(shù)手段來解決，技術(shù)手段包括走數(shù)據(jù)庫變更或者代碼變更來解決，這是最糟的一種場景

3. 異步確保模式

異步確保模式是補償模式的一個典型案例，經(jīng)常應(yīng)用到使用方對響應(yīng)時間要求并不太高，我們通常把這類操作從主流程中摘除，通過異步的方式進行處理，處理后把結(jié)果通過通知系統(tǒng)通知給使用方，這個方案***的好處能夠?qū)Ω卟l(fā)流量進行消峰，例如：電商系統(tǒng)中的物流、配送，以及支付系統(tǒng)中的計費、入賬等。

實踐中，將要執(zhí)行的異步操作封裝后持久入庫，然后通過定時撈取未完成的任務(wù)進行補償操作來實現(xiàn)異步確保模式，只要定時系統(tǒng)足夠健壯，任何一個任務(wù)最終會被成功執(zhí)行。

異步確保模式的示意圖如下：

異步確保模式

對于案例5：異步回調(diào)超時，使用的就是異步確保模式，這種情況下對于某個操作，如果遲遲沒有收到響應(yīng)，我們通過查詢模式和補償模式來繼續(xù)未完成的操作。

4. 定期校對模式

既然我們在系統(tǒng)中實現(xiàn)最終一致性，系統(tǒng)在沒有達到一致之前，系統(tǒng)間的狀態(tài)是不一致的，甚至是混亂的，需要補償操作來達到一致的目的，但是我們?nèi)绾蝸戆l(fā)現(xiàn)需要補償?shù)牟僮髂?

在操作的主流程中的系統(tǒng)間執(zhí)行校對操作，我們可以事后異步的批量校對操作的狀態(tài)，如果發(fā)現(xiàn)不一致的操作，則進行補償，補償操作與補償模式中的補償操作是一致的。

另外，實現(xiàn)定期校對的一個關(guān)鍵就是分布式系統(tǒng)中需要有一個自始至終唯一的ID，ID的生成請參考SnowFlake。

在分布式系統(tǒng)中，全局唯一ID的示意圖如下：

唯一ID

一般情況下，生成全局唯一ID有兩種方法：

1. 持久型：使用數(shù)據(jù)庫表自增字段或者Sequence生成，為了提高效率，每個應(yīng)用節(jié)點可以緩存一批次的ID，如果機器重啟可能會損失一部分ID，但是這并不會產(chǎn)生任何問題
2. 時間型：一般由機器號、業(yè)務(wù)號、時間、單節(jié)點內(nèi)自增ID組成，由于時間一般精確到秒或者毫秒，因此不需要持久就能保證在分布式系統(tǒng)中全局唯一、粗略遞增能特點

實踐中，為了能在分布式系統(tǒng)中迅速的定位問題，一般的分布式系統(tǒng)都有技術(shù)支持系統(tǒng)，它能夠跟蹤一個請求的調(diào)用鏈，調(diào)用鏈?zhǔn)窃诙S的維度跟蹤一個調(diào)用請求，***形成一個調(diào)用樹，原理可參考谷歌的論文Dapper, a Large-Scale Distributed Systems Tracing Infrastructure，一個開源的參考實現(xiàn)為pinpoint。

在分布式系統(tǒng)中，調(diào)用鏈的示意圖如下：

調(diào)用鏈

全局的唯一流水ID可以把一個請求在分布式系統(tǒng)中的流轉(zhuǎn)的路徑聚合，而調(diào)用鏈中的spanid可以把聚合的請求路徑通過樹形結(jié)構(gòu)進行展示，讓技術(shù)支持人員輕松的發(fā)現(xiàn)系統(tǒng)出現(xiàn)的問題，能夠快速定位出現(xiàn)問題的服務(wù)節(jié)點，提高應(yīng)急效率。

關(guān)于訂單跟蹤、調(diào)用鏈跟蹤、業(yè)務(wù)鏈跟蹤，我們會在后續(xù)文章中詳細介紹。

在分布式系統(tǒng)中構(gòu)建了唯一ID，調(diào)用鏈等基礎(chǔ)設(shè)施，我們很容易對系統(tǒng)間的不一致進行核對，通常我們需要構(gòu)建第三方的定期核對系統(tǒng)，以第三方的角度來監(jiān)控服務(wù)執(zhí)行的健康程度。

定期核對系統(tǒng)示意圖如下：

定期核對模式

對于案例6：掉單、案例7：系統(tǒng)間狀態(tài)不一致通常通過定期校對模式發(fā)現(xiàn)問題，并通過補償模式來修復(fù)，***完成系統(tǒng)間的最終一致性。

定期校對模式多應(yīng)用在金融系統(tǒng)，金融系統(tǒng)由于涉及到資金安全，需要保證***的準(zhǔn)確性，所以，需要多重的一致性保證機制，包括：系統(tǒng)間的一致性對賬、現(xiàn)金對賬、賬務(wù)對賬、手續(xù)費對賬等等，這些都屬于定期校對模式，順便說一下，金融系統(tǒng)與社交應(yīng)用在技術(shù)上本質(zhì)的區(qū)別在于社交應(yīng)用在于量大，而金融系統(tǒng)在于數(shù)據(jù)的準(zhǔn)確性。

到現(xiàn)在為止，我們看到通過查詢模式、補償模式、定期核對模式可以解決案例4到案例7的所有問題，對于案例4：同步超時，如果同步超時，我們需要查詢狀態(tài)進行補償，對于案例5：異步回調(diào)超時，如果遲遲沒有收到回調(diào)響應(yīng)，我們也會通過查詢狀態(tài)進行補償，對于案例6：掉單、案例7：系統(tǒng)間狀態(tài)不一致，我們通過定期核對模式可以保證系統(tǒng)間操作的一致性，避免掉單和狀態(tài)不一致導(dǎo)致問題。

5. 可靠消息模式

在分布式系統(tǒng)中，對于主流程中優(yōu)先級比較低的操作，大多采用異步的方式執(zhí)行，也就是前面提到的異步確保型，為了讓異步操作的調(diào)用方和被調(diào)用方充分的解耦，也由于專業(yè)的消息隊列本身具有可伸縮、可分片、可持久等功能，我們通常通過消息隊列實現(xiàn)異步化，對于消息隊列，我們需要建立特殊的設(shè)施保證可靠的消息發(fā)送以及處理機的冪等等。

消息的可靠發(fā)送

消息的可靠發(fā)送可以認為是盡***努力發(fā)送消息通知，有兩種實現(xiàn)方法：

***種，發(fā)送消息之前，把消息持久到數(shù)據(jù)庫，狀態(tài)標(biāo)記為待發(fā)送，然后發(fā)送消息，如果發(fā)送成功，將消息改為發(fā)送成功。定時任務(wù)定時從數(shù)據(jù)庫撈取一定時間內(nèi)未發(fā)送的消息，將消息發(fā)送。

消息發(fā)送模式1

第二種，實現(xiàn)方式與***種類似，不同的是持久消息的數(shù)據(jù)庫是獨立的，并不耦合在業(yè)務(wù)系統(tǒng)中。發(fā)送消息之前，先發(fā)送一個預(yù)消息給某一個第三方的消息管理器，消息管理器將其持久到數(shù)據(jù)庫，并標(biāo)記狀態(tài)為待發(fā)送，發(fā)送成功后，標(biāo)記消息為發(fā)送成功。定時任務(wù)定時從數(shù)據(jù)庫撈取一定時間內(nèi)未發(fā)送的消息，回查業(yè)務(wù)系統(tǒng)是否要繼續(xù)發(fā)送，根據(jù)查詢結(jié)果來確定消息的狀態(tài)。

消息發(fā)送模式2

一些公司把消息的可靠發(fā)送實現(xiàn)在了中間件里，通過Spring的注入，在消息發(fā)送的時候自動持久消息記錄，如果有消息記錄沒有發(fā)送成功，定時會補償發(fā)送。

消息處理器的冪等性

如果我們要保證消息可靠的發(fā)送，簡單來說，要保證消息一定要發(fā)送出去，那么就需要有重試機制，有了重試機制，消息一定會重復(fù)，那么我們需要對重復(fù)做處理。

處理重復(fù)的***方式為保證操作的冪等性，冪等性的數(shù)學(xué)公式為：

f(f(x)) = f(x)

保證操作的冪等性常用的幾個方法：

1. 使用數(shù)據(jù)庫表的唯一鍵進行濾重，拒絕重復(fù)的請求
2. 使用分布式表對請求進行濾重
3. 使用狀態(tài)流轉(zhuǎn)的方向性來濾重，通常使用行級鎖來實現(xiàn)(后續(xù)在鎖相關(guān)的文章中詳細說明)
4. 根據(jù)業(yè)務(wù)的特點，操作本身就是冪等的，例如：刪除一個資源、增加一個資源、獲得一個資源等

6. 緩存一致性模型

大規(guī)模高并發(fā)系統(tǒng)中一個常見的核心需求就是億級的讀需求，顯然，關(guān)系型數(shù)據(jù)庫并不是解決高并發(fā)讀需求的***方案，互聯(lián)網(wǎng)的經(jīng)典做法就是使用緩存抗讀需求，下面有一些使用緩存的保證一致性的***實踐：

1. 如果性能要求不是非常的高，盡量使用分布式緩存，而不要使用本地緩存
2. 種緩存的時候一定種完全，如果緩存數(shù)據(jù)的一部分有效，一部分無效，寧可放棄種緩存，也不要把部分數(shù)據(jù)種入緩存
3. 數(shù)據(jù)庫與緩存只需要保持弱一致性，而不需要強一致性，讀的順序要先緩存，后數(shù)據(jù)庫，寫的順序要先數(shù)據(jù)庫，后緩存

這里的***實踐能夠解決案例8：緩存和數(shù)據(jù)庫不一致、案例9：本地緩存節(jié)點間不一致、案例10：緩存數(shù)據(jù)結(jié)構(gòu)不一致的問題，對于數(shù)據(jù)存儲層、緩存與數(shù)據(jù)庫、Nosql等的一致性是更深入的存儲一致性技術(shù)，將會在后續(xù)文章單獨介紹，這里的數(shù)據(jù)一致性主要是處理應(yīng)用層與緩存、應(yīng)用層與數(shù)據(jù)庫、一部分的緩存與數(shù)據(jù)庫的一致性。

3.5 專題模式

這一節(jié)介紹特殊場景下的一致性問題和解決方案。

遷移開關(guān)的設(shè)計

在大多數(shù)企業(yè)里，新項目和老項目一般會共存，大家都在努力的下掉老項目，但是由于種種原因總是下不掉，如果要徹底的下掉老項目，就必須要有非常完善的遷移方案，遷移是一項非常復(fù)雜而艱巨的任務(wù)，我會在將來的文章中詳細探討遷移方案、流程和技術(shù)，這里我們只對遷移中使用的開關(guān)進行描述。

遷移過程必須使用開關(guān)，開關(guān)一般都會基于多個維度來設(shè)計，例如：全局的、用戶的、角色的、商戶的、產(chǎn)品的等等，如果遷移過程中遇到問題，我們需要關(guān)閉開關(guān)，遷移回老的系統(tǒng)，這需要我們的新系統(tǒng)兼容老的數(shù)據(jù)，老的系統(tǒng)也兼容新的數(shù)據(jù)，從某種意義上來講，遷移比實現(xiàn)新系統(tǒng)更加困難。

曾經(jīng)看過很多簡單的開關(guān)設(shè)計，有的開關(guān)設(shè)計在應(yīng)用層次，通過一個curl語句調(diào)用，沒有權(quán)限控制，這樣的開關(guān)在服務(wù)池的每個節(jié)點都是不同步的、不一致的;還有的系統(tǒng)把開關(guān)配置放在中心化的配置系統(tǒng)、數(shù)據(jù)庫或者緩存等，處理的每個請求都通過統(tǒng)一的開關(guān)來判斷是否遷移等等，這樣的開關(guān)有一個致命的缺點，服務(wù)請求在處理過程中，開關(guān)可能會變化，各個節(jié)點之間開關(guān)可能不同步、不一致，導(dǎo)致重復(fù)的請求可能走到新的邏輯又走了老的邏輯，如果新的邏輯和老的邏輯沒有保證冪等性，這個請求就被重復(fù)處理了，如果是金融行業(yè)的應(yīng)用，可能會導(dǎo)致資金損失，電商系統(tǒng)可能會導(dǎo)致發(fā)貨并退款等問題。

這里面我們推薦使用訂單開關(guān)，不管我們在什么維度上設(shè)計了開關(guān)，接收到服務(wù)請求后，我們在請求創(chuàng)建的關(guān)聯(lián)實體(例如：訂單)上標(biāo)記開關(guān)，以后的任何處理流程，包括同步的和異步的處理流程，都通過訂單上的開關(guān)來判斷，而不是通過全局的或者基于配置的開關(guān)，這樣在訂單創(chuàng)建的時候，開關(guān)已經(jīng)確定，不再變更，一旦一份數(shù)據(jù)不再發(fā)生變化，那么它永遠是線程安全的，并且不會有不一致的問題。

這個模式在生產(chǎn)中使用比較頻繁，建議每個企業(yè)都把這個模式作為設(shè)計評審的一項，如果不檢查這一項，很多開發(fā)童鞋都會偷懶，直接在配置中或者數(shù)據(jù)庫中做個開關(guān)就上線了。

4 總結(jié)

本文從一致性問題的實踐出發(fā)，從大規(guī)模高并發(fā)服務(wù)化系統(tǒng)的實踐經(jīng)驗中進行總結(jié)，列舉導(dǎo)致不一致的具體問題，圍繞著具體問題，總結(jié)出解決不一致的方法，并且抽象成模式，供大家在開發(fā)服務(wù)化系統(tǒng)的過程中參考。

另外，由于篇幅有限，還有一些關(guān)于分布式一致性的技術(shù)無法在一篇文章中與大家分享，包括：paxos算法、raft算法、zab算法、nwr算法、一致性哈希等，我會在后續(xù)文章中詳細介紹。

點擊《分布式服務(wù)化系統(tǒng)一致性的“***實干”》閱讀原文。

【本文為51CTO專欄作者“李艷鵬”的原創(chuàng)稿件，轉(zhuǎn)載可通過作者簡書號(李艷鵬)或51CTO專欄獲取聯(lián)系】

戳這里，看該作者更多好文