訂單中心，1億數(shù)據(jù)架構(gòu)，這次服了

這篇文章主要介紹“訂單中心，1億數(shù)據(jù)架構(gòu)，這次服了”，在日常操作中，相信很多人在訂單中心，1億數(shù)據(jù)架構(gòu)，這次服了問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”訂單中心，1億數(shù)據(jù)架構(gòu)，這次服了”的疑惑有所幫助！接下來(lái)，請(qǐng)跟著小編一起來(lái)學(xué)習(xí)吧！

訂單中心，是互聯(lián)網(wǎng)業(yè)務(wù)中，一個(gè)典型的“多key”業(yè)務(wù)，即：用戶ID，商家ID，訂單ID等多個(gè)key上都有業(yè)務(wù)查詢需求。

隨著數(shù)據(jù)量的逐步增大，并發(fā)量的逐步增大，訂單中心這種“多key”業(yè)務(wù)，架構(gòu)應(yīng)該如何設(shè)計(jì)，有哪些因素需要考慮，是本文將要系統(tǒng)性討論的問(wèn)題。

什么是“多key”類業(yè)務(wù)?

所謂的“多key”，是指一條元數(shù)據(jù)中，有多個(gè)屬性上存在前臺(tái)在線查詢需求。

訂單中心是什么業(yè)務(wù)，有什么典型業(yè)務(wù)需求?

訂單中心是一個(gè)非常常見的“多key”業(yè)務(wù)，主要提供訂單的查詢與修改的服務(wù)，其核心元數(shù)據(jù)為：

Order(oid, buyer_uid, seller_uid, time, money, detail…);

其中：

• oid為訂單ID，主鍵;

• buyer_uid為買家uid;

• seller_uid為賣家uid;

• time,  money, detail, …等為訂單屬性;

數(shù)據(jù)庫(kù)設(shè)計(jì)上，一般來(lái)說(shuō)在業(yè)務(wù)初期，單庫(kù)，配合查詢字段上的索引，就能滿足元數(shù)據(jù)存儲(chǔ)與查詢需求。

• order-center：訂單中心服務(wù)，對(duì)調(diào)用者提供友好的RPC接口;

• order-db：對(duì)訂單進(jìn)行數(shù)據(jù)存儲(chǔ)，并在訂單，買家，賣家等字段建立索引;

隨著訂單量的越來(lái)越大，數(shù)據(jù)庫(kù)需要進(jìn)行水平切分，由于存在多個(gè)key上的查詢需求，用哪個(gè)字段進(jìn)行切分呢?

• 如果用oid來(lái)切分，buyer_uid和seller_uid上的查詢則需要遍歷多庫(kù);

• 如果用buyer_uid或seller_uid來(lái)切分，其他屬性上的查詢則需要遍歷多庫(kù);

總之，很難有一個(gè)萬(wàn)全之策，在展開技術(shù)方案之前，先一起梳理梳理查詢需求。

任何脫離業(yè)務(wù)需求的架構(gòu)設(shè)計(jì)，都是耍流氓。

訂單中心，典型業(yè)務(wù)查詢需求有哪些?

第一類，前臺(tái)訪問(wèn)，最典型的有三類需求：

• 訂單實(shí)體查詢：通過(guò)oid查詢訂單實(shí)體，90%流量屬于這類需求;

• 用戶訂單列表查詢：通過(guò)buyer_uid分頁(yè)查詢用戶歷史訂單列表，9%流量屬于這類需求;

• 商家訂單列表查詢：通過(guò)seller_uid分頁(yè)查詢商家歷史訂單列表，1%流量屬于這類需求;

前臺(tái)訪問(wèn)的特點(diǎn)是什么呢?

吞吐量大，服務(wù)要求高可用，用戶對(duì)訂單的訪問(wèn)一致性要求高，商家對(duì)訂單的訪問(wèn)一致性要求相對(duì)較低，可以接受一定時(shí)間的延時(shí)。

第二類，后臺(tái)訪問(wèn)，根據(jù)產(chǎn)品、運(yùn)營(yíng)需求，訪問(wèn)模式各異：

按照時(shí)間，價(jià)格，商品，詳情來(lái)進(jìn)行查詢;

后臺(tái)訪問(wèn)的特點(diǎn)是什么呢?

運(yùn)營(yíng)側(cè)的查詢基本上是批量分頁(yè)的查詢，由于是內(nèi)部系統(tǒng)，訪問(wèn)量很低，對(duì)可用性的要求不高，對(duì)一致性的要求也沒這么嚴(yán)格，允許秒級(jí)甚至十秒級(jí)別的查詢延時(shí)。

這兩類不同的業(yè)務(wù)需求，應(yīng)該使用什么樣的架構(gòu)方案來(lái)解決呢?

要點(diǎn)一：前臺(tái)與后臺(tái)分離的架構(gòu)設(shè)計(jì)。

如果前臺(tái)業(yè)務(wù)和后臺(tái)業(yè)務(wù)共用一批服務(wù)和一個(gè)數(shù)據(jù)庫(kù)，有可能導(dǎo)致，由于后臺(tái)的“少數(shù)幾個(gè)請(qǐng)求”的“批量查詢”的“低效”訪問(wèn)，導(dǎo)致數(shù)據(jù)庫(kù)的cpu偶爾瞬時(shí)100%，影響前臺(tái)正常用戶的訪問(wèn)(例如，訂單查詢超時(shí))。

前臺(tái)與后臺(tái)訪問(wèn)的查詢需求不同，對(duì)系統(tǒng)的要求也不一樣，故應(yīng)該兩者解耦，實(shí)施“前臺(tái)與后臺(tái)分離”的架構(gòu)設(shè)計(jì)。

前臺(tái)業(yè)務(wù)架構(gòu)不變，站點(diǎn)訪問(wèn)，服務(wù)分層，數(shù)據(jù)庫(kù)水平切分。

后臺(tái)業(yè)務(wù)需求則抽取獨(dú)立的web/service/db來(lái)支持，解除系統(tǒng)之間的耦合，對(duì)于“業(yè)務(wù)復(fù)雜”“并發(fā)量低”“無(wú)需高可用”“能接受一定延時(shí)”的后臺(tái)業(yè)務(wù)：

• 可以去掉service層，在運(yùn)營(yíng)后臺(tái)web層通過(guò)dao直接訪問(wèn)數(shù)據(jù)層;

• 可以不需要反向代理，不需要集群冗余;

• 可以通過(guò)MQ或者線下異步同步數(shù)據(jù)，犧牲一些數(shù)據(jù)的實(shí)時(shí)性;

• 可以使用更契合大量數(shù)據(jù)允許接受更高延時(shí)的“索引外置”或者“HIVE”的設(shè)計(jì)方案;

解決完了后臺(tái)業(yè)務(wù)的訪問(wèn)需求，那前臺(tái)的oid，buyer_uid，seller_uid如何來(lái)進(jìn)行數(shù)據(jù)庫(kù)水平切分呢?

要點(diǎn)二：多個(gè)維度的查詢較為復(fù)雜，對(duì)于復(fù)雜系統(tǒng)設(shè)計(jì)，應(yīng)該逐個(gè)擊破。

假設(shè)沒有seller_uid，應(yīng)該如何擊破oid和buyer_uid的查詢需求?訂單中心，假設(shè)只有oid和buyer_uid上的查詢需求，就蛻化為一個(gè)“1對(duì)多”的業(yè)務(wù)場(chǎng)景，對(duì)于“1對(duì)多”的業(yè)務(wù)，水平切分應(yīng)該使用“基因法”。

要點(diǎn)三：基因法，是解決“1對(duì)多”業(yè)務(wù)，數(shù)據(jù)庫(kù)水平切分的常見方案。

什么是分庫(kù)基因?

通過(guò)buyer_uid分庫(kù)，假設(shè)分為16個(gè)庫(kù)，采用buyer_uid%16的方式來(lái)進(jìn)行數(shù)據(jù)庫(kù)路由，所謂的模16，其本質(zhì)是buyer_uid的最后4個(gè)bit決定這行數(shù)據(jù)落在哪個(gè)庫(kù)上，這4個(gè)bit，就是分庫(kù)基因。

什么是基因法分庫(kù)?

在訂單數(shù)據(jù)oid生成時(shí)，oid末端加入分庫(kù)基因，讓同一個(gè)buyer_uid下的所有訂單都含有相同基因，落在同一個(gè)分庫(kù)上。

如上圖所示，buyer_uid=666的用戶下了一個(gè)訂單：

• 使用buyer_uid%16分庫(kù)，決定這行數(shù)據(jù)要插入到哪個(gè)庫(kù)中;

• 分庫(kù)基因是buyer_uid的最后4個(gè)bit，即1010;

• 在生成訂單標(biāo)識(shí)oid時(shí)，先使用一種分布式ID生成算法生成前60bit(上圖中綠色部分);

• 將分庫(kù)基因加入到oid的最后4個(gè)bit(上圖中粉色部分)，拼裝成最終64bit的訂單oid(上圖中藍(lán)色部分);

通過(guò)這種方法保證，同一個(gè)用戶下的所有訂單oid，都落在同一個(gè)庫(kù)上，oid的最后4個(gè)bit都相同，于是：

• 通過(guò)buyer_uid%16能夠定位到庫(kù);

• 通過(guò)oid%16也能定位到庫(kù);

假設(shè)沒有oid，應(yīng)該如何擊破buyer_uid和seller_uid的查詢需求?訂單中心，假設(shè)只有buyer_uid和seller_uid上的查詢需求，就蛻化為一個(gè)“多對(duì)多”的業(yè)務(wù)場(chǎng)景，對(duì)于“多對(duì)多”的業(yè)務(wù)，水平切分應(yīng)該使用“數(shù)據(jù)冗余法”。

如上圖所示：

• 當(dāng)有訂單生成時(shí)，通過(guò)buyer_uid分庫(kù)，oid中融入分庫(kù)基因，寫入DB-buyer庫(kù);

• 通過(guò)線下異步的方式，通過(guò)binlog+canal，將數(shù)據(jù)冗余到DB-seller庫(kù)中;

• buyer庫(kù)通過(guò)buyer_uid分庫(kù)，seller庫(kù)通過(guò)seller_uid分庫(kù)，前者滿足oid和buyer_uid的查詢需求，后者滿足seller_uid的查詢需求;

數(shù)據(jù)冗余的方法有很多種：

• 服務(wù)同步雙寫;

• 服務(wù)異步雙寫;

• 線下異步雙寫(上圖所示，是線下異步雙寫);

要點(diǎn)四：數(shù)據(jù)冗余，是解決“多對(duì)多”業(yè)務(wù)，數(shù)據(jù)庫(kù)水平切分的常見方案。

不管哪種方案，因?yàn)閮刹讲僮鞑荒鼙ＷC原子性，總有出現(xiàn)數(shù)據(jù)不一致的可能，高吞吐分布式事務(wù)是業(yè)內(nèi)尚未解決的難題，此時(shí)的架構(gòu)方向，是最終一致性，并不是完全保證數(shù)據(jù)的一致，而是盡早的發(fā)現(xiàn)不一致，并修復(fù)不一致。

要點(diǎn)五：最終一致性，是高吞吐互聯(lián)網(wǎng)業(yè)務(wù)一致性的常用實(shí)踐。

保證冗余數(shù)據(jù)最終一致的常見方案有三種：

• 冗余數(shù)據(jù)全量定時(shí)掃描;

• 冗余數(shù)據(jù)增量日志掃描;

• 冗余數(shù)據(jù)線上消息實(shí)時(shí)檢測(cè);

那如果oid/buyer_uid/seller_uid同時(shí)存在呢?

綜合上面的解決方案即可：

• 如果沒有seller_uid，“多key”業(yè)務(wù)會(huì)蛻化為“1對(duì)多”業(yè)務(wù)，此時(shí)應(yīng)該使用“基因法”分庫(kù)：使用buyer_uid分庫(kù)，在oid中加入分庫(kù)基因;

• 如果沒有oid，“多key”業(yè)務(wù)會(huì)蛻化為“多對(duì)多”業(yè)務(wù)，此時(shí)應(yīng)該使用“數(shù)據(jù)冗余法”分庫(kù)：使用buyer_uid和seller_uid來(lái)分別分庫(kù)，冗余數(shù)據(jù)，滿足不同屬性上的查詢需求;

• 如果oid/buyer_uid/seller_uid同時(shí)存在，可以使用上述兩種方案的綜合方案，來(lái)解決“多key”業(yè)務(wù)的數(shù)據(jù)庫(kù)水平切分難題;

要點(diǎn)總結(jié)

• 前后臺(tái)差異化需求，可使用前臺(tái)與后臺(tái)分離的架構(gòu)設(shè)計(jì);

• 對(duì)于復(fù)雜系統(tǒng)設(shè)計(jì)，應(yīng)該逐個(gè)擊破;

• 基因法，是解決“1對(duì)多”業(yè)務(wù)，數(shù)據(jù)庫(kù)水平切分的常見方案;

• 數(shù)據(jù)冗余，是解決“多對(duì)多”業(yè)務(wù)，數(shù)據(jù)庫(kù)水平切分的常見方案;

• 最終一致性，是高吞吐互聯(lián)網(wǎng)業(yè)務(wù)一致性的常用實(shí)踐。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文

到此，關(guān)于“訂單中心，1億數(shù)據(jù)架構(gòu)，這次服了”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)?lái)更多實(shí)用的文章！