架構(gòu)演進(jìn)實(shí)踐:從0到4000高并發(fā)請(qǐng)求背后的努力！-創(chuàng)新互聯(lián)

創(chuàng)新互聯(lián)IDC提供業(yè)務(wù):成都機(jī)柜租用,成都服務(wù)器租用,成都機(jī)柜租用,重慶服務(wù)器租用等四川省內(nèi)主機(jī)托管與主機(jī)租用業(yè)務(wù);數(shù)據(jù)中心含:雙線機(jī)房,BGP機(jī)房,電信機(jī)房,移動(dòng)機(jī)房,聯(lián)通機(jī)房。

來(lái)自：即時(shí)通訊網(wǎng)  
http://www.52im.net/thread-2141-1-1.html

達(dá)達(dá)創(chuàng)立于2014年5月，業(yè)務(wù)覆蓋全國(guó)37個(gè)城市，擁有130萬(wàn)注冊(cè)眾包配送員，日均配送百萬(wàn)單，是全國(guó)領(lǐng)先的最后三公里物流配送平臺(tái)。達(dá)達(dá)的業(yè)務(wù)模式與滴滴以及Uber很相似，以眾包的方式利用社會(huì)閑散人力資源，解決O2O最后三公里即時(shí)性配送難題（2016年4月，達(dá)達(dá)已經(jīng)與京東到家合并）。

達(dá)達(dá)的業(yè)務(wù)組成簡(jiǎn)單直接——商家下單、配送員接單和配送，也正因?yàn)槔斫馄饋?lái)簡(jiǎn)單，使得達(dá)達(dá)的業(yè)務(wù)量在短時(shí)間能實(shí)現(xiàn)爆發(fā)式增長(zhǎng)。而支撐業(yè)務(wù)快速增長(zhǎng)的背后，正是達(dá)達(dá)技術(shù)團(tuán)隊(duì)持續(xù)不斷的快速技術(shù)迭代的結(jié)果，本文正好借此機(jī)會(huì)，總結(jié)并分享了這一系列技術(shù)演進(jìn)的第一手實(shí)踐資料，希望能給同樣奮斗在互聯(lián)網(wǎng)創(chuàng)業(yè)一線的你帶來(lái)啟發(fā)。

技術(shù)背景

達(dá)達(dá)業(yè)務(wù)主要包含兩部分：

• 商家發(fā)單；

• 配送員接單配送；

達(dá)達(dá)的業(yè)務(wù)邏輯看起來(lái)非常簡(jiǎn)單直接，如下圖所示：

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

下圖是達(dá)達(dá)在成長(zhǎng)初期，每天的訪問(wèn)量變化趨圖，可見(jiàn)增長(zhǎng)極快：

下圖是達(dá)達(dá)在成長(zhǎng)初期，高峰期請(qǐng)求QPS的變化趨勢(shì)圖，可見(jiàn)增長(zhǎng)極快：

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

最初的技術(shù)架構(gòu)：簡(jiǎn)單直接 

作為創(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做為開(kāi)發(fā)語(yǔ)言，數(shù)據(jù)庫(kù)使用MySQL。

如下圖所示，應(yīng)用層的幾大系統(tǒng)都訪問(wèn)一個(gè)數(shù)據(jù)庫(kù)：

中期架構(gòu)優(yōu)化：讀寫(xiě)分離

數(shù)據(jù)庫(kù)瓶頸越來(lái)越嚴(yán)重

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

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

我們的讀寫(xiě)分離方案

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

MySQL支持主從同步，實(shí)時(shí)將主庫(kù)的數(shù)據(jù)增量復(fù)制到從庫(kù)，而且一個(gè)主庫(kù)可以連接多個(gè)從庫(kù)同步。

利用MySQL的此特性，我們?cè)趹?yīng)用服務(wù)端對(duì)每次請(qǐng)求做讀寫(xiě)判斷：

• 若是寫(xiě)請(qǐng)求，則把這次請(qǐng)求內(nèi)的所有DB操作發(fā)向主庫(kù)；

• 若是讀請(qǐng)求，則把這次請(qǐng)求內(nèi)的所有DB操作發(fā)向從庫(kù)。

實(shí)現(xiàn)讀寫(xiě)分離后，數(shù)據(jù)庫(kù)的壓力減少了許多，CPU使用率和IO使用率都降到了5%內(nèi)，Slow Query也趨近于0。

主從同步、讀寫(xiě)分離給我們主要帶來(lái)如下兩個(gè)好處：

• 減輕了主庫(kù)（寫(xiě)）壓力：達(dá)達(dá)的業(yè)務(wù)主要來(lái)源于讀操作，做讀寫(xiě)分離后，讀壓力轉(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的變化圖：

讀寫(xiě)分離前主庫(kù)的select QPS

讀寫(xiě)分離后主庫(kù)的select QPS

新?tīng)顩r出現(xiàn)：主從延遲問(wèn)題

當(dāng)然，沒(méi)有一個(gè)方案是萬(wàn)能的。

讀寫(xiě)分離，暫時(shí)解決了MySQL壓力問(wèn)題，同時(shí)也帶來(lái)了新的挑戰(zhàn)：

• 業(yè)務(wù)高峰期，商家發(fā)完訂單，在我的訂單列表中卻看不到當(dāng)發(fā)的訂單（典型的read after write）；

• 系統(tǒng)內(nèi)部偶爾也會(huì)出現(xiàn)一些查詢不到數(shù)據(jù)的異常。

通過(guò)監(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í)間，單位為秒，若同從同步無(wú)延遲，這個(gè)值為0。MySQL主從延遲一個(gè)重要的原因之一是主從復(fù)制是單線程串行執(zhí)行。

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

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

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

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

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

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

主庫(kù)的寫(xiě)操作變的越來(lái)越慢

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

可見(jiàn)磁盤(pán)IO使用率已經(jīng)非常高，高峰期IO響應(yīng)時(shí)間大達(dá)到636毫秒，IO使用率最高達(dá)到100%

同時(shí)，業(yè)務(wù)越來(lái)越復(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ì)，因此我們開(kāi)發(fā)了大數(shù)據(jù)日志系統(tǒng)。另一方面，UUID做主鍵是個(gè)糟糕的選擇，在下文的水平分庫(kù)中，針對(duì)ID的生成，有更深入的講述）。

進(jìn)一步對(duì)主庫(kù)進(jìn)行拆分，優(yōu)化主庫(kù)寫(xiě)操作慢的問(wèn)題

這時(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)僅訪問(wèn)對(duì)應(yīng)業(yè)務(wù)的數(shù)據(jù)庫(kù)，避免或減少跨庫(kù)訪問(wèn)：

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

未來(lái)是美好的，道路是曲折的。

垂直分庫(kù)過(guò)程，也遇到不少挑戰(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)中，需要通過(guò)商家名查詢某個(gè)商家的所有訂單，在垂直分庫(kù)前，可以join商家和訂單表做查詢，如下如示：

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

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

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

為未來(lái)做準(zhǔn)備，進(jìn)一步升級(jí)架構(gòu)：水平分庫(kù)（sharding）

通過(guò)上一節(jié)的分享，我們知道：

• 讀寫(xiě)分離，通過(guò)從庫(kù)水平擴(kuò)展，解決了讀壓力；

• 垂直分庫(kù)通過(guò)按業(yè)務(wù)拆分主庫(kù)，緩存了寫(xiě)壓力。

但技術(shù)團(tuán)隊(duì)是否就此高枕無(wú)憂？答案是：NO。

上述架構(gòu)依然存在以下隱患：

• 單表數(shù)據(jù)量越來(lái)越大：如訂單表，單表記錄數(shù)很快將過(guò)億，超出MySQL的極限，影響讀寫(xiě)性能；

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

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

水平分庫(kù)面臨的第一個(gè)問(wèn)題是，按什么邏輯進(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ù)開(kāi)發(fā)過(guò)程中，減少聚合查詢。

反復(fù)權(quán)衡利弊，并參考了Uber等公司的分庫(kù)方案后，我們最后決定按訂單ID做水平分庫(kù)。

從架構(gòu)上，我們將系統(tǒng)分為三層：

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

• 數(shù)據(jù)訪問(wèn)層：統(tǒng)一的數(shù)據(jù)訪問(wèn)接口，對(duì)上層應(yīng)用層屏蔽讀寫(xiě)分庫(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ù)訪問(wèn)層的設(shè)計(jì)。

數(shù)據(jù)訪問(wèn)層主要包含三部分：

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

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

• 緩存：采用Redis實(shí)現(xiàn)數(shù)據(jù)的緩存，提升性能。

ID生成器是整個(gè)水平分庫(kù)的核心，它決定了如何拆分?jǐn)?shù)據(jù)，以及查詢存儲(chǔ)-檢索數(shù)據(jù)：

• ID需要跨庫(kù)全局唯一，否則會(huì)引發(fā)業(yè)務(wù)層的沖突；

• 此外，ID必須是數(shù)字且升序，這主要是考慮到升序的ID能保證MySQL的性能；

• 同時(shí)，ID生成器必須非常穩(wěn)定，因?yàn)槿魏喂收隙紩?huì)影響所有的數(shù)據(jù)庫(kù)操作；

我們的ID的生成策略借鑒了Instagram的ID生成算法。

如上圖所示，方案說(shuō)明如下：

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

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

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

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

寫(xiě)在最后

創(chuàng)業(yè)是與時(shí)間賽跑的過(guò)程，前期為了快速滿足業(yè)務(wù)需求，我們采用簡(jiǎn)單高效的方案，如使用云服務(wù)、應(yīng)用服務(wù)直接訪問(wèn)單點(diǎn)DB。

后期隨著系統(tǒng)壓力增大，性能和穩(wěn)定性逐漸納入考慮范圍，而DB最容易出現(xiàn)性能瓶頸，我們采用讀寫(xiě)分離、垂直分庫(kù)、水平分庫(kù)等方案。

面對(duì)高性能和高穩(wěn)定性，架構(gòu)升級(jí)需要盡可能超前完成，否則，系統(tǒng)隨時(shí)可能出現(xiàn)系統(tǒng)響應(yīng)變慢甚至宕機(jī)的情況。

原文鏈接：https://mp.weixin.qq.com/s/IWytJhcxth5ig2qrqdQjvg

新聞標(biāo)題：架構(gòu)演進(jìn)實(shí)踐:從0到4000高并發(fā)請(qǐng)求背后的努力！-創(chuàng)新互聯(lián)
文章起源：http://bm7419.com/article48/giohp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、定制開(kāi)發(fā)、網(wǎng)站建設(shè)、手機(jī)網(wǎng)站建設(shè)、企業(yè)建站、App開(kāi)發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)