<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

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

          共 3637字,需瀏覽 8分鐘

           ·

          2020-08-28 16:57

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

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

          什么是“多key”類(lèi)業(yè)務(wù)?
          所謂的“多key”,是指一條元數(shù)據(jù)中,有多個(gè)屬性上存在前臺(tái)在線查詢(xún)需求。

          訂單中心是什么業(yè)務(wù),有什么典型業(yè)務(wù)需求?
          訂單中心是一個(gè)非常常見(jiàn)的“多key”業(yè)務(wù),主要提供訂單的查詢(xún)與修改的服務(wù),其核心元數(shù)據(jù)為:
          Order(oid, buyer_uid, seller_uid, time, money, detail…);
          其中:
          (1)oid為訂單ID,主鍵;
          (2)buyer_uid為買(mǎi)家uid;
          (3)seller_uid為賣(mài)家uid;
          (4)time, money, detail, …等為訂單屬性;

          數(shù)據(jù)庫(kù)設(shè)計(jì)上,一般來(lái)說(shuō)在業(yè)務(wù)初期,單庫(kù),配合查詢(xún)字段上的索引,就能滿(mǎn)足元數(shù)據(jù)存儲(chǔ)與查詢(xún)需求。
          (1)order-center:訂單中心服務(wù),對(duì)調(diào)用者提供友好的RPC接口;
          (2)order-db:對(duì)訂單進(jìn)行數(shù)據(jù)存儲(chǔ),并在訂單,買(mǎi)家,賣(mài)家等字段建立索引;

          隨著訂單量的越來(lái)越大,數(shù)據(jù)庫(kù)需要進(jìn)行水平切分,由于存在多個(gè)key上的查詢(xún)需求,用哪個(gè)字段進(jìn)行切分呢?
          (1)如果用oid來(lái)切分,buyer_uid和seller_uid上的查詢(xún)則需要遍歷多庫(kù);
          (2)如果用buyer_uid或seller_uid來(lái)切分,其他屬性上的查詢(xún)則需要遍歷多庫(kù);

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

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

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

          第一類(lèi),前臺(tái)訪問(wèn),最典型的有三類(lèi)需求:
          (1)訂單實(shí)體查詢(xún):通過(guò)oid查詢(xún)訂單實(shí)體,90%流量屬于這類(lèi)需求;
          (2)用戶(hù)訂單列表查詢(xún):通過(guò)buyer_uid分頁(yè)查詢(xún)用戶(hù)歷史訂單列表,9%流量屬于這類(lèi)需求;
          (3)商家訂單列表查詢(xún):通過(guò)seller_uid分頁(yè)查詢(xún)商家歷史訂單列表,1%流量屬于這類(lèi)需求;

          前臺(tái)訪問(wèn)的特點(diǎn)是什么呢?
          吞吐量大,服務(wù)要求高可用,用戶(hù)對(duì)訂單的訪問(wèn)一致性要求高,商家對(duì)訂單的訪問(wèn)一致性要求相對(duì)較低,可以接受一定時(shí)間的延時(shí)。

          第二類(lèi),后臺(tái)訪問(wèn),根據(jù)產(chǎn)品、運(yùn)營(yíng)需求,訪問(wèn)模式各異:
          (1)按照時(shí)間,價(jià)格,商品,詳情來(lái)進(jìn)行查詢(xún);

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

          這兩類(lèi)不同的業(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)求”的“批量查詢(xún)”的“低效”訪問(wèn),導(dǎo)致數(shù)據(jù)庫(kù)的cpu偶爾瞬時(shí)100%,影響前臺(tái)正常用戶(hù)的訪問(wèn)(例如,訂單查詢(xún)超時(shí))。
          前臺(tái)與后臺(tái)訪問(wèn)的查詢(xú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ù):
          (1)可以去掉service層,在運(yùn)營(yíng)后臺(tái)web層通過(guò)dao直接訪問(wèn)數(shù)據(jù)層;
          (2)可以不需要反向代理,不需要集群冗余;
          (3)可以通過(guò)MQ或者線下異步同步數(shù)據(jù),犧牲一些數(shù)據(jù)的實(shí)時(shí)性;
          (4)可以使用更契合大量數(shù)據(jù)允許接受更高延時(shí)的“索引外置”或者“HIVE”的設(shè)計(jì)方案;

          關(guān)于前臺(tái)與后臺(tái)分離的架構(gòu)設(shè)計(jì),在《用戶(hù)中心,1億數(shù)據(jù)架構(gòu),這次服了》一文中有更為細(xì)致的分析,便不再展開(kāi)。

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

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

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

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

          什么是分庫(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的用戶(hù)下了一個(gè)訂單:
          (1)使用buyer_uid%16分庫(kù),決定這行數(shù)據(jù)要插入到哪個(gè)庫(kù)中;
          (2)分庫(kù)基因是buyer_uid的最后4個(gè)bit,即1010;
          (3)在生成訂單標(biāo)識(shí)oid時(shí),先使用一種分布式ID生成算法生成前60bit(上圖中綠色部分);
          (4)將分庫(kù)基因加入到oid的最后4個(gè)bit(上圖中粉色部分),拼裝成最終64bit的訂單oid(上圖中藍(lán)色部分);

          通過(guò)這種方法保證,同一個(gè)用戶(hù)下的所有訂單oid,都落在同一個(gè)庫(kù)上,oid的最后4個(gè)bit都相同,于是:
          (1)通過(guò)buyer_uid%16能夠定位到庫(kù);
          (2)通過(guò)oid%16也能定位到庫(kù);

          關(guān)于“一對(duì)多”業(yè)務(wù),以及“基因法”,在《帖子中心,1億數(shù)據(jù)架構(gòu),這次服了》一文中有更為細(xì)致的分析,便不再展開(kāi)。

          假設(shè)沒(méi)有oid,應(yīng)該如何擊破buyer_uid和seller_uid的查詢(xún)需求?
          訂單中心,假設(shè)只有buyer_uid和seller_uid上的查詢(xún)需求,就蛻化為一個(gè)“多對(duì)多”的業(yè)務(wù)場(chǎng)景,對(duì)于“多對(duì)多”的業(yè)務(wù),水平切分應(yīng)該使用“數(shù)據(jù)冗余法”。
          如上圖所示:
          (1)當(dāng)有訂單生成時(shí),通過(guò)buyer_uid分庫(kù),oid中融入分庫(kù)基因,寫(xiě)入DB-buyer庫(kù);
          (2)通過(guò)線下異步的方式,通過(guò)binlog+canal,將數(shù)據(jù)冗余到DB-seller庫(kù)中;
          (3)buyer庫(kù)通過(guò)buyer_uid分庫(kù),seller庫(kù)通過(guò)seller_uid分庫(kù),前者滿(mǎn)足oid和buyer_uid的查詢(xún)需求,后者滿(mǎn)足seller_uid的查詢(xún)需求;

          數(shù)據(jù)冗余的方法有很多種:
          (1)服務(wù)同步雙寫(xiě);
          (2)服務(wù)異步雙寫(xiě);
          (3)線下異步雙寫(xiě)(上圖所示,是線下異步雙寫(xiě));

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

          不管哪種方案,因?yàn)閮刹讲僮鞑荒鼙WC原子性,總有出現(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ù)最終一致的常見(jiàn)方案有三種:
          (1)冗余數(shù)據(jù)全量定時(shí)掃描;
          (2)冗余數(shù)據(jù)增量日志掃描;
          (3)冗余數(shù)據(jù)線上消息實(shí)時(shí)檢測(cè);

          關(guān)于“多對(duì)多”業(yè)務(wù),數(shù)據(jù)冗余多種方案,數(shù)據(jù)冗余保證最終一致性多種方案,在《好友中心,1億數(shù)據(jù)架構(gòu),這次服了》一文中有更為細(xì)致的分析,便不再展開(kāi)。

          那如果oid/buyer_uid/seller_uid同時(shí)存在呢?
          綜合上面的解決方案即可:
          (1)如果沒(méi)有seller_uid,“多key”業(yè)務(wù)會(huì)蛻化為“1對(duì)多”業(yè)務(wù),此時(shí)應(yīng)該使用“基因法”分庫(kù):使用buyer_uid分庫(kù),在oid中加入分庫(kù)基因;
          (2)如果沒(méi)有oid,“多key”業(yè)務(wù)會(huì)蛻化為“多對(duì)多”業(yè)務(wù),此時(shí)應(yīng)該使用“數(shù)據(jù)冗余法”分庫(kù):使用buyer_uid和seller_uid來(lái)分別分庫(kù),冗余數(shù)據(jù),滿(mǎn)足不同屬性上的查詢(xún)需求;
          (3)如果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ù)水平切分的常見(jiàn)方案;
          四:數(shù)據(jù)冗余,是解決“多對(duì)多”業(yè)務(wù),數(shù)據(jù)庫(kù)水平切分的常見(jiàn)方案;
          五:最終一致性,是高吞吐互聯(lián)網(wǎng)業(yè)務(wù)一致性的常用實(shí)踐。

          相關(guān)文章
          用戶(hù)中心,1億數(shù)據(jù)架構(gòu),這次服了》
          帖子中心,1億數(shù)據(jù)架構(gòu),這次服了
          好友中心,1億數(shù)據(jù)架構(gòu),這次服了

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

          如果你喜歡這種講技術(shù)的方式,掃碼一起玩。

          有方法論,能落地,視頻講架構(gòu)

          瀏覽 38
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          評(píng)論
          圖片
          表情
          推薦
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  俺去啦电影网 | 久久深爱网 | 欧美成人精品无码 | 91人体视频| 无码欧美日韩二区三区蜜桃 |