[[314974]]

對于支付寶和微信支付這樣的國民應用，海量交易帶來的系統可用性問題成了關乎國計民生的問題。本文總結了微信支付的核心訂單系統的架構實現，以及海量交易所帶來的擴容、成本、容災和灰度等問題及解決方案，最終通過系統架構多次迭代確立基于 Mysql 單機存儲引擎，業務和存儲強耦的高可用的分布式訂單系統。

本文主要講述了基于條帶構建的高可用分布式訂單存儲系統，條帶是由無狀態服務和有狀態存儲服務組成的條帶架構的基本單元，通過條帶可以實現線性擴縮容的能力；在下單時通過跳單的操作可以允許一次下單重試更換到可用的條帶，這樣可以應對少數條帶不可用帶來的下單不可用問題；同時基于條帶的架構也帶了冷熱分離、故障壓縮、差異服務、熱點均衡和灰度控制的能力。

基于條帶化的架構雖然帶來很多優點，但同時也造成業務和存儲強耦合，另外業務開發人員在開發時也需要了解整體架構不能更加專注業務邏輯。

1. 簡介

隨著移動支付的飛速發展，移動支付用戶量持續增加，移動支付已悄無聲息的融入到國民的生活并且產生重要的作用。

在支付系統中，一筆交易往往需要多個相關系統的協作完成，其中包括支付產品系統、訂單交易系統、風控系統、支付系統、賬號系統、商戶系統、賬戶系統和清結算系統等等。在一個交易系統中一筆交易是通過一筆訂單進行標識的，訂單系統需要提供創建訂單、支付訂單、查詢訂單、關閉訂單和訂單退款的能力。

訂單系統作為其它系統的依賴系統，它的可用性將直接影響整個交易系統的可用性。交易系統的可用性將直接影響用戶的交易體驗和整個品牌的口碑。

傳統的銀行都是基于大型的商業服務器和正版授權的數據庫軟件構建自己的交易系統，互聯網有別于傳統銀行，往往是采用小型廉價的商業服務器和開源的數據庫軟件構建自己的交易系統。

另外傳統銀行的交易系統是集中式的，而互聯網企業多采用分布式系統構建自己的系統，這樣對數據的一致性、災備、可用性提出更高的要求。對于大型企業或者第三方數據庫公司，它們會研發一些自己的分布式數據庫存儲，例如 OceanBase、TiDB 等。但是很多企業還是會采用開源的 mysql 作為自己的數據庫系統，一種基于 mysql 實現的易擴展、高可用支持海量存儲的訂單交易系統對于是一個企業也是一種很好的方案選擇。

本文會討論一種基于 mysql 構建的海量訂單交易系統，高可用和易擴展作為整個系統兩個主要特征。為達到整個系統的高可用，可用性主要包含三種改進：

1. 通過使用 HaProxy 來進行數據庫的快速切換解決存儲不可用。
2. 通過條帶化進行物理隔離防止單存儲故障導致的不可用擴散。
3. 在系統頂層通過跳單來降低邏輯服務和存儲不可用帶來的影響。

為了解決系統的容量，主要通過條帶化單元的水平擴展來擴充整個系統的容量，同時條帶化的結構可以很好的解決數據冷熱分離的問題。在系統的垂直方向整個系統主要分為代理層、邏輯服務層和存儲層；系統在水平方向是由眾多物理隔離的條帶組成的，一個條帶包含了對應的邏輯服務和存儲，同時條帶也是水平擴展的基本單位。

本文主要先描述整個系統的整體架構，接下來會描述傳統架構中存在問題并提出對應的解決方案，然后會討論整個架構對可用性和易擴展的實現細節，以及探討結合通用組件來快速開發整個系統。

2.業界現狀

交易系統的可用性主要分為無狀態服務的可用性和有狀態存儲的可用性，無狀態服務的可用性相比更容易解決，而有狀態存儲服務的可用性則成為整個交易系統的核心瓶頸。

為了解決有狀態存儲服務的可用性，業界也研發了很多的金融級分布式系統存儲方案。例如 Google 的 Bigtable、MegaStore 和 Spanner；Facebook 的 MyRocks；阿里的OceanBase 和 XEngine；騰訊的TDSQL；PingCap 的 TiDB。

這里的存儲主要分為兩個大的方向：基于關系型數據庫構造建分布式關系型存儲系統和基于NoSql 構建的分布式存儲系統。分布式關系型存儲系統如 OceanBase、MyRocks 和TDSQL 等；分布式 NoSql 存儲系統如：Spanner、X-Engine 和 TiDB 等。

近代互聯網時代，Google 的存儲技術是整個互 聯網行業的技術標桿，其發表的 GFS、Bigtable 和 Spanner 等一些列技術成果，奠定了近幾〸年的存儲 發展方向。其存儲系統也經歷 Bigtable、MegaStore 到 Spanner 的演化，并且 Spanner 是第一個把數據 分布在全球范圍內的系統，并且支持外部一致性的 分布式事務。不管是在存儲的理論研究和技術實現， Google 都是這個時代的拓荒者。

Facebook 作為一家技術實力同樣強勁的互聯網廠商，MyRocks 是 Facebook 開發的一款基于 RocksDB 的開源 MySQL 存儲引擎，并且已經穩定支撐 Facebook 的海量業務，并作為 Facebook 的 mysql 的主分支。

阿里作為中國電商的代表性公司每天都會面臨海量的交易，雖然海量交易代表業務的快速增長，但也會對整個交易系統的可用性、擴展性、一致性、性能等提出了更高的要求。在中國移動支付整體快速 增長以及阿里的雙 11 活動的推動下，阿里的交易系統也在一次一次的交易海嘯中快速成長起來。阿里整個集團不僅完成了去 IOE，也完成存儲的自研，以及到打磨成為業界頂尖的互聯網分布式金融存儲產品。

阿里目前分布式存儲產品有完全自主研發的金融級分布式關系數據庫 OceanBase 和阿里數據庫產品事業部自研的OLTP 數據庫存儲引擎 X-Engine 等。OceanBase 作為完全自主研發的金融級分布式關系數據庫，支持強一致、高可用、高擴展、高性能、高度兼容和低成本等特性。OceanBase 是基于單機關系型數據庫，根據數據特性分為基線數據和更新 數據構建的一種類 Bigtable 的分布式存儲系統；而X-Engine 定位于為阿里云上的公有云客戶提供低成 本高性能的數據庫服務。X-Engine 采用了基于 LSM Tree 的分布式架構，通過優化和借助硬件加速從而提供更低成本下的高性能的讀寫的 OLTP 存儲解決方案。

伴隨著微信支付的快速發展，以及用戶持續增長和交易量的增長。騰訊的財付通作為支付底層的服務提供者有自研的金融級分布式數據庫 TDSQL， 不僅支撐微信紅包業務，也在騰訊云為更多的企業用戶提供分布式數據庫解決方案。

由于歷史原因，微信支付的核心訂單系統沒有將所有的可用性轉移到分布式存儲系統，而是走出了一條基于單機關系型數據庫，業務和存儲強耦的高可用訂單系統方案。上面業務和存儲強耦的訂單存儲方案也正是本文討論的方案，雖然沒有采用一些分布式存儲方案，但它可能更加適合互聯網的中小型企業構建自主的高可用訂單存儲系統。

除了阿里和騰訊，PingCap 是一家專注開源的新型分布式數據庫公司，其研發的分布式關系型數據庫 TiDB 項目具備分布式強一致性事務、在線彈性水平擴展、故障自恢復的高可用、跨數據中心多活等核心特性，并提供 HTAP 的一站式解決方案。雖 然 TiDB 沒有海量的交易，但作為一家專注存儲自研的公司，代表了中國自研存儲的努力和崛起。

3. 系統架構

通過上節的描述，訂單交易系統的可用性更加聚焦在有狀態存儲服務的可用性，一些高可用、強一致的分布式存儲方案可以解決問題。也正如前面提到，微信支付的核心訂單交易系統沒有采用高可用、 強一致分布式存儲系統，而是走出了一條基于單機存儲，存儲和業務強耦的一種訂單可用方案。這里的方案也可以給更多中小企業提供一種自主構建可用訂單系統的解決方案。

圖 1: 訂單系統架構概覽

如圖 1 所示的整個系統的簡要結構，整個系統是由代理層和若干的條帶共同組成的，每個條帶內包含無狀態的邏輯服務和有狀態的存儲。整個系統在垂直方向分為三層：代理層、邏輯服務層和存儲層。

其中，代理層主要功能包含訂單路由和跳單、邏輯服務層聚合業務特性、數據的增刪改查和單機事務等、 存儲層負責數據的存儲；在水平方向是由多個可動態擴縮的條帶組成。條帶是系統構成的基本單元，可以通過條帶的邏輯聚合實現讀寫分離、冷熱分離、差異化服務、和提升版本發布質量等。

整個系統的容量是通過動態的添加和刪除條帶來達到容量的動態擴縮容；系統的可用性通過對存儲不可用問題提出針對性的解決 方案和優化來提升整個系統的可用性。系統中各條帶是物理隔離的，如果存在條單不可用，在代理層可以通過跳過不可用條帶保證訂單的創建和訂單支付有很高的可用性。條單不可用還是會影響該條帶內的訂單查詢和訂單退款，實際中訂單查詢和訂單退款相比訂單創建和訂單支付可以 更加柔性和更好的容忍度。

通過上面的描述整個系統通過無狀態的代理層和跳單共同保證系統的創建 訂單和支付訂單有很高的可用性。條帶內的無狀態邏輯服務采用三機部署，這樣一個條帶內所有邏輯服務同時不可用的概率將會極低；條帶內的存儲也是三機部署，一主兩備可以保證集群的數據的災備 和可用性，集群內的主備之間采用半同步保證數據 的最終一致（可以采用基于 Paxos 改造 binlog 的強 一致數據存儲，例如 PhxSql）。

訂單號

基于業務和單機存儲強耦的訂單存儲方案，本質是將存儲層的分布式方案上移到業務層進行實現。對于通用分布式存儲系統中主鍵的概念，在分布式訂單存儲系統中可以天然的使用訂單號來代替。存 儲的分布式一般采用基于 Range 或者 Hash 的分片 方案，一般先生成好一個全局唯一的主鍵，然后根據主鍵決定好數組所在的分片，我們稱之為分片先綁定。

文章中提出的方案是，通過隨機在所有可用的分片中隨機選取一個作為當前單號所在的分片，然后 將分片的編號記錄在到訂單號中并進行訂單的創建， 我們稱這種方案為分片遲綁定。

訂單號 = (版本號，條帶編號，時間，訂單編號)

訂單號主要由版本號、條帶編號、時間信息和訂 單編號組成。其中版本號用于控制訂單號的版本升級；條帶編號存儲了數據所在的分片，根據條帶編號進行路由；時間信息用于記錄單號的生成時間，根據時間和訪問頻率決定數據冷、熱和溫的程度；訂單編號用戶保證訂單號在全局的唯一性，根據我們的條帶方案可以降級到 (條帶編號、時間信息、訂單編 號) 唯一即可，這樣訂單編號只需要在一個條帶內唯一即可。

同時會降低對全局唯一序號生成器的依賴，這樣每個條帶都可以使用條帶內的序號生成器進一步提高整個系統的可用性。

路由信息表

路由信息表維護了每個條帶的路由信息，每條 路由信息維護了每個條帶的編號、邏輯服務的地址和端口、存儲服務的地址和端口、條帶是否可用、條帶的冷、熱、溫等情況、以及所屬分區。如表 1 所示，條帶編號是一個增長的 ID，沒新增一個條帶就自增的為條帶分配一個新的 ID；分區是條帶的邏輯聚合概念，我們可以根據聚合的分區 構建重點商戶分區、普通商戶分區、預發布分區和 冷分區，從而提供差異服務、冷熱隔離等能力。

每個條帶都有自己的對應的邏輯服務和存儲服務，通過配置的地址我們可以在邏輯上形成邏輯隔離的條帶， 如果機器也不混合部署和重復使用，條帶在物理上也是隔離的。

可用狀態表明當前條帶是否可用；冷熱狀態表明 DB 中數據的時間特性，我們粗略分為冷、 熱和溫三類。

代理服務

代理服務作為整個訂單系統的入口，需要提供下單、支付、查單和關單等接口。下單屬于創建訂單，支付和關單屬于更新訂單，查單屬于查詢訂單。下單的時候，代理服務需要正確和均勻的選擇條帶， 并在某些條帶不可用的情況下進行跳單保證有限跳單次數內可以找到可用的條帶。

對于支付、查單和關單需要正確解析單號中的條帶信息，進行正確的路由。由于代理服務是無狀態的邏輯服務，為了提高代理服務的可用性，通過水平部署多個代理服務實例可以解決。假定同一時刻只有有限個代理服務實例同時不可用，業務方在一次請求中進行失敗重試便可將請求路由到其它正常的代理服務，從而保證代理服務具有較高的可用性。

條帶

傳統的基于 Mysql 的系統架構中為了擴充系統的容量一般會采用水平的分庫分表策略，通過對主鍵進行哈希將數據分布在不同的機器上從而提升系統的容量。例如實際系統假定有 8 組 DB，可以將主鍵按 8 求余進行存儲，但是這樣的方案存在兩個缺點：冷熱分離和翻倍擴容。

在訂單系統中，訂單記錄在一段時間之后很少會進行訂單查詢和訂單退款，所以具有明顯的冷熱特性。為了更好的利用機器資源，一般會將 x 冷數據進行分離并存儲到低成本的機器進行存儲和訪問。對于上面的 Sharding 模式，我們需要按天建表進行冷數據分離。

對于上面的 Sharding 模式，擴容的時候會選擇將 DB 的數量增加到 16 組，需要將擴容的數據拷貝一份到新的機 器上，然后根據 16 進行請求重新計算路由，上面的 過程被稱作翻倍擴容。上面的翻倍擴容對于實時訂單系統是無法忍受的，我們更希望對系統的容量進行線性擴縮容，同時不需要影響已經生成的訂單。為了更好的支持冷熱數據分離和線性擴容，我們提出基于條帶的動態擴容架構。一個條帶作為存儲的基本單元，其中包含了無狀態的邏輯服務和有狀態的存儲，通過增加和減少條帶的數量進行線性的擴縮容。

事務

對于交易系統很多場景下會面臨需要操作多個資源同時成功或者失敗，如轉賬、多個單據狀態的同時扭轉等。在單機關系型數據中我們會使用單機事務來進行解決，同樣對于分布式系統需要系統具 備分布式事務的能力。

由于分布式事務的實現復雜、性能低下等特點，在業務系統中往往會將分布式事務轉化為單機事務進行解決，或者將分布式事務根據核心程度劃分為主事務和次事務，通過將次事務通過異步組件進行異步補償完成整個事務。

另外，由于交易系統一筆交易往往會操作多個相關的交易單據，我們可以將相關的多個單據部署在同一個分片， 這樣就可以轉化為單機事務進行解決。通過上面的分析，我們將系統的事務轉為條帶內的單機事務和跨條帶的異常補償事務，這樣各個條帶就可以充分解耦做到物理和邏輯的隔離。

跳單

在進行下單前，系統中存在一個條帶健康度的檢查服務，它會實時模式真實訂單探測和收集條帶的健康度、耗時等情況。

另外，在某些情況下需要手動屏蔽不可用或者可用的條帶 (如增加或減少跳單， 冷熱分離等場景)。在下單的時候，代理服務結合條帶健康度、黑名單等信息，并在可用的條帶內根據短期內每個條帶的請求量選擇一個可用的條帶，然后根據訂單號到對應的條帶生成訂單。

如果第一次成功，則直接返回訂單號；如果沒有成功，此時可以屏蔽掉當前的條帶，進一步在剩余的可用條帶內選擇一個可用的條帶，直到重試到達上限。我們稱上面不斷重試尋找可用條帶的過程為跳單，跳單主要是通過有限次重試跳過不可用條帶而保證下單操作的高可用。

健康度檢查服務

條帶健康度檢查服務是所有條帶的觀察者，它通過周期性模擬真實的交易探測每個條帶的可用性和耗時等情況。

根據健康度檢查服務提供的條帶可用和耗時信息可以在下單的時候以更高的概率選到可用的條帶而有效的屏蔽掉不可用的條帶。條帶的是否可用也需要提供好的評價策略和兜底方案，防止網絡持續抖動時造成過探測導致所有條帶的不可 用。

4.訂單流程

對于訂單系統，作為支付系統的核心流程，往往需要提供創建訂單、更新訂單和查詢訂單的能力。對于訂單的復雜查詢，為了不影響實時交易鏈路的可用性，會采用將備機的數據通過可靠的異步組件同步到非實時的數據庫進行復雜查詢或者統計等操作。

下面會介紹基于上面的條帶化架構的創建訂單、 修改訂單和查詢訂單的流程：

創建訂單

如表 2 所示的流程，主要由入口的路由服務完成訂單號的生成以及條帶不可用時的跳單操作。

這樣可以保證創建訂單的一個高可用，即使存在若干不可用的條帶整個系統還是可以進行下單操作。

更新訂單

如表 3 所示的流程，當業務在下單流程獲取訂單號之后，業務方攜帶單號，代理服務解析單號中的條帶編號，就可以保證請求在對應的條帶內進行請求， 并正確找到對應 DB 的信息。

查詢訂單

對于訂單查詢，我們可以將查詢分為實時的讀請求和非實時的讀請求。實時的讀請求讀取主庫的數據，主要為核心鏈路提供準確的數據查詢；非實時的讀請求讀取備庫的數據，主要為核心鏈路提供降級的備機讀取以及非實時鏈路的讀取。

如表 4 所示 的流程，當業務在下單流程獲取訂單號之后，業務方攜帶單號，代理服務解析單號中的條帶編號，就可以保證請求在對應的條帶內進行請求，并正確找到對應 DB 的信息。

5. 架構特性

線性擴容

對于海量交易的系統，線性擴容成為一個重要的特性。線性擴容給整個系統提供了更多的靈活性以應對特定時期的交易洪峰，并且能通過簡單的擴縮容取得交易處理能力和成本的平衡。

對于業務可能快速持續增長的系統，線性擴容能力可以應對不必要的系統重新設計和重構。

故障壓縮

由于各條帶是邏輯和物理隔離的，不管是由于條帶內 DB 導致的故障或者灰度發布導致的故障， 相應的故障只會壓縮在該條帶內，不會擴散導致整個系統的雪崩。

通過統計我們可以簡單估算每個條單不可用的概率，然后估算整個系統不可用的概率。

差異服務

根據我們抽象的條帶概念，我們可以再聚合某些條帶為一個分區，某些商戶的請求只可以落在某些分區的條帶內。這樣不同的分區提供不同的機器、帶寬等，可以實現對重點商戶和非重點商戶的差異化服務。

冷熱分離

當系統某些條帶的容量到達預警值，或者其中的數據已經超過某個冷卻閾值。我們可以將條帶變為只讀和可更新，但不能再進行數據的寫入。

等到數據的訪問量下降到某個閾值后，可以將條帶內的全量數據停寫后拷貝到冷庫，然后修改條帶路由信息中的存儲服務地址為冷數據所在的新機器的地址。

然后刪除舊機器上的數據并新增一個空的條帶，這樣就可以簡單的完成冷熱數據分離，同時上面的過程可以實現完全自動化。

灰度控制

在互聯網系統的可用性問題中，統計發現很多版本的問題可以通過合理的灰度提早發現和解決。基于條帶的架構可以輕松的構建預發布環境，預發布環境通過后可以控制新版本先對某些生產條帶進行灰度發布，然后逐步灰度到所有的條帶。

同時還可以通過控制某些條帶的請求量從而可以做到更細粒度的灰度。

熱點均衡

在選擇分區的時候，可以統計近期每個條帶創建的訂單數作出一個合理的條帶選擇，從而達到最大程度的數據均衡，避免傳統分片模式下數據傾斜的問題。

6. 備份、容災和恢復

備份

為了應對機架級不可用、機房級不可用和城市級不可用，需要通過數據備份進行容災。可以根據業務的容災選擇合理的容災級別，通常業務會選擇一主兩備的三機備份策略。

數據一致性

如果采用 Mysql 作為條帶內的存儲引擎，Mysql 支持同步復制、異步復制、半同步復制、增強半同步復制和 MGR(MySQL Group Replication)。通常我們很少采用同步和異步復制，在 Mysql5.7 增強半同步之前 DBA 多會采用半同步復制，但如果主機宕機 切換到備機會出現一定的數據不一致。

為了解決半同步帶來的問題，Mysql5.7 之后推出了增強半同步。但是 MGR 是基于 Paxos 的強一致復制方案，但是 MGR 業界的互聯網公司卻很少有公司采用。

容災

我們假定所有的機房都在一個城市內的不同機房，為了應對城市內的機房級不可用，我們需要將三份數據分布在同城的三個不同機房內，同時保證每個機房內有相同的主機和備機的數量，對機房級進行負載均衡。

當出現機房級以及機房級以下的不可用，可以快速的進行主機切換保證業務的可用性， 如果出現整個機房的不可用最多會損失 1/3 的交易量。但是對于條帶化的架構，我們可以快速調整條帶路由信息表將不可用的條帶進行屏蔽，這樣只會有一個短暫的不可用。

7. 架構缺點及改進

對于分布式事務不太友好。

其實可以將更多的能力下降到存儲進行解決， 這樣對業務人員的架構能力提出較高的要求。

如果現行系統進行改造的成本過高。

8. 總結

上文首先描述了基于單機 Mysql 構建的業務和存儲強耦合的高可用海量分布式訂單系統，基于抽象的條帶概念使得整個系統架構天然具備了一些線性擴容、故障壓縮、冷熱分離、灰度控制、差異服務和熱點均衡等能力。雖然不同于支付寶通過強一致分布式存儲系統來保證分布式存儲服務的高可用， 但這種構建于單機 Mysql 的架構更加適合沒有獨立研發分布式存儲的中小企業。從目前業界存儲演進的方向來看，強一致的分布式關系型數據存儲系統還是業界努力的方向。