[[360800]] 

圖片來自 Pexels

當(dāng)時(shí)用的 MySQL 數(shù)據(jù)庫。根據(jù)監(jiān)控，我們的每秒最高訂單量已經(jīng)達(dá)到了 2000 筆(不包括秒殺，秒殺 TPS 已經(jīng)上萬了。秒殺我們有一套專門的解決方案，詳見《秒殺系統(tǒng)設(shè)計(jì)～億級(jí)用戶》)。

不過，直到此時(shí)，訂單系統(tǒng)還是單庫單表，幸好當(dāng)時(shí)數(shù)據(jù)庫服務(wù)器配置不錯(cuò)，我們的系統(tǒng)才能撐住這么大的壓力。

業(yè)務(wù)量還在快速增長，再不重構(gòu)系統(tǒng)早晚出大事，我們花了一天時(shí)間快速制定了重構(gòu)方案。

重構(gòu)?說這么高大上，不就是分庫分表嗎?的確，就是分庫分表。不過除了分庫分表，還包括管理端的解決方案，比如運(yùn)營，客服和商務(wù)需要從多維度查詢訂單數(shù)據(jù)，分庫分表后，怎么滿足大家的需求?

分庫分表后，上線方案和數(shù)據(jù)不停機(jī)遷移方案都需要慎重考慮。為了保證系統(tǒng)穩(wěn)定，還需要考慮相應(yīng)的降級(jí)方案。

為什么要分庫分表?

當(dāng)數(shù)據(jù)庫產(chǎn)生性能瓶頸：IO 瓶頸或 CPU 瓶頸。兩種瓶頸最終都會(huì)導(dǎo)致數(shù)據(jù)庫的活躍連接數(shù)增加，進(jìn)而達(dá)到數(shù)據(jù)庫可承受的最大活躍連接數(shù)閾值。

終會(huì)導(dǎo)致應(yīng)用服務(wù)無連接可用，造成災(zāi)難性后果?？梢韵葟拇a，SQL，索引幾方面進(jìn)行優(yōu)化。如果這幾方面已經(jīng)沒有太多優(yōu)化的余地，就該考慮分庫分表了。

IO 瓶頸

第一種：磁盤讀 IO 瓶頸。

由于熱點(diǎn)數(shù)據(jù)太多，數(shù)據(jù)庫緩存完全放不下，查詢時(shí)會(huì)產(chǎn)生大量的磁盤 IO，查詢速度會(huì)比較慢，這樣會(huì)導(dǎo)致產(chǎn)生大量活躍連接，最終可能會(huì)發(fā)展成無連接可用的后果。

可以采用一主多從，讀寫分離的方案，用多個(gè)從庫分?jǐn)偛樵兞髁俊；蛘卟捎梅謳?水平分表(把一張表的數(shù)據(jù)拆成多張表來存放，比如訂單表可以按 user_id 來拆分)的方案。

第二種：磁盤寫 IO 瓶頸。

由于數(shù)據(jù)庫寫入頻繁，會(huì)產(chǎn)生頻繁的磁盤寫入 IO 操作，頻繁的磁盤 IO 操作導(dǎo)致產(chǎn)生大量活躍連接，最終同樣會(huì)發(fā)展成無連接可用的后果。

這時(shí)只能采用分庫方案，用多個(gè)庫來分?jǐn)倢懭雺毫?。再加上水平分表的策略，分表后，單表存?chǔ)的數(shù)據(jù)量會(huì)更小，插入數(shù)據(jù)時(shí)索引查找和更新的成本會(huì)更低，插入速度自然會(huì)更快。

CPU 瓶頸

SQL 問題：如果 SQL 中包含 join，group by，order by，非索引字段條件查詢等增加 CPU 運(yùn)算的操作，會(huì)對(duì) CPU 產(chǎn)生明顯的壓力。

這時(shí)可以考慮 SQL 優(yōu)化，創(chuàng)建適當(dāng)?shù)乃饕?，也可以把一些?jì)算量大的SQL邏輯放到應(yīng)用中處理。

單表數(shù)據(jù)量太大：由于單張表數(shù)據(jù)量過大，比如超過一億，查詢時(shí)遍歷樹的層次太深或者掃描的行太多，SQL 效率會(huì)很低，也會(huì)非常消耗 CPU。這時(shí)可以根據(jù)業(yè)務(wù)場景水平分表。

分庫分表方案

分庫分表主要有兩種方案：

①利用 MyCat，KingShard 這種代理中間件分庫分表。

好處是和業(yè)務(wù)代碼耦合度很低，只需做一些配置即可，接入成本低。缺點(diǎn)是這種代理中間件需要單獨(dú)部署，所以從調(diào)用連路上又多了一層。

而且分庫分表邏輯完全由代理中間件管理，對(duì)于程序員完全是黑盒，一旦代理本身出問題(比如出錯(cuò)或宕機(jī))，會(huì)導(dǎo)致無法查詢和存儲(chǔ)相關(guān)業(yè)務(wù)數(shù)據(jù)，引發(fā)災(zāi)難性的后果。

如果不熟悉代理中間件源碼，排查問題會(huì)非常困難。曾經(jīng)有公司使用 MyCat，線上發(fā)生故障后，被迫修改方案，三天三夜才恢復(fù)系統(tǒng)。CTO 也廢了!

②利用 Sharding-Jdbc，TSharding 等以 Jar 包形式呈現(xiàn)的輕量級(jí)組件分庫分表。

缺點(diǎn)是，會(huì)有一定的代碼開發(fā)工作量，對(duì)業(yè)務(wù)有一些侵入性。好處是對(duì)程序員透明，程序員對(duì)分庫分表邏輯的把控會(huì)更強(qiáng)，一旦發(fā)生故障，排查問題會(huì)比較容易。

穩(wěn)妥起見，我們選用了第二種方案，使用更輕量級(jí)的 Sharding-Jdbc。

做系統(tǒng)重構(gòu)前，我們首先要確定重構(gòu)的目標(biāo)，其次要對(duì)未來業(yè)務(wù)的發(fā)展有一個(gè)預(yù)期。這個(gè)可以找相關(guān)業(yè)務(wù)負(fù)責(zé)人了解，根據(jù)目標(biāo)和業(yè)務(wù)預(yù)期來確定重構(gòu)方案。

例如，我們希望經(jīng)過本次重構(gòu)，系統(tǒng)能支撐兩年，兩年內(nèi)不再大改。業(yè)務(wù)方預(yù)期兩年內(nèi)日單量達(dá)到 1000 萬，相當(dāng)于兩年后日訂單量要翻 10 倍。

根據(jù)上面的數(shù)據(jù)，我們分成了 16 個(gè)數(shù)據(jù)庫。按日訂單量 1000 萬來算，每個(gè)庫平均的日訂單量就是 62.5 萬(1000 萬/16)，每秒最高訂單量理論上在 1250 左右( 2000*(62.5/100) )。

這樣數(shù)據(jù)庫的壓力基本上是可控的，而且基本不會(huì)浪費(fèi)服務(wù)器資源。

每個(gè)庫分了 16 張表，即便按照每天 1000 萬的訂單量，兩年總單量是 73 億(73 億=1000 萬*365*2)，每個(gè)庫的數(shù)據(jù)量平均是 4.56 億(4.56 億=73 億/16)，每張表的數(shù)據(jù)量平均是 2850 萬(2850 萬=4.56 億/16)。

可以看到未來兩到三年每張表的數(shù)據(jù)量也不算多，完全在可控范圍。

分庫分表主要是為了用戶端下單和查詢使用，按 user_id 的查詢頻率最高，其次是 order_id。

所以我們選擇 user_id 做為 sharding column，按 user_id 做 hash，將相同用戶的訂單數(shù)據(jù)存儲(chǔ)到同一個(gè)數(shù)據(jù)庫的同一張表中。

這樣用戶在網(wǎng)頁或者 App 上查詢訂單時(shí)只需要路由到一張表就可以獲取用戶的所有訂單了，這樣就保證了查詢性能。

另外我們在訂單 ID(order_id)里摻雜了用戶 ID(user_id)信息。

簡單來說，order_id 的設(shè)計(jì)思路就是，將 order_id 分為前后兩部分，前面的部分是 user_id，后面的部分是具體的訂單編號(hào)，兩部分組合在一起就構(gòu)成了 order_id。

這樣我們很容易從 order_id 解析出 user_id。通過 order_id 查詢訂單時(shí)，先從 order_id 中解析出 user_id，然后就可以根據(jù) user_id 路由到具體的庫表了。

另外，數(shù)據(jù)庫分成 16 個(gè)，每個(gè)庫分 16 張表還有一個(gè)好處。16 是 2 的 N 次冪，所以 hash 值對(duì) 16 取模的結(jié)果與 hash 值和 16 按位“與運(yùn)算”的結(jié)果是一樣的。

我們知道位運(yùn)算基于二進(jìn)制，跨過各種編譯和轉(zhuǎn)化直接到最底層的機(jī)器語言，效率自然遠(yuǎn)高于取模運(yùn)算。

有讀者可能會(huì)問，查詢直接查數(shù)據(jù)庫，會(huì)不會(huì)有性能問題?是的。所以我們在上層加了 Redis，Redis 做了分片集群，用于存儲(chǔ)活躍用戶最近 50 條訂單。

這樣一來，只有少部分在 Redis 查不到訂單的用戶請(qǐng)求才會(huì)到數(shù)據(jù)庫查詢訂單，這樣就減小了數(shù)據(jù)庫查詢壓力，而且每個(gè)分庫還有兩個(gè)從庫，查詢操作只走從庫，進(jìn)一步分?jǐn)偭嗣總€(gè)分庫的壓力。

有讀者可能還會(huì)問，為什么沒采用一致性 hash 方案?用戶查詢最近 50 條之前的訂單怎么辦?請(qǐng)繼續(xù)往后看!

管理端技術(shù)方案

分庫分表后，不同用戶的訂單數(shù)據(jù)散落在不同的庫和表中，如果需要根據(jù)用戶 ID 之外的其他條件查詢訂單。

例如，運(yùn)營同學(xué)想從后臺(tái)查出某天 iphone7 的訂單量，就需要從所有數(shù)據(jù)庫的表中查出數(shù)據(jù)然后在聚合到一起。

這樣代碼實(shí)現(xiàn)非常復(fù)雜，而且查詢性能也會(huì)很差。所以我們需要一種更好的方案來解決這個(gè)問題。

我們采用了 ES(ElasticSearch)+HBase 組合的方案，將索引與數(shù)據(jù)存儲(chǔ)隔離。

可能參與條件檢索的字段都會(huì)在 ES 中建一份索引，例如商家，商品名稱，訂單日期等。所有訂單數(shù)據(jù)全量保存到 HBase 中。

我們知道 HBase 支持海量存儲(chǔ)，而且根據(jù) Rowkey 查詢速度超快。而 ES 的多條件檢索能力非常強(qiáng)大。可以說，這個(gè)方案把 ES 和 HBase 的優(yōu)點(diǎn)發(fā)揮地淋漓盡致。

看一下該方案的查詢過程：先根據(jù)輸入條件去 ES 相應(yīng)的索引上查詢符合條件的 Rowkey 值，然后用 Rowkey 值去 HBase 查詢，后面這一步查詢速度極快，查詢時(shí)間幾乎可以忽略不計(jì)。

如下圖：

 

該方案，解決了管理端通過各種字段條件查詢訂單的業(yè)務(wù)需求，同時(shí)也解決了商家端按商家 ID 和其他條件查詢訂單的需求。如果用戶希望查詢最近 50 條訂單之前的歷史訂單，也同樣可以用這個(gè)方案。

每天產(chǎn)生數(shù)百萬的訂單數(shù)據(jù)，如果管理后臺(tái)想查到最新的訂單數(shù)據(jù)，就需要頻繁更新 ES 索引。在海量訂單數(shù)據(jù)的場景下，索引頻繁更新會(huì)不會(huì)對(duì) ES 產(chǎn)生太大壓力?

ES 索引有一個(gè) segment(片段)的概念。ES 把每個(gè)索引分成若干個(gè)較小的 segment 片段。

每一個(gè) segement 都是一個(gè)完整的倒排索引，在搜索查詢時(shí)會(huì)依次掃描相關(guān)索引的所有 segment。

每次 refresh(刷新索引) 的時(shí)候，都會(huì)生成一個(gè)新的 segement，因此 segment 實(shí)際上記錄了索引的一組變化值。由于每次索引刷新只涉及個(gè)別 segement 片段，更新索引的成本就很低了。

所以，即便默認(rèn)的索引刷新(refresh)間隔只有 1 秒鐘，ES 也能從容應(yīng)對(duì)。

不過，由于每個(gè) segement 的存儲(chǔ)和掃描都需要占用一定的內(nèi)存和 CPU 等資源，因此 ES 后臺(tái)進(jìn)程需要不斷的進(jìn)行 segement 合并來減少 segement 的數(shù)量，從而提升掃描效率以及降低資源消耗。

MySQL 中的訂單數(shù)據(jù)需要實(shí)時(shí)同步到 Hbase 和 ES 中，那么同步方案是什么?

我們利用 Canal 實(shí)時(shí)獲取 MySQL 庫表中的增量訂單數(shù)據(jù)，然后把訂單數(shù)據(jù)推到消息隊(duì)列 RocketMQ 中，消費(fèi)端獲取消息后把數(shù)據(jù)寫到 Hbase，并在 ES 更新索引。

 

上面是 Canal 的原理圖：

• Canal 模擬 mysql slave 的交互協(xié)議，把自己偽裝成 mysql 的從庫。
• 向 mysql master 發(fā)送 dump 協(xié)議。
• mysql master 收到 dump 協(xié)議，發(fā)送 binary log 給 slave(Canal)。
• Canal 解析 binary log 字節(jié)流對(duì)象，根據(jù)應(yīng)用場景對(duì) binary log 字節(jié)流做相應(yīng)的處理。

為了保證數(shù)據(jù)一致性，不丟失數(shù)據(jù)。我們使用了 RocketMQ 的事務(wù)型消息，保證消息一定能成功發(fā)送。另外，在 Hbase 和 ES 都操作成功后才做 ack 操作，保證消息正常消費(fèi)。

不停機(jī)數(shù)據(jù)遷移

在互聯(lián)網(wǎng)行業(yè)，很多系統(tǒng)的訪問量很高，即便在凌晨兩三點(diǎn)也有一定的訪問量。由于數(shù)據(jù)遷移導(dǎo)致服務(wù)暫停，是很難被業(yè)務(wù)方接受的!下面就聊一下在用戶無感知的前提下，我們的不停機(jī)數(shù)據(jù)遷移方案!

數(shù)據(jù)遷移過程我們要注意哪些關(guān)鍵點(diǎn)呢?

• 保證遷移后數(shù)據(jù)準(zhǔn)確不丟失，即每條記錄準(zhǔn)確而且不丟失記錄。
• 不影響用戶體驗(yàn)，尤其是訪問量高的 C 端業(yè)務(wù)需要不停機(jī)平滑遷移。
• 保證遷移后的系統(tǒng)性能和穩(wěn)定性。

常用的數(shù)據(jù)遷移方案主要包括：掛從庫，雙寫以及利用數(shù)據(jù)同步工具三種方案，下面分別做一下介紹。

掛從庫

在主庫上建一個(gè)從庫。從庫數(shù)據(jù)同步完成后，將從庫升級(jí)成主庫(新庫)，再將流量切到新庫。

這種方式適合表結(jié)構(gòu)不變，而且空閑時(shí)間段流量很低，允許停機(jī)遷移的場景。一般發(fā)生在平臺(tái)遷移的場景，如從機(jī)房遷移到云平臺(tái)，從一個(gè)云平臺(tái)遷移到另一個(gè)云平臺(tái)。

大部分中小型互聯(lián)網(wǎng)系統(tǒng)，空閑時(shí)段訪問量很低。在空閑時(shí)段，幾分鐘的停機(jī)時(shí)間，對(duì)用戶影響很小，業(yè)務(wù)方是可以接受的。

所以我們可以采用停機(jī)遷移的方案，步驟如下：

• 新建從庫(新數(shù)據(jù)庫)，數(shù)據(jù)開始從主庫向從庫同步。
• 數(shù)據(jù)同步完成后，找一個(gè)空閑時(shí)間段。為了保證主從數(shù)據(jù)庫數(shù)據(jù)一致，需要先停掉服務(wù)，然后再把從庫升級(jí)為主庫。
• 如果訪問數(shù)據(jù)庫用的是域名，直接解析域名到新數(shù)據(jù)庫(從庫升級(jí)成的主庫)，如果訪問數(shù)據(jù)庫用的是 IP，將 IP 改成新數(shù)據(jù)庫 IP。

最后啟動(dòng)服務(wù)，整個(gè)遷移過程完成。

這種遷移方案的優(yōu)勢是遷移成本低，遷移周期短。缺點(diǎn)是，切換數(shù)據(jù)庫過程需要停止服務(wù)。

我們的并發(fā)量比較高，而且又做了分庫分表，表結(jié)構(gòu)也變了，所以不能采取這種方案!

雙寫

老庫和新庫同時(shí)寫入，然后將老數(shù)據(jù)批量遷移到新庫，最后流量切換到新庫并關(guān)閉老庫讀寫。

這種方式適合數(shù)據(jù)結(jié)構(gòu)發(fā)生變化，不允許停機(jī)遷移的場景。一般發(fā)生在系統(tǒng)重構(gòu)時(shí)，表結(jié)構(gòu)發(fā)生變化，如表結(jié)構(gòu)改變或者分庫分表等場景。

有些大型互聯(lián)網(wǎng)系統(tǒng)，平常并發(fā)量很高，即便是空閑時(shí)段也有相當(dāng)?shù)脑L問量。幾分鐘的停機(jī)時(shí)間，對(duì)用戶也會(huì)有明顯的影響，甚至導(dǎo)致一定的用戶流失，這對(duì)業(yè)務(wù)方來說是無法接受的。

所以我們需要考慮一種用戶無感知的不停機(jī)遷移方案，聊一下我們的具體遷移方案，步驟如下：

①代碼準(zhǔn)備。在服務(wù)層對(duì)訂單表進(jìn)行增刪改的地方，要同時(shí)操作新庫(分庫分表后的數(shù)據(jù)庫表)和老庫，需要修改相應(yīng)的代碼(同時(shí)寫新庫和老庫)。

準(zhǔn)備遷移程序腳本，用于做老數(shù)據(jù)遷移。準(zhǔn)備校驗(yàn)程序腳本，用于校驗(yàn)新庫和老庫的數(shù)據(jù)是否一致。

②開啟雙寫，老庫和新庫同時(shí)寫入。

注意：

• 任何對(duì)數(shù)據(jù)庫的增刪改都要雙寫;對(duì)于更新操作，如果新庫沒有相關(guān)記錄，需要先從老庫查出記錄，將更新后的記錄寫入新庫。
• 為了保證寫入性能，老庫寫完后，可以采用消息隊(duì)列異步寫入新庫。

③利用腳本程序，將某一時(shí)間戳之前的老數(shù)據(jù)遷移到新庫。

注意：

• 時(shí)間戳一定要選擇開啟雙寫后的時(shí)間點(diǎn)，比如開啟雙寫后 10 分鐘的時(shí)間點(diǎn)，避免部分老數(shù)據(jù)被漏掉。
• 遷移過程遇到記錄沖突直接忽略，因?yàn)榈?2 步的更新操作，已經(jīng)把記錄拉到了新庫。
• 遷移過程一定要記錄日志，尤其是錯(cuò)誤日志，如果有雙寫失敗的情況，我們可以通過日志恢復(fù)數(shù)據(jù)，以此來保證新老庫的數(shù)據(jù)一致。

④第 3 步完成后，我們還需要通過腳本程序檢驗(yàn)數(shù)據(jù)，看新庫數(shù)據(jù)是否準(zhǔn)確以及有沒有漏掉的數(shù)據(jù)。

⑤數(shù)據(jù)校驗(yàn)沒問題后，開啟雙讀，起初給新庫放少部分流量，新庫和老庫同時(shí)讀取。

由于延時(shí)問題，新庫和老庫可能會(huì)有少量數(shù)據(jù)記錄不一致的情況，所以新庫讀不到時(shí)需要再讀一遍老庫。

⑥然后再逐步將讀流量切到新庫，相當(dāng)于灰度上線的過程。遇到問題可以及時(shí)把流量切回老庫。

⑦讀流量全部切到新庫后，關(guān)閉老庫寫入(可以在代碼里加上熱配置開關(guān))，只寫新庫。

⑧遷移完成，后續(xù)可以去掉雙寫雙讀相關(guān)無用代碼。

利用數(shù)據(jù)同步工具 

我們可以看到上面雙寫的方案比較麻煩，很多數(shù)據(jù)庫寫入的地方都需要修改代碼。有沒有更好的方案呢?

我們還可以利用 Canal，DataBus 等工具做數(shù)據(jù)同步。以阿里開源的 Canal 為例。

利用同步工具，就不需要開啟雙寫了，服務(wù)層也不需要編寫雙寫的代碼，直接用 Canal 做增量數(shù)據(jù)同步即可。

相應(yīng)的步驟就變成了：

①代碼準(zhǔn)備。準(zhǔn)備 Canal 代碼，解析 binary log 字節(jié)流對(duì)象，并把解析好的訂單數(shù)據(jù)寫入新庫。

準(zhǔn)備遷移程序腳本，用于做老數(shù)據(jù)遷移。準(zhǔn)備校驗(yàn)程序腳本，用于校驗(yàn)新庫和老庫的數(shù)據(jù)是否一致。

②運(yùn)行 Canal 代碼，開始增量數(shù)據(jù)(線上產(chǎn)生的新數(shù)據(jù))從老庫到新庫的同步。

③利用腳本程序，將某一時(shí)間戳之前的老數(shù)據(jù)遷移到新庫。注意：時(shí)間戳一定要選擇開始運(yùn)行 Canal 程序后的時(shí)間點(diǎn)(比如運(yùn)行 Canal 代碼后 10 分鐘的時(shí)間點(diǎn))，避免部分老數(shù)據(jù)被漏掉。

遷移過程一定要記錄日志，尤其是錯(cuò)誤日志，如果有些記錄寫入失敗，我們可以通過日志恢復(fù)數(shù)據(jù)，以此來保證新老庫的數(shù)據(jù)一致。

④第 3 步完成后，我們還需要通過腳本程序檢驗(yàn)數(shù)據(jù)，看新庫數(shù)據(jù)是否準(zhǔn)確以及有沒有漏掉的數(shù)據(jù)。

⑤數(shù)據(jù)校驗(yàn)沒問題后，開啟雙讀，起初給新庫放少部分流量，新庫和老庫同時(shí)讀取。

由于延時(shí)問題，新庫和老庫可能會(huì)有少量數(shù)據(jù)記錄不一致的情況，所以新庫讀不到時(shí)需要再讀一遍老庫。

逐步將讀流量切到新庫，相當(dāng)于灰度上線的過程。遇到問題可以及時(shí)把流量切回老庫。

⑥讀流量全部切到新庫后，將寫入流量切到新庫(可以在代碼里加上熱配置開關(guān)：由于切換過程 Canal 程序還在運(yùn)行，仍然能夠獲取老庫的數(shù)據(jù)變化并同步到新庫，所以切換過程不會(huì)導(dǎo)致部分老庫數(shù)據(jù)無法同步新庫的情況)。

⑦關(guān)閉 Canal 程序。

⑧遷移完成。

擴(kuò)容縮容方案

需要對(duì)數(shù)據(jù)重新 hash 取模，再將原來多個(gè)庫表的數(shù)據(jù)寫入擴(kuò)容后的庫表中。整體擴(kuò)容方案和上面的不停機(jī)遷移方案基本一致。采用雙寫或者 Canal 等數(shù)據(jù)同步方案都可以。

更好的分庫分表方案

通過前面的描述，不難看出我們的分庫分表方案有一些缺陷，比如采用 hash 取模的方式會(huì)產(chǎn)生數(shù)據(jù)分布不均勻的情況，擴(kuò)容縮容也非常麻煩。

這些問題可以用一致性 hash 方案解決。基于虛擬節(jié)點(diǎn)設(shè)計(jì)原理的一致性 hash 可以讓數(shù)據(jù)分布更均勻。

而且一致性 hash 采用環(huán)形設(shè)計(jì)思路，在增減節(jié)點(diǎn)時(shí)，使得數(shù)據(jù)遷移的成本會(huì)更低，只需要遷移臨近節(jié)點(diǎn)的數(shù)據(jù)。

不過需要擴(kuò)容時(shí)基本上要成倍擴(kuò)容，在 hash 環(huán)上每個(gè)節(jié)點(diǎn)間隙都增加新的節(jié)點(diǎn)，這樣才能分?jǐn)偹性泄?jié)點(diǎn)的訪問和存儲(chǔ)壓力。

由于篇幅原因，這里不詳細(xì)介紹一致性 hash 了，網(wǎng)上有很多相關(guān)資料，大家有興趣可以仔細(xì)研究一下。

降級(jí)方案

在大促期間訂單服務(wù)壓力過大時(shí)，可以將同步調(diào)用改為異步消息隊(duì)列方式，來減小訂單服務(wù)壓力并提高吞吐量。

大促時(shí)某些時(shí)間點(diǎn)瞬間生成訂單量很高。我們采取異步批量寫數(shù)據(jù)庫的方式，來減少數(shù)據(jù)庫訪問頻次，進(jìn)而降低數(shù)據(jù)庫的寫入壓力。

詳細(xì)步驟：后端服務(wù)接到下單請(qǐng)求，直接放進(jìn)消息隊(duì)列，訂單服務(wù)取出消息后，先將訂單信息寫入 Redis，每隔 100ms 或者積攢 10 條訂單，批量寫入數(shù)據(jù)庫一次。

前端頁面下單后定時(shí)向后端拉取訂單信息，獲取到訂單信息后跳轉(zhuǎn)到支付頁面。

用這種異步批量寫入數(shù)據(jù)庫的方式大幅減少了數(shù)據(jù)庫寫入頻次，從而明顯降低了訂單數(shù)據(jù)庫寫入壓力。

不過，因?yàn)橛唵问钱惒綄懭霐?shù)據(jù)庫的，就會(huì)存在數(shù)據(jù)庫訂單和相應(yīng)庫存數(shù)據(jù)暫時(shí)不一致的情況，以及用戶下單后不能及時(shí)查到訂單的情況。

因?yàn)楫吘故墙导?jí)方案，可以適當(dāng)降低用戶體驗(yàn)，我們保證數(shù)據(jù)最終一致即可。

根據(jù)系統(tǒng)壓力情況，可以在大促開始時(shí)開啟異步批量寫的降級(jí)開關(guān)，大促結(jié)束后再關(guān)閉降級(jí)開關(guān)。

流程如下圖：

 

作者：二馬讀書

編輯：陶家龍

出處：轉(zhuǎn)載自公眾號(hào)二馬讀書(ID：ermadushu)