業(yè)務(wù)場(chǎng)景

達(dá)達(dá)是全國(guó)領(lǐng)先的最后三公里物流配送平臺(tái)。 達(dá)達(dá)的業(yè)務(wù)模式與滴滴以及Uber很相似，以眾包的方式利用社會(huì)閑散人力資源，解決O2O最后三公里即時(shí)性配送難題。 達(dá)達(dá)業(yè)務(wù)主要包含兩部分：商家發(fā)單，配送員接單配送，如下圖所示。

達(dá)達(dá)的業(yè)務(wù)規(guī)模增長(zhǎng)極大，在1年左右的時(shí)間從零增長(zhǎng)到每天近百萬單，給后端帶來極大的訪問壓力。壓力主要分為兩類：讀壓力、寫壓力。讀壓力來源于配送員在APP中搶單，高頻刷新查詢周圍的訂單，每天訪問量幾億次，高峰期QPS高達(dá)數(shù)千次/秒。寫壓力來源于商家發(fā)單、達(dá)達(dá)接單、取貨、完成等操作。達(dá)達(dá)業(yè)務(wù)讀的壓力遠(yuǎn)大于寫壓力，讀請(qǐng)求量約是寫請(qǐng)求量的30倍以上。

下圖是達(dá)達(dá)過去6個(gè)月，每天的訪問量及QPS變化趨勢(shì)圖變化趨圖，可見增長(zhǎng)極快

極速增長(zhǎng)的業(yè)務(wù)，對(duì)技術(shù)的要求越來越高，我們必須在架構(gòu)上做好充分的準(zhǔn)備，才能迎接業(yè)務(wù)的挑戰(zhàn)。接下來，我們一起看看達(dá)達(dá)的后臺(tái)架構(gòu)是如何演化的。

最初的技術(shù)選型

作為創(chuàng)業(yè)公司，最重要的一點(diǎn)是敏捷，快速實(shí)現(xiàn)產(chǎn)品，對(duì)外提供服務(wù)，于是我們選擇了公有云服務(wù)，保證快速實(shí)施和可擴(kuò)展性，節(jié)省了自建機(jī)房等時(shí)間。在技術(shù)選型上，為快速的響應(yīng)業(yè)務(wù)需求，業(yè)務(wù)系統(tǒng)使用python做為開發(fā)語言，數(shù)據(jù)庫(kù)使用Mysql。如下圖所示，應(yīng)用層的幾大系統(tǒng)都訪問一個(gè)數(shù)據(jù)庫(kù)。

讀寫分離

隨著業(yè)務(wù)的發(fā)展，訪問量的極速增長(zhǎng)，上述的方案很快不能滿足性能需求。每次請(qǐng)求的響應(yīng)時(shí)間越來越長(zhǎng)，比如配送員在app中刷新周圍訂單，響應(yīng)時(shí)間從最初的500毫秒增加到了2秒以上。業(yè)務(wù)高峰期，系統(tǒng)甚至出現(xiàn)過宕機(jī)，一些商家和配送員甚至因此而懷疑我們的服務(wù)質(zhì)量。在這生死存亡的關(guān)鍵時(shí)刻，通過監(jiān)控，我們發(fā)現(xiàn)高期峰Mysql CPU使用率已接近80%，磁盤IO使用率接近90%，Slow query從每天1百條上升到1萬條，而且一天比一天嚴(yán)重。數(shù)據(jù)庫(kù)儼然已成為瓶頸，我們必須得快速做架構(gòu)升級(jí)。

如下是數(shù)據(jù)庫(kù)一周的qps變化圖，可見數(shù)據(jù)庫(kù)壓力的增長(zhǎng)極快。

當(dāng)Web應(yīng)用服務(wù)出現(xiàn)性能瓶頸的時(shí)候，由于服務(wù)本身無狀態(tài)（stateless），我們可以通過加機(jī)器的水平擴(kuò)展方式來解決。 而數(shù)據(jù)庫(kù)顯然無法通過簡(jiǎn)單的添加機(jī)器來實(shí)現(xiàn)擴(kuò)展，因此我們采取了Mysql主從同步和應(yīng)用服務(wù)端讀寫分離的方案。

Mysql支持主從同步，實(shí)時(shí)將主庫(kù)的數(shù)據(jù)增量復(fù)制到從庫(kù)，而且一個(gè)主庫(kù)可以連接多個(gè)從庫(kù)同步（細(xì)節(jié)參考Replication）。利用此特性，我們?cè)趹?yīng)用服務(wù)端對(duì)每次請(qǐng)求做讀寫判斷，若是寫請(qǐng)求，則把這次請(qǐng)求內(nèi)的所有DB操作發(fā)向主庫(kù)；若是讀請(qǐng)求，則把這次請(qǐng)求內(nèi)的所有DB操作發(fā)向從庫(kù)，如下圖所示。

實(shí)現(xiàn)讀寫分離后，數(shù)據(jù)庫(kù)的壓力減少了許多，CPU使用率和IO使用率都降到了5%內(nèi)，Slow Query也趨近于0。主從同步、讀寫分離給我們主要帶來如下兩個(gè)好處：

減輕了主庫(kù)（寫）壓力：達(dá)達(dá)的業(yè)務(wù)主要來源于讀操作，做讀寫分離后，讀壓力轉(zhuǎn)移到了從庫(kù)，主庫(kù)的壓力減小了數(shù)十倍。

從庫(kù)（讀）可水平擴(kuò)展（加從庫(kù)機(jī)器）：因系統(tǒng)壓力主要是讀請(qǐng)求，而從庫(kù)又可水平擴(kuò)展，當(dāng)從庫(kù)壓力太時(shí)，可直接添加從庫(kù)機(jī)器，緩解讀請(qǐng)求壓力

如下是優(yōu)化后數(shù)據(jù)庫(kù)qps的變化圖：

讀寫分離前主庫(kù)的select qps

讀寫分離后主庫(kù)的select qps

當(dāng)然，沒有一個(gè)方案是萬能的。讀寫分離，暫時(shí)解決了Mysql壓力問題，同時(shí)也帶來了新的挑戰(zhàn)。業(yè)務(wù)高峰期，商家發(fā)完訂單，在我的訂單列表中卻看不到當(dāng)發(fā)的訂單（典型的read after write）；系統(tǒng)內(nèi)部偶爾也會(huì)出現(xiàn)一些查詢不到數(shù)據(jù)的異常。通過監(jiān)控，我們發(fā)現(xiàn)，業(yè)務(wù)高峰期Mysql可能會(huì)出現(xiàn)主從延遲，極端情況，主從延遲高達(dá)10秒。

那如何監(jiān)控主從同步狀態(tài)？在從庫(kù)機(jī)器上，執(zhí)行show slave status，查看Seconds_Behind_Master值，代表主從同步從庫(kù)落后主庫(kù)的時(shí)間，單位為秒，若主從同步無延遲，這個(gè)值為0。Mysql主從延遲一個(gè)重要的原因之一是主從復(fù)制是單線程串行執(zhí)行。

那如何為避免或解決主從延遲？我們做了如下一些優(yōu)化：

優(yōu)化Mysql參數(shù)，比如增大innodb_buffer_pool_size，讓更多操作在Mysql內(nèi)存中完成，減少磁盤操作。

使用高性能CPU主機(jī)

數(shù)據(jù)庫(kù)使用物理主機(jī)，避免使用虛擬云主機(jī)，提升IO性能

使用SSD磁盤，提升IO性能。SSD的隨機(jī)IO性能約是SATA硬盤的10倍。

業(yè)務(wù)代碼優(yōu)化，將實(shí)時(shí)性要求高的某些操作，使用主庫(kù)做讀操作

垂直分庫(kù)

讀寫分離很好的解決讀壓力問題，每次讀壓力增加，可以通過加從庫(kù)的方式水平擴(kuò)展。但是寫操作的壓力隨著業(yè)務(wù)爆發(fā)式的增長(zhǎng)沒有很有效的緩解辦法，比如商家發(fā)單起來越慢，嚴(yán)重影響了商家的使用體驗(yàn)。我們監(jiān)控發(fā)現(xiàn)，數(shù)據(jù)庫(kù)寫操作越來越慢，一次普通的insert操作，甚至可能會(huì)執(zhí)行1秒以上。

下圖是數(shù)據(jù)庫(kù)主庫(kù)的壓力， 可見磁盤IO使用率已經(jīng)非常高，高峰期IO響應(yīng)時(shí)間最大達(dá)到636毫秒，IO使用率最高達(dá)到100%。

同時(shí)，業(yè)務(wù)越來越復(fù)雜，多個(gè)應(yīng)用系統(tǒng)使用同一個(gè)數(shù)據(jù)庫(kù)，其中一個(gè)很小的非核心功能出現(xiàn)Slow query，常常影響主庫(kù)上的其它核心業(yè)務(wù)功能。我們有一個(gè)應(yīng)用系統(tǒng)在MySql中記錄日志，日志量非常大，近1億行記錄，而這張表的ID是UUID，某一天高峰期，整個(gè)系統(tǒng)突然變慢，進(jìn)而引發(fā)了宕機(jī)。監(jiān)控發(fā)現(xiàn)，這張表insert極慢，拖慢了整個(gè)MySql Master，進(jìn)而拖跨了整個(gè)系統(tǒng)。（當(dāng)然在mysql中記日志不是一種好的設(shè)計(jì)，因此我們開發(fā)了大數(shù)據(jù)日志系統(tǒng)，敬請(qǐng)關(guān)注本博客后續(xù)文章。另一方面，UUID做主鍵是個(gè)糟糕的選擇，在下文的水平分庫(kù)中，針對(duì)ID的生成，有更深入的講述）。

這時(shí)，主庫(kù)成為了性能瓶頸，我們意識(shí)到，必需得再一次做架構(gòu)升級(jí)，將主庫(kù)做拆分，一方面以提升性能，另一方面減少系統(tǒng)間的相互影響，以提升系統(tǒng)穩(wěn)定性。這一次，我們將系統(tǒng)按業(yè)務(wù)進(jìn)行了垂直拆分。如下圖所示，將最初龐大的數(shù)據(jù)庫(kù)按業(yè)務(wù)拆分成不同的業(yè)務(wù)數(shù)據(jù)庫(kù)，每個(gè)系統(tǒng)僅訪問對(duì)應(yīng)業(yè)務(wù)的數(shù)據(jù)庫(kù)，避免或減少跨庫(kù)訪問。

下圖是垂直拆分后，數(shù)據(jù)庫(kù)主庫(kù)的壓力，可見磁盤IO使用率已降低了許多，高峰期IO響應(yīng)時(shí)間在2.33毫秒內(nèi)，IO使用率最高只到22.8%。

未來是美好的，道路是曲折的。垂直分庫(kù)過程，我們也遇到不少挑戰(zhàn)，最大的挑戰(zhàn)是：不能跨庫(kù)join，同時(shí)需要對(duì)現(xiàn)有代碼重構(gòu)。單庫(kù)時(shí)，可以簡(jiǎn)單的使用join關(guān)聯(lián)表查詢；拆庫(kù)后，拆分后的數(shù)據(jù)庫(kù)在不同的實(shí)例上，就不能跨庫(kù)使用join了。比如在CRM系統(tǒng)中，需要通過商家名查詢某個(gè)商家的所有訂單，在垂直分庫(kù)前，可以join商家和訂單表做查詢，如下如示：

select * from tborder where supplierid in (select id from supplier where name=‘上海海底撈’)；

分庫(kù)后，則要重構(gòu)代碼，先通過商家名查詢商家id，再通過商家Id查詢訂單表，如下所示：

supplierids = select id from supplier where name=‘上海海底撈’

select * from tb_order where supplierid in (supplierids )

垂直分庫(kù)過程中的經(jīng)驗(yàn)教訓(xùn)，使我們制定了SQL最佳實(shí)踐，其中一條便是程序中禁用或少用join，而應(yīng)該在程序中組裝數(shù)據(jù)，讓SQL更簡(jiǎn)單。一方面為以后進(jìn)一步垂直拆分業(yè)務(wù)做準(zhǔn)備，另一方面也避免了Mysql中join的性能較低的問題。

經(jīng)過一個(gè)星期緊鑼密鼓的底層架構(gòu)調(diào)整，以及業(yè)務(wù)代碼重構(gòu)，終于完成了數(shù)據(jù)庫(kù)的垂直拆分。拆分之后，每個(gè)應(yīng)用程序只訪問對(duì)應(yīng)的數(shù)據(jù)庫(kù)，一方面將單點(diǎn)數(shù)據(jù)庫(kù)拆分成了多個(gè)，分?jǐn)偭酥鲙?kù)寫壓力；另一方面，拆分后的數(shù)據(jù)庫(kù)各自獨(dú)立，實(shí)現(xiàn)了業(yè)務(wù)隔離，不再互相影響。

水平分庫(kù)（sharding）

讀寫分離，通過從庫(kù)水平擴(kuò)展，解決了讀壓力；垂直分庫(kù)通過按業(yè)務(wù)拆分主庫(kù)，緩存了寫壓力，但系統(tǒng)依然存在以下隱患：

單表數(shù)據(jù)量越來越大。如訂單表，單表記錄數(shù)很快將過億，超出MySql的極限，影響讀寫性能。

核心業(yè)務(wù)庫(kù)的寫壓力越來越大，已不能再進(jìn)一次垂直拆分，Mysql 主庫(kù)不具備水平擴(kuò)展的能力

以前，系統(tǒng)壓力逼迫我們架構(gòu)升級(jí)，這一次，我們需提前做好架構(gòu)升級(jí)，實(shí)現(xiàn)數(shù)據(jù)庫(kù)的水平擴(kuò)展(sharding)。業(yè)務(wù)類似于我們的Uber在公司成立的5年后（2014）年才實(shí)施了水平分庫(kù)（mezzanine-migration）,但我們的業(yè)務(wù)發(fā)展要求我們?cè)诔闪?8月就要開始實(shí)施水平分庫(kù)。邏輯架構(gòu)圖如下圖所示：

水平分庫(kù)面臨的第一個(gè)問題是，按什么邏輯進(jìn)行拆分。一種方案是按城市拆分，一個(gè)城市的所有數(shù)據(jù)在一個(gè)數(shù)據(jù)庫(kù)中；另一種方案是按訂單ID平均拆分?jǐn)?shù)據(jù)。按城市拆分的優(yōu)點(diǎn)是數(shù)據(jù)聚合度比較高，做聚合查詢比較簡(jiǎn)單，實(shí)現(xiàn)也相對(duì)簡(jiǎn)單，缺點(diǎn)是數(shù)據(jù)分布不均勻，某些城市的數(shù)據(jù)量極大，產(chǎn)生熱點(diǎn)，而這些熱點(diǎn)以后可能還要被迫再次拆分。按訂單ID拆分則正相反，優(yōu)點(diǎn)是數(shù)據(jù)分布均勻，不會(huì)出現(xiàn)一個(gè)數(shù)據(jù)庫(kù)數(shù)據(jù)極大或極小的情況，缺點(diǎn)是數(shù)據(jù)太分散，不利于做聚合查詢。比如，按訂單ID拆分后，一個(gè)商家的訂單可能分布在不同的數(shù)據(jù)庫(kù)中，查詢一個(gè)商家的所有訂單，可能需要查詢多個(gè)數(shù)據(jù)庫(kù)。針對(duì)這種情況，一種解決方案是將需要聚合查詢的數(shù)據(jù)做冗余表，冗余的表不做拆分，同時(shí)在業(yè)務(wù)開發(fā)過程中，減少聚合查詢。

反復(fù)權(quán)衡利弊，并參考了Uber等公司的分庫(kù)方案后，我們最后決定按訂單ID做水平分庫(kù)。從架構(gòu)上，我們將系統(tǒng)分為三層：

應(yīng)用層：即各類業(yè)務(wù)應(yīng)用系統(tǒng)

數(shù)據(jù)訪問層：統(tǒng)一的數(shù)據(jù)訪問接口，對(duì)上層應(yīng)用層屏蔽讀寫分庫(kù)、分庫(kù)、緩存等技術(shù)細(xì)節(jié)。

數(shù)據(jù)層：對(duì)DB數(shù)據(jù)進(jìn)行分片，并可動(dòng)態(tài)的添加shard分片。

水平分庫(kù)的技術(shù)關(guān)鍵點(diǎn)在于數(shù)據(jù)訪問層的設(shè)計(jì)，數(shù)據(jù)訪問層主要包含三部分：

ID生成器：生成每張表的主鍵

數(shù)據(jù)源路由：將每次DB操作路由到不同的shard數(shù)據(jù)源上

緩存： 采用Redis實(shí)現(xiàn)數(shù)據(jù)的緩存，提升性能（以后會(huì)有詳細(xì)文章）

ID生成器是整個(gè)水平分庫(kù)的核心，它決定了如何拆分?jǐn)?shù)據(jù)，以及查詢存儲(chǔ)-檢索數(shù)據(jù)。ID需要跨庫(kù)全局唯一，否則會(huì)引發(fā)業(yè)務(wù)層的沖突。此外，ID必須是數(shù)字且升序，這主要是考慮到升序的ID能保證Mysql的性能（若是UUID等隨機(jī)字符串，在高并發(fā)和大數(shù)據(jù)量情況下，性能極差。對(duì)比性能測(cè)試數(shù)據(jù)可供參考uuid-vs-int-insert-performance）。同時(shí)，ID生成器必須非常穩(wěn)定，因?yàn)槿魏喂收隙紩?huì)影響所有的數(shù)據(jù)庫(kù)操作。

我們的ID的生成策略借鑒了Instagram的ID生成算法（sharding-ids-at-instagram）。具體方案如下：

整個(gè)ID的二進(jìn)制長(zhǎng)度為64位

前36位使用時(shí)間戳，以保證ID是升序增加

中間13位是分庫(kù)標(biāo)識(shí)，用來標(biāo)識(shí)當(dāng)前這個(gè)ID對(duì)應(yīng)的記錄在哪個(gè)數(shù)據(jù)庫(kù)中

后15位為自增序列，以保證在同一秒內(nèi)并發(fā)時(shí)，ID不會(huì)重復(fù)。每個(gè)shard庫(kù)都有一個(gè)自增序列表，生成自增序列時(shí)，從自增序列表中獲取當(dāng)前自增序列值，并加1，做為當(dāng)前ID的后15位。