支付平台架構師談大規模高並發服務化系統設計經驗

本文轉自簡書作者：李艷鵬
原文鏈接：http://www.jianshu.com/p/1156151e20c8

作者簡介：

李艷鵬
支付平台架構師，專注線上和線下支付平台的應用架構和技術架構的規划與落地，負責交易、支付、渠道、賬務、計費、風控、對賬等系統的設計與實現，在移動支付、聚合支付、合規賬戶、掃碼支付、標記化支付等業務場景上有產品應用架構規划的經驗。

1、背景

一致性是一個抽象的、具有多重含義的計算機術語，在不同應用場景下，有不同的定義和含義。在傳統的IT時代，一致性通常指強一致性，強一致性通常體現在你中有我、我中有你、渾然一體；

而在互聯網時代，一致性的含義遠遠超出了它原有的含義，在我們討論互聯網時代的一致性之前，我們先了解一下互聯網時代的特點，互聯網時代信息量巨大、需要計算能力巨大，不但對用戶響應速度要求快，而且吞吐量指標也要向外擴展（既：水平伸縮）。

於是單節點的服務器無法滿足需求，服務節點開始池化，想想那個經典的故事，一只筷子一折就斷，一把筷子怎么都折不斷，可見人多力量大的思想是多么的重要。

但是人多也不一定能解決所有事情，還得進行有序、合理的分配任務，進行有效的管理，於是互聯網時代談論最多的話題就是拆分，拆分一般分為“水平拆分”和“垂直拆分”（大家不要對應到數據庫或者緩存拆分，這里主要表達一種邏輯）。

• “水平拆分”指的是同一個功能由於單機節點無法滿足性能需求，需要擴展成為多節點，多個節點具有一致的功能，組成一個服務池，一個節點服務一部分的請求量，團結起來共同處理大規模高並發的請求量。

• “垂直拆分”指的是按照功能拆分，秉着“專業的人干專業的事兒”的原則，把一個復雜的功能拆分到多個單一的簡單的元功能，不同的元功能組合在一起，和未拆分前完成的功能是一致的，由於每個元功能職責單一、功能簡單，讓維護和變更都變得更簡單、安全，更易於產品版本的迭代，在這樣的一個互聯網的時代和環境，一致性指分布式服務化系統之間的弱一致性，包括應用系統一致性和數據一致性。

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

本文根據作者在互聯網企業的實際項目經驗，對服務化系統中最難解決的一致性問題進行研究和探討，試圖從實踐經驗中找到規律，抽象出模式，分享給大家，希望對大家的項目實施有所幫助。

在對實踐的總結中也會對相關的一致性術語做最朴實的解釋，希望能幫助大家徹底理解一致性的本質，並能將其應用到實踐，解決讀者現實中遇到的服務化系統的一致性問題，本文使用理論與實踐相結合的方法，突出在實踐中解決問題的模式，因此叫做《分布式服務化系統一致性的“最佳實干”》。

2、問題

本節列舉不一致會導致的種種問題，這也包括一例生活中的問題。

案例1：買房

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

案例2：轉賬

轉賬是經典的不一致案例，設想一下銀行為你處理一筆轉賬，扣減你賬戶上的余額，然后增加別人賬戶的余額；如果扣減你的賬戶余額成功，增加別人賬戶余額失敗，那么你就會損失這筆資金。

反過來，如果扣減你的賬戶余額失敗，增加別人賬戶余額成功，那么銀行就會損失這筆資金，銀行需要賠付。對於資金處理系統來說，上面任何一種場景都是不允許發生的，一旦發生就會有資金損失，后果是不堪設想的，嚴重情況會讓一個公司瞬間倒閉，可參考案例。

案例3：下訂單和扣庫存

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

案例4：同步超時

服務化的系統間調用常常因為網絡問題導致系統間調用超時，即使是網絡很好的機房，在億次流量的基數下，同步調用超時也是家常便飯。系統A同步調用系統B超時，系統A可以明確得到超時反饋，但是無法確定系統B是否已經完成了預定的功能或者沒有完成預定的功能。

於是，系統A就迷茫了，不知道應該繼續做什么，如何反饋給使用方。（曾經的一個 B2B 產品的客戶要求接口超時重新通知他們，這個在技術上是難以實現的，因為服務器本身可能並不知道自己超時，可能會繼續正常的返回數據，只是客戶端並沒有接受到結果罷了，因此這不是一個合理的解決方案）。

案例5：異步回調超時

此案例和上一個同步超時案例類似，不過這個場景使用了異步回調，系統A同步調用系統B發起指令，系統B采用受理模式，受理后則返回受理成功，然后系統B異步通知系統A。

在這個過程中，如果系統A由於某種原因遲遲沒有收到回調結果，那么兩個系統間的狀態就不一致，互相認知不同會導致系統間發生錯誤，嚴重情況下會影響核心事務，甚至會導致資金損失。

案例6：掉單

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

案例7：系統間狀態不一致

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

案例8：緩存和數據庫不一致

交易相關系統基本離不開關系型數據庫，依賴關系型數據庫提供的 ACID 特性（后面介紹），但是在大規模高並發的互聯網系統里，一些特殊的場景對讀的性能要求極高，服務於交易的數據庫難以抗住大規模的讀流量，通常需要在數據庫前墊緩存，那么緩存和數據庫之間的數據如何保持一致性？是要保持強一致呢還是弱一致性呢？

案例9：本地緩存節點間不一致

一個服務池上的多個節點為了滿足較高的性能需求，需要使用本地緩存，使用了本地緩存，每個節點都會有一份緩存數據的拷貝，如果這些數據是靜態的、不變的，那永遠都不會有問題，但是如果這些數據是半靜態的或者常被更新的，當被更新的時候，各個節點更新是有先后順序的，在更新的瞬間，各個節點的數據是不一致的。

如果這些數據是為某一個開關服務的，想象一下重復的請求走進了不同的節點（在 failover 或者補償導致的場景下，重復請求是一定會發生的，也是服務化系統必須處理的），一個請求走了開關打開的邏輯，同時另外一個請求走了開關關閉的邏輯，這導致請求被處理兩次，最壞的情況下會導致災難性的后果，就是資金損失。

案例10：緩存數據結構不一致

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

3、模式

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

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

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

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

3.2 酸鹼平衡理論

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

1. ACID（酸）

如何保證強一致性呢？計算機專業的童鞋在學習關系型數據庫的時候都學習了 ACID 原理，這里對 ACID 做個簡單的介紹。如果想全面的學習 ACID 原理，請參考 ACID（https://en.wikipedia.org/wiki/ACID）。

關系型數據庫天生就是解決具有復雜事務場景的問題，關系型數據庫完全滿足 ACID 的特性。

ACID 指的是：

• A：Atomicity，原子性

• C:：Consistency，一致性

• I：Isolation，隔離性

• D：Durability，持久性

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

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

如果你在為交易相關系統做技術選型，交易的存儲應該只考慮關系型數據庫，對於核心系統，如果需要較好的性能，可以考慮使用更強悍的硬件，這種向上擴展（升級硬件）雖然成本較高，但是是最簡單粗暴有效的方式。

另外，Nosql 完全不適合交易場景，Nosql 主要用來做數據分析、ETL、報表、數據挖掘、推薦、日志處理等非交易場景。

前面提到的案例2-轉賬和案例3-下訂單和扣庫存都可以利用關系型數據庫的強一致性解決。

然而，前面提到，互聯網項目多數具有大規模高並發的特性，必須應用拆分的理念，對高並發的壓力采取“大而化小、小而化了”的方法，否則難以滿足動輒億級流量的需求，即使使用關系型數據庫，單機也難以滿足存儲和 TPS 上的需求。

為了保證案例2-轉賬可以利用關系型數據庫的強一致性，在拆分的時候盡量的把轉賬相關的賬戶放入一個數據庫分片，對於案例3，盡量的保證把訂單和庫存放入同一個數據庫分片，這樣通過關系型數據庫自然就解決了不一致的問題。

然而，有些時候事與願違，由於業務規則的限制，無法將相關的數據分到同一個數據庫分片，這個時候我們就需要實現最終一致性。

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

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

對於這種情況，我們需要繼續探討解決之道，CAP原理和BASE原理，BASE原理通過記錄事務的中間的臨時狀態，實現最終一致性。

2. CAP（帽子理論）

如果想深入的學習 CAP 理論，請參考 CAP（https://en.wikipedia.org/wiki/CAP_theorem）。

由於對系統或者數據進行了拆分，我們的系統不再是單機系統，而是分布式系統，針對分布式系的帽子理論包含三個元素：

• C：Consistency，一致性，數據一致更新，所有數據變動都是同步的；

• A：Availability，可用性， 好的響應性能，完全的可用性指的是在任何故障模型下，服務都會在有限的時間處理響應；

• P：Partition tolerance，分區容錯性，可靠性；

帽子理論證明，任何分布式系統只可同時滿足二點，沒法三者兼顧。關系型數據庫由於關系型數據庫是單節點的，因此，不具有分區容錯性，但是具有一致性和可用性，而分布式的服務化系統都需要滿足分區容錯性。

那么我們必須在一致性和可用性中進行權衡，具體表現在服務化系統處理的異常請求在某一個時間段內可能是不完全的，但是經過自動的或者手工的補償后，達到了最終的一致性。

3. BASE（鹼）

BASE 理論解決 CAP 理論提出了分布式系統的一致性和可用性不能兼得的問題，如果想全面的學習BASE原理，請參考 Eventual consistency（https://en.wikipedia.org/wiki/Eventual_consistency）。

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

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

BASE 模型包含個三個元素：

• BA：Basically Available，基本可用

• S：Soft State，軟狀態，狀態可以有一段時間不同步

• E：Eventually Consistent，最終一致，最終數據是一致的就可以了，而不是時時保持強一致

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

以案例1-轉賬為例，我們把用戶A給用戶B轉賬分成四個階段，第一個階段用戶A准備轉賬，第二個階段從用戶A賬戶扣減余額，第三個階段對用戶B增加余額，第四個階段完成轉賬。

系統需要記錄操作過程中每一步驟的狀態，一旦系統出現故障，系統能夠自動發現沒有完成的任務，然后，根據任務所處的狀態，繼續執行任務，最終完成任務，達到一致的最終狀態。

在實際應用中，上面這個過程通常是通過持久化執行任務的狀態和環境信息，一旦出現問題，定時任務會撈取未執行完的任務，繼續未執行完的任務，直到執行完成為止，或者取消已經完成的部分操作回到原始狀態。

這種方法在任務完成每個階段的時候，都要更新數據庫中任務的狀態，這在大規模高並發系統中不會有太好的性能，一個更好的辦法是用 Write-Ahead Log（寫前日志），這和數據庫的 Bin Log（操作日志）相似，在做每一個操作步驟，都先寫入日志，如果操作遇到問題而停止的時候，可以讀取日志按照步驟進行恢復，並且繼續執行未完成的工作，最后達到一致。

寫前日志可以利用機械硬盤的追加寫而達到較好性能，因此，這是一種專業化的實現方式，多數業務系系統還是使用數據庫記錄的字段來記錄任務的執行狀態，也就是記錄中間的“軟狀態”，一個任務的狀態流轉一般可以通過數據庫的行級鎖來實現，這比使用 Write-Ahead Log 實現更簡單、更快速。

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

4. 酸鹼平衡的總結

1. 使用向上擴展（強悍的硬件）運行專業的關系型數據庫（例如：Oracle或者DB2）能夠保證強一致性，錢能解決的問題就不是問題

2. 如果錢是問題，可以對廉價硬件運行的開源關系型數據庫（例如：Mysql）進行分片，將相關的數據分到數據庫的同一個片，仍然能夠使用關系型數據庫保證事務

3. 如果業務規則限制，無法將相關的數據分到同一個片，就需要實現最終一致性，通過記錄事務的軟狀態（中間狀態、臨時狀態），一旦處於不一致，可以通過系統自動化或者人工干預來修復不一致的情況

3.3 分布式一致性協議

國際開放標准組織 Open Group 定義了 DTS（分布式事務處理模型），模型中包含4個角色：

• 應用程序；

• 事務管理器；

• 資源管理器；

• 通信資源管理器

事務處理器是統管全局的管理者，資源處理器和通信資源處理器是事務的參與者。

J2EE 規范也包含此分布式事務處理模型的規范，並在所有的 AppServer 中進行實現，J2EE 規范中定義了 TX 協議和 XA 協議，TX 協議定義應用程序與事務管理器之間的接口，而 XA 協議定義了事務管理器與資源處理器之間的接口。

在過去，大家使用 AppServer，例如：Websphere、Weblogic、Jboss 等配置數據源的時候會看見類似 XADatasource 的數據源，這就是實現了 DTS 的關系型數據庫的數據源。企業級開發 JEE 中，關系型數據庫、JMS 服務扮演資源管理器的角色，而 EJB 容器則扮演事務管理器的角色。

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

1. 兩階段提交協議

上面描述的 JEE 的 XA 協議就是根據兩階段提交來保證事務的完整性，並實現分布式服務化的強一致性。

兩階段提交協議把分布式事務分成兩個過程，一個是准備階段，一個是提交階段，准備階段和提交階段都是由事務管理器發起的，為了接下來講解方便，我們把事務管理器稱為協調者，把資管管理器稱為參與者。

兩階段如下：

• 准備階段：協調者向參與者發起指令，參與者評估自己的狀態，如果參與者評估指令可以完成，參與者會寫 redo 或者 undo 日志（這也是前面提起的 Write-Ahead Log 的一種），然后鎖定資源，執行操作，但是並不提交；

• 提交階段：如果每個參與者明確返回准備成功，也就是預留資源和執行操作成功，協調者向參與者發起提交指令，參與者提交資源變更的事務，釋放鎖定的資源；

  如果任何一個參與者明確返回准備失敗，也就是預留資源或者執行操作失敗，協調者向參與者發起中止指令，參與者取消已經變更的事務，執行 undo 日志，釋放鎖定的資源；

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

兩階段提交協議

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

1. 阻塞：從上面的描述來看，對於任何一次指令必須收到明確的響應，才會繼續做下一步，否則處於阻塞狀態，占用的資源被一直鎖定，不會被釋放；

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

3. 腦裂：協調者發送提交指令，有的參與者接收到執行了事務，有的參與者沒有接收到事務，就沒有執行事務，多個參與者之間是不一致的；

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

2. 三階段提交協議

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

1. 詢問階段：協調者詢問參與者是否可以完成指令，協調者只需要回答是還是不是，而不需要做真正的操作，這個階段超時導致中止；

2. 准備階段：如果在詢問階段所有的參與者都返回可以執行操作，協調者向參與者發送預執行請求，然后參與者寫 redo 和 undo 日志，執行操作，但是不提交操作；

   如果在詢問階段任何參與者返回不能執行操作的結果，則協調者向參與者發送中止請求，這里的邏輯與兩階段提交協議的的准備階段是相似的，這個階段超時導致成功；

3. 提交階段：如果每個參與者在准備階段返回准備成功，也就是預留資源和執行操作成功，協調者向參與者發起提交指令，參與者提交資源變更的事務，釋放鎖定的資源；

   如果任何一個參與者返回准備失敗，也就是預留資源或者執行操作失敗，協調者向參與者發起中止指令，參與者取消已經變更的事務，執行 undo 日志，釋放鎖定的資源，這里的邏輯與兩階段提交協議的提交階段一致；

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

三階段提交協議

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

1. 增加了一個詢問階段，詢問階段可以確保盡可能早的發現無法執行操作而需要中止的行為，但是它並不能發現所有的這種行為，只會減少這種情況的發生；

2. 在准備階段以后，協調者和參與者執行的任務中都增加了超時，一旦超時，協調者和參與者都繼續提交事務，默認為成功，這也是根據概率統計上超時后默認成功的正確性最大；

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

3. TCC

上面兩節講解了兩階段提交協議和三階段提交協議，實際上他們能解決案例2-轉賬和案例3-下訂單和扣庫存中的分布式事務的問題，但是遇到極端情況，系統會發生阻塞或者不一致的問題，需要運營或者技術人工解決。

無論兩階段還是三階段方案中都包含多個參與者、多個階段實現一個事務，實現復雜，性能也是一個很大的問題，因此，在互聯網高並發系統中，鮮有使用兩階段提交和三階段提交協議的場景。

阿里巴巴提出了新的 TCC 協議，TCC 協議將一個任務拆分成 Try、Confirm、Cancel，正常的流程會先執行 Try，如果執行沒有問題，再執行 Confirm。

如果執行過程中出了問題，則執行操作的逆操 Cancel，從正常的流程上講，這仍然是一個兩階段的提交協議，但是，在執行出現問題的時候，有一定的自我修復能力，如果任何一個參與者出現了問題，協調者通過執行操作的逆操作來取消之前的操作，達到最終的一致狀態。

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

從 TCC 的邏輯上看，可以說 TCC 是簡化版的三階段提交協議，解決了兩階段提交協議的阻塞問題，但是沒有解決極端情況下會出現不一致和腦裂的問題。

然而，TCC 通過自動化補償手段，會把需要人工處理的不一致情況降到到最少，也是一種非常有用的解決方案，根據線人，阿里在內部的一些中間件上實現了 TCC 模式。

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

TCC 協議使用場景示意圖如下：

 

TCC

總結一下，兩階段提交協議、三階段提交協議、TCC 協議都能保證分布式事務的一致性，他們保證的分布式系統的一致性從強到弱，TCC 達到的目標是最終一致性，其中任何一種方法都可以不同程度的解決案例2：轉賬、案例3：下訂單和扣庫存的問題，只是實現的一致性的級別不一樣而已。

對於案例4：同步超時可以通過 TCC 的理念解決，如果同步調用超時，調用方可以使用 fastfail 策略，返回調用方的使用方失敗的結果，同時調用服務的逆向 cancel 操作，保證服務的最終一致性。

3.4 保證最終一致性的模式

在大規模高並發服務化系統中，一個功能被拆分成多個具有單一功能的元功能，一個流程會有多個系統的多個元功能組合實現，如果使用兩階段提交協議和三階段提交協議，確實能解決系統間一致性問題。

除了這兩個協議帶來的自身的問題，這些協議的實現比較復雜、成本比較高，最重要的是性能並不好，相比來看，TCC 協議更簡單、容易實現，但是 TCC 協議由於每個事務都需要執行 Try，再執行 Confirm 略微顯得臃腫。

因此，在現實的系統中，底線要求僅僅需要能達到最終一致性，而不需要實現專業的、復雜的一致性協議，實現最終一致性有一些非常有效的、簡單粗暴的模式，下面就介紹這些模式及其應用場景。

1. 查詢模式

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

為了能夠實現查詢，每個服務操作都需要有唯一的流水號標識，也可使用此次服務操作對應的資源 ID 來標志，例如：請求流水號、訂單號等。

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

查詢模式的示意圖如下：

 查詢模式

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

2. 補償模式

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

對於服務化系統中同步調用的操作，業務操作發起的主動方在還沒有得到業務操作執行方的明確返回或者調用超時，場景可參考案例4：同步超時，這個時候業務發起的主動方需要及時的調用業務執行方獲得操作執行的狀態。

這里使用查詢模式，獲得業務操作的執行方的狀態后，如果業務執行方已經完預設的工作，則業務發起方給業務的使用方返回成功，如果業務操作的執行方的狀態為失敗或者未知，則會立即告訴業務的使用方失敗。

然后調用業務操作的逆向操作，保證操作不被執行或者回滾已經執行的操作，讓業務的使用方、業務發起的主動方、業務的操作方最終達成一致的狀態。

補償模式的示意圖如下：

補償模式

補償操作根據發起形式分為：

1. 自動恢復：程序根據發生不一致的環境，通過繼續未完成的操作，或者回滾已經完成的操作，自動來達到一致；

2. 通知運營：如果程序無法自動恢復，並且設計時考慮到了不一致的場景，可以提供運營功能，通過運營手工進行補償；

3. 通知技術：如果很不巧，系統無法自動回復，又沒有運營功能，那必須通過技術手段來解決，技術手段包括走數據庫變更或者代碼變更來解決，這是最糟的一種場景；

3. 異步確保模式

異步確保模式是補償模式的一個典型案例，經常應用到使用方對響應時間要求並不太高，我們通常把這類操作從主流程中摘除。

通過異步的方式進行處理，處理后把結果通過通知系統通知給使用方，這個方案最大的好處能夠對高並發流量進行消峰，例如：電商系統中的物流、配送，以及支付系統中的計費、入賬等。

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

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

 

異步確保模式

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

4. 定期校對模式

既然我們在系統中實現最終一致性，系統在沒有達到一致之前，系統間的狀態是不一致的，甚至是混亂的，需要補償操作來達到一致的目的，但是我們如何來發現需要補償的操作呢？

在操作的主流程中的系統間執行校對操作，我們可以事后異步的批量校對操作的狀態，如果發現不一致的操作，則進行補償，補償操作與補償模式中的補償操作是一致的。

另外，實現定期校對的一個關鍵就是分布式系統中需要有一個自始至終唯一的 ID，ID 的生成請參考 SnowFlake（https://github.com/twitter/snowflake）。

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

唯一ID

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

1. 持久型：使用數據庫表自增字段或者 Sequence 生成，為了提高效率，每個應用節點可以緩存一批次的ID，如果機器重啟可能會損失一部分ID，但是這並不會產生任何問題；

2. 時間型：一般由機器號、業務號、時間、單節點內自增ID組成，由於時間一般精確到秒或者毫秒，因此不需要持久就能保證在分布式系統中全局唯一、粗略遞增能特點；

實踐中，為了能在分布式系統中迅速的定位問題，一般的分布式系統都有技術支持系統，它能夠跟蹤一個請求的調用鏈，調用鏈是在二維的維度跟蹤一個調用請求，最后形成一個調用樹，原理可參考谷歌的論文 Dapper, a Large-Scale Distributed Systems Tracing Infrastructure，一個開源的參考實現為 pinpoint。

在分布式系統中，調用鏈的示意圖如下：

調用鏈

全局的唯一流水ID 可以把一個請求在分布式系統中的流轉的路徑聚合，而調用鏈中的 spanid 可以把聚合的請求路徑通過樹形結構進行展示，讓技術支持人員輕松的發現系統出現的問題，能夠快速定位出現問題的服務節點，提高應急效率。

關於訂單跟蹤、調用鏈跟蹤、業務鏈跟蹤，我們會在后續文章中詳細介紹。

在分布式系統中構建了唯一ID，調用鏈等基礎設施，我們很容易對系統間的不一致進行核對，通常我們需要構建第三方的定期核對系統，以第三方的角度來監控服務執行的健康程度。

定期核對系統示意圖如下：

定期核對模式

對於案例6：掉單、案例7：系統間狀態不一致通常通過定期校對模式發現問題，並通過補償模式來修復，最后完成系統間的最終一致性。

定期校對模式多應用在金融系統，金融系統由於涉及到資金安全，需要保證百分之百的准確性，所以，需要多重的一致性保證機制，包括：系統間的一致性對賬、現金對賬、賬務對賬、手續費對賬等等。

這些都屬於定期校對模式，順便說一下，金融系統與社交應用在技術上本質的區別在於社交應用在於量大，而金融系統在於數據的准確性。

到現在為止，我們看到通過查詢模式、補償模式、定期核對模式可以解決案例4到案例7的所有問題：

• 對於案例4：同步超時，如果同步超時，我們需要查詢狀態進行補償；

• 對於案例5：異步回調超時，如果遲遲沒有收到回調響應，我們也會通過查詢狀態進行補償；

• 對於案例6：掉單、案例7：系統間狀態不一致，我們通過定期核對模式可以保證系統間操作的一致性，避免掉單和狀態不一致導致問題；

5. 可靠消息模式

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

• 消息的可靠發送

消息的可靠發送可以認為是盡最大努力發送消息通知，有兩種實現方法：

第一種，發送消息之前，把消息持久到數據庫，狀態標記為待發送，然后發送消息，如果發送成功，將消息改為發送成功。定時任務定時從數據庫撈取一定時間內未發送的消息，將消息發送。

消息發送模式1

第二種，實現方式與第一種類似，不同的是持久消息的數據庫是獨立的，並不耦合在業務系統中。發送消息之前，先發送一個預消息給某一個第三方的消息管理器，消息管理器將其持久到數據庫，並標記狀態為待發送，發送成功后，標記消息為發送成功。

定時任務定時從數據庫撈取一定時間內未發送的消息，回查業務系統是否要繼續發送，根據查詢結果來確定消息的狀態。

 

消息發送模式2

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

• 消息處理器的冪等性

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

處理重復的最佳方式為保證操作的冪等性，冪等性的數學公式為：

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

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

1. 使用數據庫表的唯一鍵進行濾重，拒絕重復的請求；

2. 使用分布式表對請求進行濾重；

3. 使用狀態流轉的方向性來濾重，通常使用行級鎖來實現(后續在鎖相關的文章中詳細說明)；

4. 根據業務的特點，操作本身就是冪等的，例如：刪除一個資源、增加一個資源、獲得一個資源等；

6. 緩存一致性模型

大規模高並發系統中一個常見的核心需求就是億級的讀需求，顯然，關系型數據庫並不是解決高並發讀需求的最佳方案，互聯網的經典做法就是使用緩存抗讀需求，下面有一些使用緩存的保證一致性的最佳實踐：

1. 如果性能要求不是非常的高，盡量使用分布式緩存，而不要使用本地緩存；

2. 種緩存的時候一定種完全，如果緩存數據的一部分有效，一部分無效，寧可放棄種緩存，也不要把部分數據種入緩存；

3. 數據庫與緩存只需要保持弱一致性，而不需要強一致性，讀的順序要先緩存，后數據庫，寫的順序要先數據庫，后緩存；

這里的最佳實踐能夠解決案例8：緩存和數據庫不一致、案例9：本地緩存節點間不一致、案例10：緩存數據結構不一致的問題，對於數據存儲層、緩存與數據庫、Nosql 等的一致性是更深入的存儲一致性技術，將會在后續文章單獨介紹，這里的數據一致性主要是處理應用層與緩存、應用層與數據庫、一部分的緩存與數據庫的一致性。

3.5 專題模式

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

• 遷移開關的設計

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

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

曾經看過很多簡單的開關設計，有的開關設計在應用層次，通過一個curl語句調用，沒有權限控制，這樣的開關在服務池的每個節點都是不同步的、不一致的；還有的系統把開關配置放在中心化的配置系統、數據庫或者緩存等，處理的每個請求都通過統一的開關來判斷是否遷移等等。

這樣的開關有一個致命的缺點，服務請求在處理過程中，開關可能會變化，各個節點之間開關可能不同步、不一致，導致重復的請求可能走到新的邏輯又走了老的邏輯，如果新的邏輯和老的邏輯沒有保證冪等性，這個請求就被重復處理了，如果是金融行業的應用，可能會導致資金損失，電商系統可能會導致發貨並退款等問題。

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

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

4、總結

本文從一致性問題的實踐出發，從大規模高並發服務化系統的實踐經驗中進行總結，列舉導致不一致的具體問題，圍繞着具體問題，總結出解決不一致的方法，並且抽象成模式，供大家在開發服務化系統的過程中參考。

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