日訂單量達(dá)到100萬(wàn)單后,我們做了訂單中心重構(gòu)
掃描二維碼
隨時(shí)隨地手機(jī)看文章
作者簡(jiǎn)介:曾任職于阿里巴巴,每日優(yōu)鮮等互聯(lián)網(wǎng)公司,任技術(shù)總監(jiān)。
最近很多讀者朋友留言,希望“二馬”多寫一些實(shí)際工作經(jīng)歷以及工作中遇到的問(wèn)題和技術(shù)解決方案。應(yīng)大家要求,本文介紹一次訂單中心重構(gòu)的經(jīng)歷。
背景
幾年前我曾經(jīng)服務(wù)過(guò)的一家電商公司,隨著業(yè)務(wù)增長(zhǎng)我們每天的訂單量很快從30萬(wàn)單增長(zhǎng)到了100萬(wàn)單,訂單總量也突破了一億。當(dāng)時(shí)用的Mysql數(shù)據(jù)庫(kù)。根據(jù)監(jiān)控,我們的每秒最高訂單量已經(jīng)達(dá)到了2000筆(不包括秒殺,秒殺TPS已經(jīng)上萬(wàn)了。秒殺我們有一套專門的解決方案,詳見(jiàn)《秒殺系統(tǒng)設(shè)計(jì)~億級(jí)用戶》)。不過(guò),直到此時(shí),訂單系統(tǒng)還是單庫(kù)單表,幸好當(dāng)時(shí)數(shù)據(jù)庫(kù)服務(wù)器配置不錯(cuò),我們的系統(tǒng)才能撐住這么大的壓力。
業(yè)務(wù)量還在快速增長(zhǎng),再不重構(gòu)系統(tǒng)早晚出大事,我們花了一天時(shí)間快速制定了重構(gòu)方案。
重構(gòu)?說(shuō)這么高大上,不就是分庫(kù)分表嗎?的確,就是分庫(kù)分表。不過(guò)除了分庫(kù)分表,還包括管理端的解決方案,比如運(yùn)營(yíng),客服和商務(wù)需要從多維度查詢訂單數(shù)據(jù),分庫(kù)分表后,怎么滿足大家的需求?分庫(kù)分表后,上線方案和數(shù)據(jù)不停機(jī)遷移方案都需要慎重考慮。為了保證系統(tǒng)穩(wěn)定,還需要考慮相應(yīng)的降級(jí)方案。
為什么要分庫(kù)分表?
當(dāng)數(shù)據(jù)庫(kù)產(chǎn)生性能瓶頸:IO瓶頸或CPU瓶頸。兩種瓶頸最終都會(huì)導(dǎo)致數(shù)據(jù)庫(kù)的活躍連接數(shù)增加,進(jìn)而達(dá)到數(shù)據(jù)庫(kù)可承受的最大活躍連接數(shù)閾值。終會(huì)導(dǎo)致應(yīng)用服務(wù)無(wú)連接可用,造成災(zāi)難性后果。可以先從代碼,sql,索引幾方面進(jìn)行優(yōu)化。如果這幾方面已經(jīng)沒(méi)有太多優(yōu)化的余地,就該考慮分庫(kù)分表了。
1、IO瓶頸
-
磁盤讀IO瓶頸。由于熱點(diǎn)數(shù)據(jù)太多,數(shù)據(jù)庫(kù)緩存完全放不下,查詢時(shí)會(huì)產(chǎn)生大量的磁盤IO,查詢速度會(huì)比較慢,這樣會(huì)導(dǎo)致產(chǎn)生大量活躍連接,最終可能會(huì)發(fā)展成無(wú)連接可用的后果。可以采用一主多從,讀寫分離的方案,用多個(gè)從庫(kù)分?jǐn)偛樵兞髁俊;蛘卟捎梅謳?kù)+水平分表(把一張表的數(shù)據(jù)拆成多張表來(lái)存放,比如訂單表可以按user_id來(lái)拆分)的方案。
-
第二種:磁盤寫IO瓶頸。由于數(shù)據(jù)庫(kù)寫入頻繁,會(huì)產(chǎn)生頻繁的磁盤寫入IO操作,頻繁的磁盤IO操作導(dǎo)致產(chǎn)生大量活躍連接,最終同樣會(huì)發(fā)展成無(wú)連接可用的后果。這時(shí)只能采用分庫(kù)方案,用多個(gè)庫(kù)來(lái)分?jǐn)倢懭雺毫?。再加上水平分表的策略,分表后,單表存?chǔ)的數(shù)據(jù)量會(huì)更小,插入數(shù)據(jù)時(shí)索引查找和更新的成本會(huì)更低,插入速度自然會(huì)更快。
2、CPU瓶頸
-
SQL問(wèn)題。如果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ù)量過(guò)大,比如超過(guò)一億,查詢時(shí)遍歷樹(shù)的層次太深或者掃描的行太多,SQL效率會(huì)很低,也會(huì)非常消耗CPU。這時(shí)可以根據(jù)業(yè)務(wù)場(chǎng)景水平分表。
分庫(kù)分表方案
分庫(kù)分表主要有兩種方案:
-
利用MyCat,KingShard這種代理中間件分庫(kù)分表。好處是和業(yè)務(wù)代碼耦合度很低,只需做一些配置即可,接入成本低。缺點(diǎn)是這種代理中間件需要單獨(dú)部署,所以從調(diào)用連路上又多了一層。而且分庫(kù)分表邏輯完全由代理中間件管理,對(duì)于程序員完全是黑盒,一旦代理本身出問(wèn)題(比如出錯(cuò)或宕機(jī)),會(huì)導(dǎo)致無(wú)法查詢和存儲(chǔ)相關(guān)業(yè)務(wù)數(shù)據(jù),引發(fā)災(zāi)難性的后果。如果不熟悉代理中間件源碼,排查問(wèn)題會(huì)非常困難。曾經(jīng)有公司使用MyCat,線上發(fā)生故障后,被迫修改方案,三天三夜才恢復(fù)系統(tǒng)。CTO也廢了!
-
利用Sharding-Jdbc,TSharding等以Jar包形式呈現(xiàn)的輕量級(jí)組件分庫(kù)分表。缺點(diǎn)是,會(huì)有一定的代碼開(kāi)發(fā)工作量,對(duì)業(yè)務(wù)有一些侵入性。好處是對(duì)程序員透明,程序員對(duì)分庫(kù)分表邏輯的把控會(huì)更強(qiáng),一旦發(fā)生故障,排查問(wèn)題會(huì)比較容易。
穩(wěn)妥起見(jiàn),我們選用了第二種方案,使用更輕量級(jí)的Sharding-Jdbc。
做系統(tǒng)重構(gòu)前,我們首先要確定重構(gòu)的目標(biāo),其次要對(duì)未來(lái)業(yè)務(wù)的發(fā)展有一個(gè)預(yù)期,這個(gè)可以找相關(guān)業(yè)務(wù)負(fù)責(zé)人了解。根據(jù)目標(biāo)和業(yè)務(wù)預(yù)期來(lái)確定重構(gòu)方案。例如,我們希望經(jīng)過(guò)本次重構(gòu),系統(tǒng)能支撐兩年,兩年內(nèi)不再大改。業(yè)務(wù)方預(yù)期兩年內(nèi)日單量達(dá)到1000萬(wàn)。相當(dāng)于兩年后日訂單量要翻10倍。
根據(jù)上面的數(shù)據(jù),我們分成了16個(gè)數(shù)據(jù)庫(kù)。按日訂單量1000萬(wàn)來(lái)算,每個(gè)庫(kù)平均的日訂單量就是62.5萬(wàn)(1000萬(wàn)/16),每秒最高訂單量理論上在1250左右( 2000*(62.5/100) )。這樣數(shù)據(jù)庫(kù)的壓力基本上是可控的,而且基本不會(huì)浪費(fèi)服務(wù)器資源。
每個(gè)庫(kù)分了16張表,即便按照每天1000萬(wàn)的訂單量,兩年總單量是73億(73億=1000萬(wàn)*365*2),每個(gè)庫(kù)的數(shù)據(jù)量平均是4.56億(4.56億=73億/16),每張表的數(shù)據(jù)量平均是2850萬(wàn)(2850萬(wàn)=4.56億/16)。可以看到未來(lái)兩到三年每張表的數(shù)據(jù)量也不算多,完全在可控范圍。
分庫(kù)分表主要是為了用戶端下單和查詢使用,按user_id的查詢頻率最高,其次是order_id。所以我們選擇user_id做為sharding column,按user_id做hash,將相同用戶的訂單數(shù)據(jù)存儲(chǔ)到同一個(gè)數(shù)據(jù)庫(kù)的同一張表中。這樣用戶在網(wǎng)頁(yè)或者App上查詢訂單時(shí)只需要路由到一張表就可以獲取用戶的所有訂單了,這樣就保證了查詢性能。
另外我們?cè)谟唵蜪D(order_id)里摻雜了用戶ID(user_id)信息。簡(jiǎn)單來(lái)說(shuō),order_id的設(shè)計(jì)思路就是,將order_id分為前后兩部分,前面的部分是user_id,后面的部分是具體的訂單編號(hào),兩部分組合在一起就構(gòu)成了order_id。這樣我們很容易從order_id解析出user_id。通過(guò)order_id查詢訂單時(shí),先從order_id中解析出user_id,然后就可以根據(jù)user_id路由到具體的庫(kù)表了。
另外,數(shù)據(jù)庫(kù)分成16個(gè),每個(gè)庫(kù)分16張表還有一個(gè)好處。16是2的N次冪,所以hash值對(duì)16取模的結(jié)果與hash值和16按位“與運(yùn)算”的結(jié)果是一樣的。我們知道位運(yùn)算基于二進(jìn)制,跨過(guò)各種編譯和轉(zhuǎn)化直接到最底層的機(jī)器語(yǔ)言,效率自然遠(yuǎn)高于取模運(yùn)算。
有讀者可能會(huì)問(wèn),查詢直接查數(shù)據(jù)庫(kù),會(huì)不會(huì)有性能問(wèn)題?是的。所以我們?cè)谏蠈蛹恿薘edis,Redis做了分片集群,用于存儲(chǔ)活躍用戶最近50條訂單。這樣一來(lái),只有少部分在Redis查不到訂單的用戶請(qǐng)求才會(huì)到數(shù)據(jù)庫(kù)查詢訂單,這樣就減小了數(shù)據(jù)庫(kù)查詢壓力,而且每個(gè)分庫(kù)還有兩個(gè)從庫(kù),查詢操作只走從庫(kù),進(jìn)一步分?jǐn)偭嗣總€(gè)分庫(kù)的壓力。
有讀者可能會(huì)問(wèn),為什么沒(méi)采用一致性hash方案?用戶查詢最近50條之前的訂單怎么辦?請(qǐng)繼續(xù)往后看!
管理端技術(shù)方案
分庫(kù)分表后,不同用戶的訂單數(shù)據(jù)散落在不同的庫(kù)和表中,如果需要根據(jù)用戶ID之外的其他條件查詢訂單。例如,運(yùn)營(yíng)同學(xué)想從后臺(tái)查出某天iphone7的訂單量,就需要從所有數(shù)據(jù)庫(kù)的表中查出數(shù)據(jù)然后在聚合到一起。這樣代碼實(shí)現(xiàn)非常復(fù)雜,而且查詢性能也會(huì)很差。所以我們需要一種更好的方案來(lái)解決這個(gè)問(wèn)題。
我們采用了ES(Elastic Search)+HBase組合的方案,將索引與數(shù)據(jù)存儲(chǔ)隔離。可能參與條件檢索的字段都會(huì)在ES中建一份索引,例如商家,商品名稱,訂單日期等。所有訂單數(shù)據(jù)全量保存到HBase中。我們知道HBase支持海量存儲(chǔ),而且根據(jù)rowkey查詢速度超快。而ES的多條件檢索能力非常強(qiáng)大。可以說(shuō),這個(gè)方案把ES和HBase的優(yōu)點(diǎn)發(fā)揮地淋漓盡致。
看一下該方案的查詢過(guò)程:先根據(jù)輸入條件去ES相應(yīng)的索引上查詢符合條件的rowkey值,然后用rowkey值去HBase查詢,后面這一步查詢速度極快,查詢時(shí)間幾乎可以忽略不計(jì)。如下圖:
該方案,解決了管理端通過(guò)各種字段條件查詢訂單的業(yè)務(wù)需求,同時(shí)也解決了商家端按商家ID和其他條件查詢訂單的需求。如果用戶希望查詢最近50條訂單之前的歷史訂單,也同樣可以用這個(gè)方案。
每天產(chǎn)生數(shù)百萬(wàn)的訂單數(shù)據(jù),如果管理后臺(tái)想查到最新的訂單數(shù)據(jù),就需要頻繁更新ES索引。在海量訂單數(shù)據(jù)的場(chǎng)景下,索引頻繁更新會(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ì)。不過(guò),由于每個(gè) segement 的存儲(chǔ)和掃描都需要占用一定的內(nèi)存和CPU等資源,因此ES后臺(tái)進(jìn)程需要不斷的進(jìn)行segement合并來(lái)減少 segement 的數(shù)量,從而提升掃描效率以及降低資源消耗。
Mysql中的訂單數(shù)據(jù)需要實(shí)時(shí)同步到Hbase和ES中。同步方案是什么?
我們利用Canal實(shí)時(shí)獲取Mysql庫(kù)表中的增量訂單數(shù)據(jù),然后把訂單數(shù)據(jù)推到消息隊(duì)列RocketMQ中,消費(fèi)端獲取消息后把數(shù)據(jù)寫到Hbase,并在ES更新索引。
圖片來(lái)源于網(wǎng)絡(luò)
上面是Canal的原理圖,
1,Canal模擬mysql slave的交互協(xié)議,把自己偽裝成mysql的從庫(kù)
2,向mysql master發(fā)送dump協(xié)議
3. mysql master收到dump協(xié)議,發(fā)送binary log給slave(Canal)
4. Canal解析binary log字節(jié)流對(duì)象,根據(jù)應(yīng)用場(chǎ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)的訪問(wèn)量很高,即便在凌晨?jī)扇c(diǎn)也有一定的訪問(wèn)量。由于數(shù)據(jù)遷移導(dǎo)致服務(wù)暫停,是很難被業(yè)務(wù)方接受的!下面就聊一下在用戶無(wú)感知的前提下,我們的不停機(jī)數(shù)據(jù)遷移方案!
數(shù)據(jù)遷移過(guò)程我們要注意哪些關(guān)鍵點(diǎn)呢?第一,保證遷移后數(shù)據(jù)準(zhǔn)確不丟失,即每條記錄準(zhǔn)確而且不丟失記錄;第二,不影響用戶體驗(yàn),尤其是訪問(wèn)量高的C端業(yè)務(wù)需要不停機(jī)平滑遷移;第三,保證遷移后的系統(tǒng)性能和穩(wěn)定性。
常用的數(shù)據(jù)遷移方案主要包括:掛從庫(kù),雙寫以及利用數(shù)據(jù)同步工具三種方案。下面分別做一下介紹。
掛從庫(kù)
在主庫(kù)上建一個(gè)從庫(kù)。從庫(kù)數(shù)據(jù)同步完成后,將從庫(kù)升級(jí)成主庫(kù)(新庫(kù)),再將流量切到新庫(kù)。
這種方式適合表結(jié)構(gòu)不變,而且空閑時(shí)間段流量很低,允許停機(jī)遷移的場(chǎng)景。一般發(fā)生在平臺(tái)遷移的場(chǎng)景,如從機(jī)房遷移到云平臺(tái),從一個(gè)云平臺(tái)遷移到另一個(gè)云平臺(tái)。大部分中小型互聯(lián)網(wǎng)系統(tǒng),空閑時(shí)段訪問(wèn)量很低。在空閑時(shí)段,幾分鐘的停機(jī)時(shí)間,對(duì)用戶影響很小,業(yè)務(wù)方是可以接受的。所以我們可以采用停機(jī)遷移的方案。步驟如下:
1,新建從庫(kù)(新數(shù)據(jù)庫(kù)),數(shù)據(jù)開(kāi)始從主庫(kù)向從庫(kù)同步。
2,數(shù)據(jù)同步完成后,找一個(gè)空閑時(shí)間段。為了保證主從數(shù)據(jù)庫(kù)數(shù)據(jù)一致,需要先停掉服務(wù),然后再把從庫(kù)升級(jí)為主庫(kù)。如果訪問(wèn)數(shù)據(jù)庫(kù)用的是域名,直接解析域名到新數(shù)據(jù)庫(kù)(從庫(kù)升級(jí)成的主庫(kù)),如果訪問(wèn)數(shù)據(jù)庫(kù)用的是IP,將IP改成新數(shù)據(jù)庫(kù)IP。
3,最后啟動(dòng)服務(wù),整個(gè)遷移過(guò)程完成。
這種遷移方案的優(yōu)勢(shì)是遷移成本低,遷移周期短。缺點(diǎn)是,切換數(shù)據(jù)庫(kù)過(guò)程需要停止服務(wù)。我們的并發(fā)量比較高,而且又做了分庫(kù)分表,表結(jié)構(gòu)也變了,所以不能采取這種方案!
雙寫
老庫(kù)和新庫(kù)同時(shí)寫入,然后將老數(shù)據(jù)批量遷移到新庫(kù),最后流量切換到新庫(kù)并關(guān)閉老庫(kù)讀寫。
這種方式適合數(shù)據(jù)結(jié)構(gòu)發(fā)生變化,不允許停機(jī)遷移的場(chǎng)景。一般發(fā)生在系統(tǒng)重構(gòu)時(shí),表結(jié)構(gòu)發(fā)生變化,如表結(jié)構(gòu)改變或者分庫(kù)分表等場(chǎng)景。有些大型互聯(lián)網(wǎng)系統(tǒng),平常并發(fā)量很高,即便是空閑時(shí)段也有相當(dāng)?shù)脑L問(wèn)量。幾分鐘的停機(jī)時(shí)間,對(duì)用戶也會(huì)有明顯的影響,甚至導(dǎo)致一定的用戶流失,這對(duì)業(yè)務(wù)方來(lái)說(shuō)是無(wú)法接受的。所以我們需要考慮一種用戶無(wú)感知的不停機(jī)遷移方案。
聊一下我們的具體遷移方案,步驟如下:
-
代碼準(zhǔn)備。在服務(wù)層對(duì)訂單表進(jìn)行增刪改的地方,要同時(shí)操作新庫(kù)(分庫(kù)分表后的數(shù)據(jù)庫(kù)表)和老庫(kù),需要修改相應(yīng)的代碼(同時(shí)寫新庫(kù)和老庫(kù))。準(zhǔn)備遷移程序腳本,用于做老數(shù)據(jù)遷移。準(zhǔn)備校驗(yàn)程序腳本,用于校驗(yàn)新庫(kù)和老庫(kù)的數(shù)據(jù)是否一致。
-
開(kāi)啟雙寫,老庫(kù)和新庫(kù)同時(shí)寫入。注意:任何對(duì)數(shù)據(jù)庫(kù)的增刪改都要雙寫;對(duì)于更新操作,如果新庫(kù)沒(méi)有相關(guān)記錄,需要先從老庫(kù)查出記錄,將更新后的記錄寫入新庫(kù);為了保證寫入性能,老庫(kù)寫完后,可以采用消息隊(duì)列異步寫入新庫(kù)。
-
利用腳本程序,將某一時(shí)間戳之前的老數(shù)據(jù)遷移到新庫(kù)。注意:1,時(shí)間戳一定要選擇開(kāi)啟雙寫后的時(shí)間點(diǎn),比如開(kāi)啟雙寫后10分鐘的時(shí)間點(diǎn),避免部分老數(shù)據(jù)被漏掉;2,遷移過(guò)程遇到記錄沖突直接忽略,因?yàn)榈?步的更新操作,已經(jīng)把記錄拉到了新庫(kù);3,遷移過(guò)程一定要記錄日志,尤其是錯(cuò)誤日志,如果有雙寫失敗的情況,我們可以通過(guò)日志恢復(fù)數(shù)據(jù),以此來(lái)保證新老庫(kù)的數(shù)據(jù)一致。
-
第3步完成后,我們還需要通過(guò)腳本程序檢驗(yàn)數(shù)據(jù),看新庫(kù)數(shù)據(jù)是否準(zhǔn)確以及有沒(méi)有漏掉的數(shù)據(jù)
-
數(shù)據(jù)校驗(yàn)沒(méi)問(wèn)題后,開(kāi)啟雙讀,起初給新庫(kù)放少部分流量,新庫(kù)和老庫(kù)同時(shí)讀取。由于延時(shí)問(wèn)題,新庫(kù)和老庫(kù)可能會(huì)有少量數(shù)據(jù)記錄不一致的情況,所以新庫(kù)讀不到時(shí)需要再讀一遍老庫(kù)。然后再逐步將讀流量切到新庫(kù),相當(dāng)于灰度上線的過(guò)程。遇到問(wèn)題可以及時(shí)把流量切回老庫(kù)
-
讀流量全部切到新庫(kù)后,關(guān)閉老庫(kù)寫入(可以在代碼里加上熱配置開(kāi)關(guān)),只寫新庫(kù)
-
遷移完成,后續(xù)可以去掉雙寫雙讀相關(guān)無(wú)用代碼。
利用數(shù)據(jù)同步工具
我們可以看到上面雙寫的方案比較麻煩,很多數(shù)據(jù)庫(kù)寫入的地方都需要修改代碼。有沒(méi)有更好的方案呢?
我們還可以利用Canal,DataBus等工具做數(shù)據(jù)同步。以阿里開(kāi)源的Canal為例。
利用同步工具,就不需要開(kāi)啟雙寫了,服務(wù)層也不需要編寫雙寫的代碼,直接用Canal做增量數(shù)據(jù)同步即可。相應(yīng)的步驟就變成了:
-
代碼準(zhǔn)備。準(zhǔn)備Canal代碼,解析binary log字節(jié)流對(duì)象,并把解析好的訂單數(shù)據(jù)寫入新庫(kù)。準(zhǔn)備遷移程序腳本,用于做老數(shù)據(jù)遷移。準(zhǔn)備校驗(yàn)程序腳本,用于校驗(yàn)新庫(kù)和老庫(kù)的數(shù)據(jù)是否一致。
-
運(yùn)行Canal代碼,開(kāi)始增量數(shù)據(jù)(線上產(chǎn)生的新數(shù)據(jù))從老庫(kù)到新庫(kù)的同步。
-
利用腳本程序,將某一時(shí)間戳之前的老數(shù)據(jù)遷移到新庫(kù)。注意:1,時(shí)間戳一定要選擇開(kāi)始運(yùn)行Canal程序后的時(shí)間點(diǎn)(比如運(yùn)行Canal代碼后10分鐘的時(shí)間點(diǎn)),避免部分老數(shù)據(jù)被漏掉;3,遷移過(guò)程一定要記錄日志,尤其是錯(cuò)誤日志,如果有些記錄寫入失敗,我們可以通過(guò)日志恢復(fù)數(shù)據(jù),以此來(lái)保證新老庫(kù)的數(shù)據(jù)一致。
-
第3步完成后,我們還需要通過(guò)腳本程序檢驗(yàn)數(shù)據(jù),看新庫(kù)數(shù)據(jù)是否準(zhǔn)確以及有沒(méi)有漏掉的數(shù)據(jù)
-
數(shù)據(jù)校驗(yàn)沒(méi)問(wèn)題后,開(kāi)啟雙讀,起初給新庫(kù)放少部分流量,新庫(kù)和老庫(kù)同時(shí)讀取。由于延時(shí)問(wèn)題,新庫(kù)和老庫(kù)可能會(huì)有少量數(shù)據(jù)記錄不一致的情況,所以新庫(kù)讀不到時(shí)需要再讀一遍老庫(kù)。逐步將讀流量切到新庫(kù),相當(dāng)于灰度上線的過(guò)程。遇到問(wèn)題可以及時(shí)把流量切回老庫(kù)
-
讀流量全部切到新庫(kù)后,將寫入流量切到新庫(kù)(可以在代碼里加上熱配置開(kāi)關(guān)。注:由于切換過(guò)程Canal程序還在運(yùn)行,仍然能夠獲取老庫(kù)的數(shù)據(jù)變化并同步到新庫(kù),所以切換過(guò)程不會(huì)導(dǎo)致部分老庫(kù)數(shù)據(jù)無(wú)法同步新庫(kù)的情況)
-
關(guān)閉Canal程序
-
遷移完成。
擴(kuò)容縮容方案
需要對(duì)數(shù)據(jù)重新hash取模,再將原來(lái)多個(gè)庫(kù)表的數(shù)據(jù)寫入擴(kuò)容后的庫(kù)表中。整體擴(kuò)容方案和上面的不停機(jī)遷移方案基本一致。采用雙寫或者Canal等數(shù)據(jù)同步方案都可以。
更好的分庫(kù)分表方案
通過(guò)前面的描述,不難看出我們的分庫(kù)分表方案有一些缺陷,比如采用hash取模的方式會(huì)產(chǎn)生數(shù)據(jù)分布不均勻的情況,擴(kuò)容縮容也非常麻煩。
這些問(wèn)題可以用一致性hash方案解決?;谔摂M節(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ù)。不過(guò)需要擴(kuò)容時(shí)基本上要成倍擴(kuò)容,在hash環(huán)上每個(gè)節(jié)點(diǎn)間隙都增加新的節(jié)點(diǎn),這樣才能分?jǐn)偹性泄?jié)點(diǎn)的訪問(wèn)和存儲(chǔ)壓力。
由于篇幅原因,這里不詳細(xì)介紹一致性hash了,網(wǎng)上有很多相關(guān)資料,大家有興趣可以仔細(xì)研究一下。
降級(jí)方案
在大促期間訂單服務(wù)壓力過(guò)大時(shí),可以將同步調(diào)用改為異步消息隊(duì)列方式,來(lái)減小訂單服務(wù)壓力并提高吞吐量。
大促時(shí)某些時(shí)間點(diǎn)瞬間生成訂單量很高。我們采取異步批量寫數(shù)據(jù)庫(kù)的方式,來(lái)減少數(shù)據(jù)庫(kù)訪問(wèn)頻次,進(jìn)而降低數(shù)據(jù)庫(kù)的寫入壓力。詳細(xì)步驟:后端服務(wù)接到下單請(qǐng)求,直接放進(jìn)消息隊(duì)列,訂單服務(wù)取出消息后,先將訂單信息寫入Redis,每隔100ms或者積攢10條訂單,批量寫入數(shù)據(jù)庫(kù)一次。前端頁(yè)面下單后定時(shí)向后端拉取訂單信息,獲取到訂單信息后跳轉(zhuǎn)到支付頁(yè)面。用這種異步批量寫入數(shù)據(jù)庫(kù)的方式大幅減少了數(shù)據(jù)庫(kù)寫入頻次,從而明顯降低了訂單數(shù)據(jù)庫(kù)寫入壓力。不過(guò),因?yàn)橛唵问钱惒綄懭霐?shù)據(jù)庫(kù)的,就會(huì)存在數(shù)據(jù)庫(kù)訂單和相應(yīng)庫(kù)存數(shù)據(jù)暫時(shí)不一致的情況,以及用戶下單后不能及時(shí)查到訂單的情況。因?yàn)楫吘故墙导?jí)方案,可以適當(dāng)降低用戶體驗(yàn),我們保證數(shù)據(jù)最終一致即可。根據(jù)系統(tǒng)壓力情況,可以在大促開(kāi)始時(shí)開(kāi)啟異步批量寫的降級(jí)開(kāi)關(guān),大促結(jié)束后再關(guān)閉降級(jí)開(kāi)關(guān)。流程如下圖:
免責(zé)聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn),不代表本平臺(tái)立場(chǎng),如有問(wèn)題,請(qǐng)聯(lián)系我們,謝謝!