[[314974]]

對(duì)于支付寶和微信支付這樣的國(guó)民應(yīng)用，海量交易帶來(lái)的系統(tǒng)可用性問(wèn)題成了關(guān)乎國(guó)計(jì)民生的問(wèn)題。本文總結(jié)了微信支付的核心訂單系統(tǒng)的架構(gòu)實(shí)現(xiàn)，以及海量交易所帶來(lái)的擴(kuò)容、成本、容災(zāi)和灰度等問(wèn)題及解決方案，最終通過(guò)系統(tǒng)架構(gòu)多次迭代確立基于 Mysql 單機(jī)存儲(chǔ)引擎，業(yè)務(wù)和存儲(chǔ)強(qiáng)耦的高可用的分布式訂單系統(tǒng)。

本文主要講述了基于條帶構(gòu)建的高可用分布式訂單存儲(chǔ)系統(tǒng)，條帶是由無(wú)狀態(tài)服務(wù)和有狀態(tài)存儲(chǔ)服務(wù)組成的條帶架構(gòu)的基本單元，通過(guò)條帶可以實(shí)現(xiàn)線(xiàn)性擴(kuò)縮容的能力；在下單時(shí)通過(guò)跳單的操作可以允許一次下單重試更換到可用的條帶，這樣可以應(yīng)對(duì)少數(shù)條帶不可用帶來(lái)的下單不可用問(wèn)題；同時(shí)基于條帶的架構(gòu)也帶了冷熱分離、故障壓縮、差異服務(wù)、熱點(diǎn)均衡和灰度控制的能力。

基于條帶化的架構(gòu)雖然帶來(lái)很多優(yōu)點(diǎn)，但同時(shí)也造成業(yè)務(wù)和存儲(chǔ)強(qiáng)耦合，另外業(yè)務(wù)開(kāi)發(fā)人員在開(kāi)發(fā)時(shí)也需要了解整體架構(gòu)不能更加專(zhuān)注業(yè)務(wù)邏輯。

1. 簡(jiǎn)介

隨著移動(dòng)支付的飛速發(fā)展，移動(dòng)支付用戶(hù)量持續(xù)增加，移動(dòng)支付已悄無(wú)聲息的融入到國(guó)民的生活并且產(chǎn)生重要的作用。

在支付系統(tǒng)中，一筆交易往往需要多個(gè)相關(guān)系統(tǒng)的協(xié)作完成，其中包括支付產(chǎn)品系統(tǒng)、訂單交易系統(tǒng)、風(fēng)控系統(tǒng)、支付系統(tǒng)、賬號(hào)系統(tǒng)、商戶(hù)系統(tǒng)、賬戶(hù)系統(tǒng)和清結(jié)算系統(tǒng)等等。在一個(gè)交易系統(tǒng)中一筆交易是通過(guò)一筆訂單進(jìn)行標(biāo)識(shí)的，訂單系統(tǒng)需要提供創(chuàng)建訂單、支付訂單、查詢(xún)訂單、關(guān)閉訂單和訂單退款的能力。

訂單系統(tǒng)作為其它系統(tǒng)的依賴(lài)系統(tǒng)，它的可用性將直接影響整個(gè)交易系統(tǒng)的可用性。交易系統(tǒng)的可用性將直接影響用戶(hù)的交易體驗(yàn)和整個(gè)品牌的口碑。

傳統(tǒng)的銀行都是基于大型的商業(yè)服務(wù)器和正版授權(quán)的數(shù)據(jù)庫(kù)軟件構(gòu)建自己的交易系統(tǒng)，互聯(lián)網(wǎng)有別于傳統(tǒng)銀行，往往是采用小型廉價(jià)的商業(yè)服務(wù)器和開(kāi)源的數(shù)據(jù)庫(kù)軟件構(gòu)建自己的交易系統(tǒng)。

另外傳統(tǒng)銀行的交易系統(tǒng)是集中式的，而互聯(lián)網(wǎng)企業(yè)多采用分布式系統(tǒng)構(gòu)建自己的系統(tǒng)，這樣對(duì)數(shù)據(jù)的一致性、災(zāi)備、可用性提出更高的要求。對(duì)于大型企業(yè)或者第三方數(shù)據(jù)庫(kù)公司，它們會(huì)研發(fā)一些自己的分布式數(shù)據(jù)庫(kù)存儲(chǔ)，例如 OceanBase、TiDB 等。但是很多企業(yè)還是會(huì)采用開(kāi)源的 mysql 作為自己的數(shù)據(jù)庫(kù)系統(tǒng)，一種基于 mysql 實(shí)現(xiàn)的易擴(kuò)展、高可用支持海量存儲(chǔ)的訂單交易系統(tǒng)對(duì)于是一個(gè)企業(yè)也是一種很好的方案選擇。

本文會(huì)討論一種基于 mysql 構(gòu)建的海量訂單交易系統(tǒng)，高可用和易擴(kuò)展作為整個(gè)系統(tǒng)兩個(gè)主要特征。為達(dá)到整個(gè)系統(tǒng)的高可用，可用性主要包含三種改進(jìn)：

1. 通過(guò)使用 HaProxy 來(lái)進(jìn)行數(shù)據(jù)庫(kù)的快速切換解決存儲(chǔ)不可用。
2. 通過(guò)條帶化進(jìn)行物理隔離防止單存儲(chǔ)故障導(dǎo)致的不可用擴(kuò)散。
3. 在系統(tǒng)頂層通過(guò)跳單來(lái)降低邏輯服務(wù)和存儲(chǔ)不可用帶來(lái)的影響。

為了解決系統(tǒng)的容量，主要通過(guò)條帶化單元的水平擴(kuò)展來(lái)擴(kuò)充整個(gè)系統(tǒng)的容量，同時(shí)條帶化的結(jié)構(gòu)可以很好的解決數(shù)據(jù)冷熱分離的問(wèn)題。在系統(tǒng)的垂直方向整個(gè)系統(tǒng)主要分為代理層、邏輯服務(wù)層和存儲(chǔ)層；系統(tǒng)在水平方向是由眾多物理隔離的條帶組成的，一個(gè)條帶包含了對(duì)應(yīng)的邏輯服務(wù)和存儲(chǔ)，同時(shí)條帶也是水平擴(kuò)展的基本單位。

本文主要先描述整個(gè)系統(tǒng)的整體架構(gòu)，接下來(lái)會(huì)描述傳統(tǒng)架構(gòu)中存在問(wèn)題并提出對(duì)應(yīng)的解決方案，然后會(huì)討論整個(gè)架構(gòu)對(duì)可用性和易擴(kuò)展的實(shí)現(xiàn)細(xì)節(jié)，以及探討結(jié)合通用組件來(lái)快速開(kāi)發(fā)整個(gè)系統(tǒng)。

2.業(yè)界現(xiàn)狀

交易系統(tǒng)的可用性主要分為無(wú)狀態(tài)服務(wù)的可用性和有狀態(tài)存儲(chǔ)的可用性，無(wú)狀態(tài)服務(wù)的可用性相比更容易解決，而有狀態(tài)存儲(chǔ)服務(wù)的可用性則成為整個(gè)交易系統(tǒng)的核心瓶頸。

為了解決有狀態(tài)存儲(chǔ)服務(wù)的可用性，業(yè)界也研發(fā)了很多的金融級(jí)分布式系統(tǒng)存儲(chǔ)方案。例如 Google 的 Bigtable、MegaStore 和 Spanner；Facebook 的 MyRocks；阿里的OceanBase 和 XEngine；騰訊的TDSQL；PingCap 的 TiDB。

這里的存儲(chǔ)主要分為兩個(gè)大的方向：基于關(guān)系型數(shù)據(jù)庫(kù)構(gòu)造建分布式關(guān)系型存儲(chǔ)系統(tǒng)和基于NoSql 構(gòu)建的分布式存儲(chǔ)系統(tǒng)。分布式關(guān)系型存儲(chǔ)系統(tǒng)如 OceanBase、MyRocks 和TDSQL 等；分布式 NoSql 存儲(chǔ)系統(tǒng)如：Spanner、X-Engine 和 TiDB 等。

近代互聯(lián)網(wǎng)時(shí)代，Google 的存儲(chǔ)技術(shù)是整個(gè)互 聯(lián)網(wǎng)行業(yè)的技術(shù)標(biāo)桿，其發(fā)表的 GFS、Bigtable 和 Spanner 等一些列技術(shù)成果，奠定了近幾〸年的存儲(chǔ) 發(fā)展方向。其存儲(chǔ)系統(tǒng)也經(jīng)歷 Bigtable、MegaStore 到 Spanner 的演化，并且 Spanner 是第一個(gè)把數(shù)據(jù) 分布在全球范圍內(nèi)的系統(tǒng)，并且支持外部一致性的 分布式事務(wù)。不管是在存儲(chǔ)的理論研究和技術(shù)實(shí)現(xiàn)， Google 都是這個(gè)時(shí)代的拓荒者。

Facebook 作為一家技術(shù)實(shí)力同樣強(qiáng)勁的互聯(lián)網(wǎng)廠商，MyRocks 是 Facebook 開(kāi)發(fā)的一款基于 RocksDB 的開(kāi)源 MySQL 存儲(chǔ)引擎，并且已經(jīng)穩(wěn)定支撐 Facebook 的海量業(yè)務(wù)，并作為 Facebook 的 mysql 的主分支。

阿里作為中國(guó)電商的代表性公司每天都會(huì)面臨海量的交易，雖然海量交易代表業(yè)務(wù)的快速增長(zhǎng)，但也會(huì)對(duì)整個(gè)交易系統(tǒng)的可用性、擴(kuò)展性、一致性、性能等提出了更高的要求。在中國(guó)移動(dòng)支付整體快速 增長(zhǎng)以及阿里的雙 11 活動(dòng)的推動(dòng)下，阿里的交易系統(tǒng)也在一次一次的交易海嘯中快速成長(zhǎng)起來(lái)。阿里整個(gè)集團(tuán)不僅完成了去 IOE，也完成存儲(chǔ)的自研，以及到打磨成為業(yè)界頂尖的互聯(lián)網(wǎng)分布式金融存儲(chǔ)產(chǎn)品。

阿里目前分布式存儲(chǔ)產(chǎn)品有完全自主研發(fā)的金融級(jí)分布式關(guān)系數(shù)據(jù)庫(kù) OceanBase 和阿里數(shù)據(jù)庫(kù)產(chǎn)品事業(yè)部自研的OLTP 數(shù)據(jù)庫(kù)存儲(chǔ)引擎 X-Engine 等。OceanBase 作為完全自主研發(fā)的金融級(jí)分布式關(guān)系數(shù)據(jù)庫(kù)，支持強(qiáng)一致、高可用、高擴(kuò)展、高性能、高度兼容和低成本等特性。OceanBase 是基于單機(jī)關(guān)系型數(shù)據(jù)庫(kù)，根據(jù)數(shù)據(jù)特性分為基線(xiàn)數(shù)據(jù)和更新 數(shù)據(jù)構(gòu)建的一種類(lèi) Bigtable 的分布式存儲(chǔ)系統(tǒng)；而X-Engine 定位于為阿里云上的公有云客戶(hù)提供低成 本高性能的數(shù)據(jù)庫(kù)服務(wù)。X-Engine 采用了基于 LSM Tree 的分布式架構(gòu)，通過(guò)優(yōu)化和借助硬件加速?gòu)亩峁└统杀鞠碌母咝阅艿淖x寫(xiě)的 OLTP 存儲(chǔ)解決方案。

伴隨著微信支付的快速發(fā)展，以及用戶(hù)持續(xù)增長(zhǎng)和交易量的增長(zhǎng)。騰訊的財(cái)付通作為支付底層的服務(wù)提供者有自研的金融級(jí)分布式數(shù)據(jù)庫(kù) TDSQL， 不僅支撐微信紅包業(yè)務(wù)，也在騰訊云為更多的企業(yè)用戶(hù)提供分布式數(shù)據(jù)庫(kù)解決方案。

由于歷史原因，微信支付的核心訂單系統(tǒng)沒(méi)有將所有的可用性轉(zhuǎn)移到分布式存儲(chǔ)系統(tǒng)，而是走出了一條基于單機(jī)關(guān)系型數(shù)據(jù)庫(kù)，業(yè)務(wù)和存儲(chǔ)強(qiáng)耦的高可用訂單系統(tǒng)方案。上面業(yè)務(wù)和存儲(chǔ)強(qiáng)耦的訂單存儲(chǔ)方案也正是本文討論的方案，雖然沒(méi)有采用一些分布式存儲(chǔ)方案，但它可能更加適合互聯(lián)網(wǎng)的中小型企業(yè)構(gòu)建自主的高可用訂單存儲(chǔ)系統(tǒng)。

除了阿里和騰訊，PingCap 是一家專(zhuān)注開(kāi)源的新型分布式數(shù)據(jù)庫(kù)公司，其研發(fā)的分布式關(guān)系型數(shù)據(jù)庫(kù) TiDB 項(xiàng)目具備分布式強(qiáng)一致性事務(wù)、在線(xiàn)彈性水平擴(kuò)展、故障自恢復(fù)的高可用、跨數(shù)據(jù)中心多活等核心特性，并提供 HTAP 的一站式解決方案。雖 然 TiDB 沒(méi)有海量的交易，但作為一家專(zhuān)注存儲(chǔ)自研的公司，代表了中國(guó)自研存儲(chǔ)的努力和崛起。

3. 系統(tǒng)架構(gòu)

通過(guò)上節(jié)的描述，訂單交易系統(tǒng)的可用性更加聚焦在有狀態(tài)存儲(chǔ)服務(wù)的可用性，一些高可用、強(qiáng)一致的分布式存儲(chǔ)方案可以解決問(wèn)題。也正如前面提到，微信支付的核心訂單交易系統(tǒng)沒(méi)有采用高可用、 強(qiáng)一致分布式存儲(chǔ)系統(tǒng)，而是走出了一條基于單機(jī)存儲(chǔ)，存儲(chǔ)和業(yè)務(wù)強(qiáng)耦的一種訂單可用方案。這里的方案也可以給更多中小企業(yè)提供一種自主構(gòu)建可用訂單系統(tǒng)的解決方案。

圖 1: 訂單系統(tǒng)架構(gòu)概覽

如圖 1 所示的整個(gè)系統(tǒng)的簡(jiǎn)要結(jié)構(gòu)，整個(gè)系統(tǒng)是由代理層和若干的條帶共同組成的，每個(gè)條帶內(nèi)包含無(wú)狀態(tài)的邏輯服務(wù)和有狀態(tài)的存儲(chǔ)。整個(gè)系統(tǒng)在垂直方向分為三層：代理層、邏輯服務(wù)層和存儲(chǔ)層。

其中，代理層主要功能包含訂單路由和跳單、邏輯服務(wù)層聚合業(yè)務(wù)特性、數(shù)據(jù)的增刪改查和單機(jī)事務(wù)等、 存儲(chǔ)層負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)；在水平方向是由多個(gè)可動(dòng)態(tài)擴(kuò)縮的條帶組成。條帶是系統(tǒng)構(gòu)成的基本單元，可以通過(guò)條帶的邏輯聚合實(shí)現(xiàn)讀寫(xiě)分離、冷熱分離、差異化服務(wù)、和提升版本發(fā)布質(zhì)量等。

整個(gè)系統(tǒng)的容量是通過(guò)動(dòng)態(tài)的添加和刪除條帶來(lái)達(dá)到容量的動(dòng)態(tài)擴(kuò)縮容；系統(tǒng)的可用性通過(guò)對(duì)存儲(chǔ)不可用問(wèn)題提出針對(duì)性的解決 方案和優(yōu)化來(lái)提升整個(gè)系統(tǒng)的可用性。系統(tǒng)中各條帶是物理隔離的，如果存在條單不可用，在代理層可以通過(guò)跳過(guò)不可用條帶保證訂單的創(chuàng)建和訂單支付有很高的可用性。條單不可用還是會(huì)影響該條帶內(nèi)的訂單查詢(xún)和訂單退款，實(shí)際中訂單查詢(xún)和訂單退款相比訂單創(chuàng)建和訂單支付可以 更加柔性和更好的容忍度。

通過(guò)上面的描述整個(gè)系統(tǒng)通過(guò)無(wú)狀態(tài)的代理層和跳單共同保證系統(tǒng)的創(chuàng)建 訂單和支付訂單有很高的可用性。條帶內(nèi)的無(wú)狀態(tài)邏輯服務(wù)采用三機(jī)部署，這樣一個(gè)條帶內(nèi)所有邏輯服務(wù)同時(shí)不可用的概率將會(huì)極低；條帶內(nèi)的存儲(chǔ)也是三機(jī)部署，一主兩備可以保證集群的數(shù)據(jù)的災(zāi)備 和可用性，集群內(nèi)的主備之間采用半同步保證數(shù)據(jù) 的最終一致（可以采用基于 Paxos 改造 binlog 的強(qiáng) 一致數(shù)據(jù)存儲(chǔ)，例如 PhxSql）。

訂單號(hào)

基于業(yè)務(wù)和單機(jī)存儲(chǔ)強(qiáng)耦的訂單存儲(chǔ)方案，本質(zhì)是將存儲(chǔ)層的分布式方案上移到業(yè)務(wù)層進(jìn)行實(shí)現(xiàn)。對(duì)于通用分布式存儲(chǔ)系統(tǒng)中主鍵的概念，在分布式訂單存儲(chǔ)系統(tǒng)中可以天然的使用訂單號(hào)來(lái)代替。存 儲(chǔ)的分布式一般采用基于 Range 或者 Hash 的分片 方案，一般先生成好一個(gè)全局唯一的主鍵，然后根據(jù)主鍵決定好數(shù)組所在的分片，我們稱(chēng)之為分片先綁定。

文章中提出的方案是，通過(guò)隨機(jī)在所有可用的分片中隨機(jī)選取一個(gè)作為當(dāng)前單號(hào)所在的分片，然后 將分片的編號(hào)記錄在到訂單號(hào)中并進(jìn)行訂單的創(chuàng)建， 我們稱(chēng)這種方案為分片遲綁定。

訂單號(hào) = (版本號(hào)，條帶編號(hào)，時(shí)間，訂單編號(hào))

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

同時(shí)會(huì)降低對(duì)全局唯一序號(hào)生成器的依賴(lài)，這樣每個(gè)條帶都可以使用條帶內(nèi)的序號(hào)生成器進(jìn)一步提高整個(gè)系統(tǒng)的可用性。

路由信息表

路由信息表維護(hù)了每個(gè)條帶的路由信息，每條 路由信息維護(hù)了每個(gè)條帶的編號(hào)、邏輯服務(wù)的地址和端口、存儲(chǔ)服務(wù)的地址和端口、條帶是否可用、條帶的冷、熱、溫等情況、以及所屬分區(qū)。如表 1 所示，條帶編號(hào)是一個(gè)增長(zhǎng)的 ID，沒(méi)新增一個(gè)條帶就自增的為條帶分配一個(gè)新的 ID；分區(qū)是條帶的邏輯聚合概念，我們可以根據(jù)聚合的分區(qū) 構(gòu)建重點(diǎn)商戶(hù)分區(qū)、普通商戶(hù)分區(qū)、預(yù)發(fā)布分區(qū)和 冷分區(qū)，從而提供差異服務(wù)、冷熱隔離等能力。

每個(gè)條帶都有自己的對(duì)應(yīng)的邏輯服務(wù)和存儲(chǔ)服務(wù)，通過(guò)配置的地址我們可以在邏輯上形成邏輯隔離的條帶， 如果機(jī)器也不混合部署和重復(fù)使用，條帶在物理上也是隔離的。

可用狀態(tài)表明當(dāng)前條帶是否可用；冷熱狀態(tài)表明 DB 中數(shù)據(jù)的時(shí)間特性，我們粗略分為冷、 熱和溫三類(lèi)。

代理服務(wù)

代理服務(wù)作為整個(gè)訂單系統(tǒng)的入口，需要提供下單、支付、查單和關(guān)單等接口。下單屬于創(chuàng)建訂單，支付和關(guān)單屬于更新訂單，查單屬于查詢(xún)訂單。下單的時(shí)候，代理服務(wù)需要正確和均勻的選擇條帶， 并在某些條帶不可用的情況下進(jìn)行跳單保證有限跳單次數(shù)內(nèi)可以找到可用的條帶。

對(duì)于支付、查單和關(guān)單需要正確解析單號(hào)中的條帶信息，進(jìn)行正確的路由。由于代理服務(wù)是無(wú)狀態(tài)的邏輯服務(wù)，為了提高代理服務(wù)的可用性，通過(guò)水平部署多個(gè)代理服務(wù)實(shí)例可以解決。假定同一時(shí)刻只有有限個(gè)代理服務(wù)實(shí)例同時(shí)不可用，業(yè)務(wù)方在一次請(qǐng)求中進(jìn)行失敗重試便可將請(qǐng)求路由到其它正常的代理服務(wù)，從而保證代理服務(wù)具有較高的可用性。

條帶

傳統(tǒng)的基于 Mysql 的系統(tǒng)架構(gòu)中為了擴(kuò)充系統(tǒng)的容量一般會(huì)采用水平的分庫(kù)分表策略，通過(guò)對(duì)主鍵進(jìn)行哈希將數(shù)據(jù)分布在不同的機(jī)器上從而提升系統(tǒng)的容量。例如實(shí)際系統(tǒng)假定有 8 組 DB，可以將主鍵按 8 求余進(jìn)行存儲(chǔ)，但是這樣的方案存在兩個(gè)缺點(diǎn)：冷熱分離和翻倍擴(kuò)容。

在訂單系統(tǒng)中，訂單記錄在一段時(shí)間之后很少會(huì)進(jìn)行訂單查詢(xún)和訂單退款，所以具有明顯的冷熱特性。為了更好的利用機(jī)器資源，一般會(huì)將 x 冷數(shù)據(jù)進(jìn)行分離并存儲(chǔ)到低成本的機(jī)器進(jìn)行存儲(chǔ)和訪(fǎng)問(wèn)。對(duì)于上面的 Sharding 模式，我們需要按天建表進(jìn)行冷數(shù)據(jù)分離。

對(duì)于上面的 Sharding 模式，擴(kuò)容的時(shí)候會(huì)選擇將 DB 的數(shù)量增加到 16 組，需要將擴(kuò)容的數(shù)據(jù)拷貝一份到新的機(jī) 器上，然后根據(jù) 16 進(jìn)行請(qǐng)求重新計(jì)算路由，上面的 過(guò)程被稱(chēng)作翻倍擴(kuò)容。上面的翻倍擴(kuò)容對(duì)于實(shí)時(shí)訂單系統(tǒng)是無(wú)法忍受的，我們更希望對(duì)系統(tǒng)的容量進(jìn)行線(xiàn)性擴(kuò)縮容，同時(shí)不需要影響已經(jīng)生成的訂單。為了更好的支持冷熱數(shù)據(jù)分離和線(xiàn)性擴(kuò)容，我們提出基于條帶的動(dòng)態(tài)擴(kuò)容架構(gòu)。一個(gè)條帶作為存儲(chǔ)的基本單元，其中包含了無(wú)狀態(tài)的邏輯服務(wù)和有狀態(tài)的存儲(chǔ)，通過(guò)增加和減少條帶的數(shù)量進(jìn)行線(xiàn)性的擴(kuò)縮容。

事務(wù)

對(duì)于交易系統(tǒng)很多場(chǎng)景下會(huì)面臨需要操作多個(gè)資源同時(shí)成功或者失敗，如轉(zhuǎn)賬、多個(gè)單據(jù)狀態(tài)的同時(shí)扭轉(zhuǎn)等。在單機(jī)關(guān)系型數(shù)據(jù)中我們會(huì)使用單機(jī)事務(wù)來(lái)進(jìn)行解決，同樣對(duì)于分布式系統(tǒng)需要系統(tǒng)具 備分布式事務(wù)的能力。

由于分布式事務(wù)的實(shí)現(xiàn)復(fù)雜、性能低下等特點(diǎn)，在業(yè)務(wù)系統(tǒng)中往往會(huì)將分布式事務(wù)轉(zhuǎn)化為單機(jī)事務(wù)進(jìn)行解決，或者將分布式事務(wù)根據(jù)核心程度劃分為主事務(wù)和次事務(wù)，通過(guò)將次事務(wù)通過(guò)異步組件進(jìn)行異步補(bǔ)償完成整個(gè)事務(wù)。

另外，由于交易系統(tǒng)一筆交易往往會(huì)操作多個(gè)相關(guān)的交易單據(jù)，我們可以將相關(guān)的多個(gè)單據(jù)部署在同一個(gè)分片， 這樣就可以轉(zhuǎn)化為單機(jī)事務(wù)進(jìn)行解決。通過(guò)上面的分析，我們將系統(tǒng)的事務(wù)轉(zhuǎn)為條帶內(nèi)的單機(jī)事務(wù)和跨條帶的異常補(bǔ)償事務(wù)，這樣各個(gè)條帶就可以充分解耦做到物理和邏輯的隔離。

跳單

在進(jìn)行下單前，系統(tǒng)中存在一個(gè)條帶健康度的檢查服務(wù)，它會(huì)實(shí)時(shí)模式真實(shí)訂單探測(cè)和收集條帶的健康度、耗時(shí)等情況。

另外，在某些情況下需要手動(dòng)屏蔽不可用或者可用的條帶 (如增加或減少跳單， 冷熱分離等場(chǎng)景)。在下單的時(shí)候，代理服務(wù)結(jié)合條帶健康度、黑名單等信息，并在可用的條帶內(nèi)根據(jù)短期內(nèi)每個(gè)條帶的請(qǐng)求量選擇一個(gè)可用的條帶，然后根據(jù)訂單號(hào)到對(duì)應(yīng)的條帶生成訂單。

如果第一次成功，則直接返回訂單號(hào)；如果沒(méi)有成功，此時(shí)可以屏蔽掉當(dāng)前的條帶，進(jìn)一步在剩余的可用條帶內(nèi)選擇一個(gè)可用的條帶，直到重試到達(dá)上限。我們稱(chēng)上面不斷重試尋找可用條帶的過(guò)程為跳單，跳單主要是通過(guò)有限次重試跳過(guò)不可用條帶而保證下單操作的高可用。

健康度檢查服務(wù)

條帶健康度檢查服務(wù)是所有條帶的觀察者，它通過(guò)周期性模擬真實(shí)的交易探測(cè)每個(gè)條帶的可用性和耗時(shí)等情況。

根據(jù)健康度檢查服務(wù)提供的條帶可用和耗時(shí)信息可以在下單的時(shí)候以更高的概率選到可用的條帶而有效的屏蔽掉不可用的條帶。條帶的是否可用也需要提供好的評(píng)價(jià)策略和兜底方案，防止網(wǎng)絡(luò)持續(xù)抖動(dòng)時(shí)造成過(guò)探測(cè)導(dǎo)致所有條帶的不可 用。

4.訂單流程

對(duì)于訂單系統(tǒng)，作為支付系統(tǒng)的核心流程，往往需要提供創(chuàng)建訂單、更新訂單和查詢(xún)訂單的能力。對(duì)于訂單的復(fù)雜查詢(xún)，為了不影響實(shí)時(shí)交易鏈路的可用性，會(huì)采用將備機(jī)的數(shù)據(jù)通過(guò)可靠的異步組件同步到非實(shí)時(shí)的數(shù)據(jù)庫(kù)進(jìn)行復(fù)雜查詢(xún)或者統(tǒng)計(jì)等操作。

下面會(huì)介紹基于上面的條帶化架構(gòu)的創(chuàng)建訂單、 修改訂單和查詢(xún)訂單的流程：

創(chuàng)建訂單

如表 2 所示的流程，主要由入口的路由服務(wù)完成訂單號(hào)的生成以及條帶不可用時(shí)的跳單操作。

這樣可以保證創(chuàng)建訂單的一個(gè)高可用，即使存在若干不可用的條帶整個(gè)系統(tǒng)還是可以進(jìn)行下單操作。

更新訂單

如表 3 所示的流程，當(dāng)業(yè)務(wù)在下單流程獲取訂單號(hào)之后，業(yè)務(wù)方攜帶單號(hào)，代理服務(wù)解析單號(hào)中的條帶編號(hào)，就可以保證請(qǐng)求在對(duì)應(yīng)的條帶內(nèi)進(jìn)行請(qǐng)求， 并正確找到對(duì)應(yīng) DB 的信息。

查詢(xún)訂單

對(duì)于訂單查詢(xún)，我們可以將查詢(xún)分為實(shí)時(shí)的讀請(qǐng)求和非實(shí)時(shí)的讀請(qǐng)求。實(shí)時(shí)的讀請(qǐng)求讀取主庫(kù)的數(shù)據(jù)，主要為核心鏈路提供準(zhǔn)確的數(shù)據(jù)查詢(xún)；非實(shí)時(shí)的讀請(qǐng)求讀取備庫(kù)的數(shù)據(jù)，主要為核心鏈路提供降級(jí)的備機(jī)讀取以及非實(shí)時(shí)鏈路的讀取。

如表 4 所示 的流程，當(dāng)業(yè)務(wù)在下單流程獲取訂單號(hào)之后，業(yè)務(wù)方攜帶單號(hào)，代理服務(wù)解析單號(hào)中的條帶編號(hào)，就可以保證請(qǐng)求在對(duì)應(yīng)的條帶內(nèi)進(jìn)行請(qǐng)求，并正確找到對(duì)應(yīng) DB 的信息。

5. 架構(gòu)特性

線(xiàn)性擴(kuò)容

對(duì)于海量交易的系統(tǒng)，線(xiàn)性擴(kuò)容成為一個(gè)重要的特性。線(xiàn)性擴(kuò)容給整個(gè)系統(tǒng)提供了更多的靈活性以應(yīng)對(duì)特定時(shí)期的交易洪峰，并且能通過(guò)簡(jiǎn)單的擴(kuò)縮容取得交易處理能力和成本的平衡。

對(duì)于業(yè)務(wù)可能快速持續(xù)增長(zhǎng)的系統(tǒng)，線(xiàn)性擴(kuò)容能力可以應(yīng)對(duì)不必要的系統(tǒng)重新設(shè)計(jì)和重構(gòu)。

故障壓縮

由于各條帶是邏輯和物理隔離的，不管是由于條帶內(nèi) DB 導(dǎo)致的故障或者灰度發(fā)布導(dǎo)致的故障， 相應(yīng)的故障只會(huì)壓縮在該條帶內(nèi)，不會(huì)擴(kuò)散導(dǎo)致整個(gè)系統(tǒng)的雪崩。

通過(guò)統(tǒng)計(jì)我們可以簡(jiǎn)單估算每個(gè)條單不可用的概率，然后估算整個(gè)系統(tǒng)不可用的概率。

差異服務(wù)

根據(jù)我們抽象的條帶概念，我們可以再聚合某些條帶為一個(gè)分區(qū)，某些商戶(hù)的請(qǐng)求只可以落在某些分區(qū)的條帶內(nèi)。這樣不同的分區(qū)提供不同的機(jī)器、帶寬等，可以實(shí)現(xiàn)對(duì)重點(diǎn)商戶(hù)和非重點(diǎn)商戶(hù)的差異化服務(wù)。

冷熱分離

當(dāng)系統(tǒng)某些條帶的容量到達(dá)預(yù)警值，或者其中的數(shù)據(jù)已經(jīng)超過(guò)某個(gè)冷卻閾值。我們可以將條帶變?yōu)橹蛔x和可更新，但不能再進(jìn)行數(shù)據(jù)的寫(xiě)入。

等到數(shù)據(jù)的訪(fǎng)問(wèn)量下降到某個(gè)閾值后，可以將條帶內(nèi)的全量數(shù)據(jù)停寫(xiě)后拷貝到冷庫(kù)，然后修改條帶路由信息中的存儲(chǔ)服務(wù)地址為冷數(shù)據(jù)所在的新機(jī)器的地址。

然后刪除舊機(jī)器上的數(shù)據(jù)并新增一個(gè)空的條帶，這樣就可以簡(jiǎn)單的完成冷熱數(shù)據(jù)分離，同時(shí)上面的過(guò)程可以實(shí)現(xiàn)完全自動(dòng)化。

灰度控制

在互聯(lián)網(wǎng)系統(tǒng)的可用性問(wèn)題中，統(tǒng)計(jì)發(fā)現(xiàn)很多版本的問(wèn)題可以通過(guò)合理的灰度提早發(fā)現(xiàn)和解決。基于條帶的架構(gòu)可以輕松的構(gòu)建預(yù)發(fā)布環(huán)境，預(yù)發(fā)布環(huán)境通過(guò)后可以控制新版本先對(duì)某些生產(chǎn)條帶進(jìn)行灰度發(fā)布，然后逐步灰度到所有的條帶。

同時(shí)還可以通過(guò)控制某些條帶的請(qǐng)求量從而可以做到更細(xì)粒度的灰度。

熱點(diǎn)均衡

在選擇分區(qū)的時(shí)候，可以統(tǒng)計(jì)近期每個(gè)條帶創(chuàng)建的訂單數(shù)作出一個(gè)合理的條帶選擇，從而達(dá)到最大程度的數(shù)據(jù)均衡，避免傳統(tǒng)分片模式下數(shù)據(jù)傾斜的問(wèn)題。

6. 備份、容災(zāi)和恢復(fù)

備份

為了應(yīng)對(duì)機(jī)架級(jí)不可用、機(jī)房級(jí)不可用和城市級(jí)不可用，需要通過(guò)數(shù)據(jù)備份進(jìn)行容災(zāi)?？梢愿鶕?jù)業(yè)務(wù)的容災(zāi)選擇合理的容災(zāi)級(jí)別，通常業(yè)務(wù)會(huì)選擇一主兩備的三機(jī)備份策略。

數(shù)據(jù)一致性

如果采用 Mysql 作為條帶內(nèi)的存儲(chǔ)引擎，Mysql 支持同步復(fù)制、異步復(fù)制、半同步復(fù)制、增強(qiáng)半同步復(fù)制和 MGR(MySQL Group Replication)。通常我們很少采用同步和異步復(fù)制，在 Mysql5.7 增強(qiáng)半同步之前 DBA 多會(huì)采用半同步復(fù)制，但如果主機(jī)宕機(jī) 切換到備機(jī)會(huì)出現(xiàn)一定的數(shù)據(jù)不一致。

為了解決半同步帶來(lái)的問(wèn)題，Mysql5.7 之后推出了增強(qiáng)半同步。但是 MGR 是基于 Paxos 的強(qiáng)一致復(fù)制方案，但是 MGR 業(yè)界的互聯(lián)網(wǎng)公司卻很少有公司采用。

容災(zāi)

我們假定所有的機(jī)房都在一個(gè)城市內(nèi)的不同機(jī)房，為了應(yīng)對(duì)城市內(nèi)的機(jī)房級(jí)不可用，我們需要將三份數(shù)據(jù)分布在同城的三個(gè)不同機(jī)房?jī)?nèi)，同時(shí)保證每個(gè)機(jī)房?jī)?nèi)有相同的主機(jī)和備機(jī)的數(shù)量，對(duì)機(jī)房級(jí)進(jìn)行負(fù)載均衡。

當(dāng)出現(xiàn)機(jī)房級(jí)以及機(jī)房級(jí)以下的不可用，可以快速的進(jìn)行主機(jī)切換保證業(yè)務(wù)的可用性， 如果出現(xiàn)整個(gè)機(jī)房的不可用最多會(huì)損失 1/3 的交易量。但是對(duì)于條帶化的架構(gòu)，我們可以快速調(diào)整條帶路由信息表將不可用的條帶進(jìn)行屏蔽，這樣只會(huì)有一個(gè)短暫的不可用。

7. 架構(gòu)缺點(diǎn)及改進(jìn)

對(duì)于分布式事務(wù)不太友好。

其實(shí)可以將更多的能力下降到存儲(chǔ)進(jìn)行解決， 這樣對(duì)業(yè)務(wù)人員的架構(gòu)能力提出較高的要求。

如果現(xiàn)行系統(tǒng)進(jìn)行改造的成本過(guò)高。

8. 總結(jié)

上文首先描述了基于單機(jī) Mysql 構(gòu)建的業(yè)務(wù)和存儲(chǔ)強(qiáng)耦合的高可用海量分布式訂單系統(tǒng)，基于抽象的條帶概念使得整個(gè)系統(tǒng)架構(gòu)天然具備了一些線(xiàn)性擴(kuò)容、故障壓縮、冷熱分離、灰度控制、差異服務(wù)和熱點(diǎn)均衡等能力。雖然不同于支付寶通過(guò)強(qiáng)一致分布式存儲(chǔ)系統(tǒng)來(lái)保證分布式存儲(chǔ)服務(wù)的高可用， 但這種構(gòu)建于單機(jī) Mysql 的架構(gòu)更加適合沒(méi)有獨(dú)立研發(fā)分布式存儲(chǔ)的中小企業(yè)。從目前業(yè)界存儲(chǔ)演進(jìn)的方向來(lái)看，強(qiáng)一致的分布式關(guān)系型數(shù)據(jù)存儲(chǔ)系統(tǒng)還是業(yè)界努力的方向。