數(shù)據(jù)庫水平切分架構(gòu)方案

1、 數(shù)據(jù)庫水平切分架構(gòu)方案我是架構(gòu)師 微信號 Architect-msup功能介紹 經(jīng)過多年的積淀，已有互聯(lián)網(wǎng)、金融、電信、能源、制造等領(lǐng)域近千名架構(gòu)師、CTO、開發(fā)人員通過本平臺發(fā)布最前沿的技術(shù)，這里將有各位大牛的干貨分享，相信人人都會有收獲，人人都是架構(gòu)師！數(shù)據(jù)庫水平切分是一個很有意思的話題，不同業(yè)務(wù)類型，數(shù)據(jù)庫水平切分的方法不同。本篇將以“訂單中心”為例，介紹“多key”類業(yè)務(wù)，隨著數(shù)據(jù)量的逐步增大，數(shù)據(jù)庫性能顯著降低，數(shù)據(jù)庫水平切分相關(guān)的架構(gòu)實(shí)踐。一、什么是“多key”類業(yè)務(wù)所謂的“多key”，是指一條元數(shù)據(jù)中，有多個屬性上存在前臺在線查詢需求。訂單中心業(yè)務(wù)分析訂單中心是一個非常常見的“

2、多key”業(yè)務(wù)，主要提供訂單的查詢與修改的服務(wù)，其核心元數(shù)據(jù)為：Order(oid, buyer_uid, seller_uid, time,money, detail);其中：oid為訂單ID，主鍵buyer_uid為買家uidseller_uid為賣家uidtime, money, detail, 等為訂單屬性數(shù)據(jù)庫設(shè)計(jì)上，一般來說在業(yè)務(wù)初期，單庫單表就能夠搞定這個需求，典型的架構(gòu)設(shè)計(jì)為：order-center：訂單中心服務(wù)，對調(diào)用者提供友好的RPC接口order-db：對訂單進(jìn)行數(shù)據(jù)存儲隨著訂單量的越來越大，數(shù)據(jù)庫需要進(jìn)行水平切分，由于存在多個key上的查詢需求，用哪個字段進(jìn)行切分，成

3、了需要解決的關(guān)鍵技術(shù)問題：如果用oid來切分，buyer_uid和seller_uid上的查詢則需要遍歷多庫如果用buyer_uid或seller_uid來切分，其他屬性上的查詢則需要遍歷多庫總之，很難有一個完全之策，在展開技術(shù)方案之前，先一起梳理梳理查詢需求。二、訂單中心屬性查詢需求分析在進(jìn)行架構(gòu)討論之前，先來對業(yè)務(wù)進(jìn)行簡要分析，看哪些屬性上有查詢需求。前臺訪問，最典型的有三類需求:訂單實(shí)體查詢：通過oid查詢訂單實(shí)體，90%流量屬于這類需求用戶訂單列表查詢：通過buyer_uid分頁查詢用戶歷史訂單列表，9%流量屬于這類需求商家訂單列表查詢：通過seller_uid分頁查詢商家歷史訂單列表

4、，1%流量屬于這類需求前臺訪問的特點(diǎn)：吞吐量大，服務(wù)要求高可用，用戶對訂單的訪問一致性要求高，商家對訂單的訪問一致性要求相對較低，可以接受一定時間的延時。后臺訪問，根據(jù)產(chǎn)品、運(yùn)營需求，訪問模式各異:按照時間，架構(gòu)，商品，詳情來進(jìn)行查詢后臺訪問的特點(diǎn)：運(yùn)營側(cè)的查詢基本上是批量分頁的查詢，由于是內(nèi)部系統(tǒng)，訪問量很低，對可用性的要求不高，對一致性的要求也沒這么嚴(yán)格，允許秒級甚至十秒級別的查詢延時。這兩類不同的業(yè)務(wù)需求，應(yīng)該使用什么樣的架構(gòu)方案來解決呢？三、前臺與后臺分離的架構(gòu)設(shè)計(jì)如果前臺業(yè)務(wù)和后臺業(yè)務(wù)公用一批服務(wù)和一個數(shù)據(jù)庫，有可能導(dǎo)致，由于后臺的“少數(shù)幾個請求”的“批量查詢”的“低效”訪問，導(dǎo)致數(shù)

5、據(jù)庫的cpu偶爾瞬時100%，影響前臺正常用戶的訪問（例如，訂單查詢超時）。前臺與后臺訪問的查詢需求不同，對系統(tǒng)的要求也不一樣，故應(yīng)該兩者解耦，實(shí)施“前臺與后臺分離”的架構(gòu)設(shè)計(jì)。前臺業(yè)務(wù)架構(gòu)不變，站點(diǎn)訪問，服務(wù)分層，數(shù)據(jù)庫水平切分。后臺業(yè)務(wù)需求則抽取獨(dú)立的web/service/db來支持，解除系統(tǒng)之間的耦合，對于“業(yè)務(wù)復(fù)雜”“并發(fā)量低”“無需高可用”“能接受一定延時”的后臺業(yè)務(wù)：可以去掉service層，在運(yùn)營后臺web層通過dao直接訪問數(shù)據(jù)層可以不需要反向代理，不需要集群冗余可以通過MQ或者線下異步同步數(shù)據(jù)，犧牲一些數(shù)據(jù)的實(shí)時性可以使用更契合大量數(shù)據(jù)允許接受更高延時的“索引外置”或者“H

6、IVE”的設(shè)計(jì)方案解決了后臺業(yè)務(wù)的訪問需求，問題轉(zhuǎn)化為，前臺的oid，buyer_uid，seller_uid如何來進(jìn)行數(shù)據(jù)庫水平切分呢？多個維度的查詢較為復(fù)雜，對于復(fù)雜系統(tǒng)設(shè)計(jì)，可以逐步簡化。四、假設(shè)沒有seller_uid訂單中心，假設(shè)沒有seller_uid上的查詢需求，而只有oid和buyer_uid上的查詢需求，就蛻化為一個“1對多”的業(yè)務(wù)場景，對于“1對多”的業(yè)務(wù)，水平切分應(yīng)該使用“基因法”。再次回顧一下，什么是分庫基因？通過buyer_uid分庫，假設(shè)分為16個庫，采用buyer_uid%16的方式來進(jìn)行數(shù)據(jù)庫路由，所謂的模16，其本質(zhì)是buyer_uid的最后4個bit決定這行

7、數(shù)據(jù)落在哪個庫上，這4個bit，就是分庫基因。也再次回顧一下，什么是基因法分庫？在訂單數(shù)據(jù)oid生成時，oid末端加入分庫基因，讓同一個buyer_uid下的所有訂單都含有相同基因，落在同一個分庫上。如上圖所示，buyer_uid=666的用戶下了一個訂單：使用buyer_uid%16分庫，決定這行數(shù)據(jù)要插入到哪個庫中分庫基因是buyer_uid的最后4個bit，即1010在生成訂單標(biāo)識oid時，先使用一種分布式ID生成算法生成前60bit（上圖中綠色部分）將分庫基因加入到oid的最后4個bit（上圖中粉色部分），拼裝成最終64bit的訂單oid（上圖中藍(lán)色部分）通過這種方法保證，同一個用戶下

8、的所有訂單oid，都落在同一個庫上，oid的最后4個bit都相同，于是：通過buyer_uid%16能夠定位到庫通過oid%16也能定位到庫五、假設(shè)沒有oid訂單中心，假設(shè)沒有oid上的查詢需求，而只有buyer_uid和seller_uid上的查詢需求，就蛻化為一個“多對多”的業(yè)務(wù)場景，對于“多對多”的業(yè)務(wù)，水平切分應(yīng)該使用“數(shù)據(jù)冗余法”。如上圖所示：當(dāng)有訂單生成時，通過buyer_uid分庫，oid中融入分庫基因，寫入DB-buyer庫通過線下異步的方式，通過binlog+canal，將數(shù)據(jù)冗余到DB-seller庫中buyer庫通過buyer_uid分庫，seller庫通過seller_

9、uid分庫，前者滿足oid和buyer_uid的查詢需求，后者滿足seller_uid的查詢需求數(shù)據(jù)冗余的方法有很多種：服務(wù)同步雙寫服務(wù)異步雙寫線下異步雙寫（上圖所示，是線下異步雙寫）不管哪種方案，因?yàn)閮刹讲僮鞑荒鼙ＷC原子性，總有出現(xiàn)數(shù)據(jù)不一致的可能，高吞吐分布式事務(wù)是業(yè)內(nèi)尚未解決的難題，此時的架構(gòu)優(yōu)化方向，并不是完全保證數(shù)據(jù)的一致，而是盡早的發(fā)現(xiàn)不一致，并修復(fù)不一致。最終一致性，是高吞吐互聯(lián)網(wǎng)業(yè)務(wù)一致性的常用實(shí)踐。保證數(shù)據(jù)最終一致性的方案有三種：冗余數(shù)據(jù)全量定時掃描冗余數(shù)據(jù)增量日志掃描冗余數(shù)據(jù)線上消息實(shí)時檢測這些方案細(xì)節(jié)在“多對多”業(yè)務(wù)水平拆分的文章里詳細(xì)展開分析過，便不再贅述。六、oid/

10、buyer_uid/seller_uid同時存在通過上述分析：如果沒有seller_uid，“多key”業(yè)務(wù)會蛻化為“1對多”業(yè)務(wù)，此時應(yīng)該使用“基因法”分庫：使用buyer_uid分庫，在oid中加入分庫基因如果沒有oid，“多key”業(yè)務(wù)會蛻化為“多對多”業(yè)務(wù)，此時應(yīng)該使用“數(shù)據(jù)冗余法”分庫：使用buyer_uid和seller_uid來分別分庫，冗余數(shù)據(jù)，滿足不同屬性上的查詢需求如果oid/buyer_uid/seller_uid同時存在，可以使用上述兩種方案的綜合方案，來解決“多key”業(yè)務(wù)的數(shù)據(jù)庫水平切分難題七、總結(jié)任何復(fù)雜難題的解決，都是一個化繁為簡，逐步擊破的過程。對于像訂單中心

11、一樣復(fù)雜的“多key”類業(yè)務(wù)，在數(shù)據(jù)量較大，需要對數(shù)據(jù)庫進(jìn)行水平切分時，對于后臺需求，采用“前臺與后臺分離”的架構(gòu)設(shè)計(jì)方法：前臺、后臺系統(tǒng)web/service/db分離解耦，避免后臺低效查詢引發(fā)前臺查詢抖動采用前臺與后臺數(shù)據(jù)冗余的設(shè)計(jì)方式，分別滿足兩側(cè)的需求采用“外置索引”（例如ES搜索系統(tǒng)）或者“大數(shù)據(jù)處理”（例如HIVE）來滿足后臺變態(tài)的查詢需求對于前臺需求，化繁為簡的設(shè)計(jì)思路，將“多key”類業(yè)務(wù)，分解為“1對多”類業(yè)務(wù)和“多對多”類業(yè)務(wù)分別解決：使用“基因法”，解決“1對多”分庫需求：使用buyer_uid分庫，在oid中加入分庫基因，同時滿足oid和buyer_uid上的查詢需求使用“數(shù)據(jù)冗余法”，解決“多對多”分庫需求：使用bu