單KEY業(yè)務(wù)，數(shù)據(jù)庫(kù)水平切分架構(gòu)實(shí)踐
本文將以“用戶中心”為例，介紹“單KEY”類(lèi)業(yè)務(wù)，隨著數(shù)據(jù)量的逐步增大，數(shù)據(jù)庫(kù)性能顯著降低，數(shù)據(jù)庫(kù)水平切分相關(guān)的架構(gòu)實(shí)踐：
- 如何來(lái)實(shí)施水平切分
- 水平切分后常見(jiàn)的問(wèn)題
- 典型問(wèn)題的優(yōu)化思路及實(shí)踐
一、用戶中心
用戶中心是一個(gè)非常常見(jiàn)的業(yè)務(wù)，主要提供用戶注冊(cè)、登錄、信息查詢(xún)與修改的服務(wù)，其核心元數(shù)據(jù)為：
- User(uid, login_name, passwd, sex, age, nickname, …)
其中：
- uid為用戶ID，主鍵
- login_name, passwd, sex, age, nickname, …等用戶屬性
數(shù)據(jù)庫(kù)設(shè)計(jì)上，一般來(lái)說(shuō)在業(yè)務(wù)初期，單庫(kù)單表就能夠搞定這個(gè)需求，典型的架構(gòu)設(shè)計(jì)為：
- user-center：用戶中心服務(wù)，對(duì)調(diào)用者提供友好的RPC接口
- user-db：對(duì)用戶進(jìn)行數(shù)據(jù)存儲(chǔ)
二、用戶中心水平切分方法
當(dāng)數(shù)據(jù)量越來(lái)越大時(shí)，需要對(duì)數(shù)據(jù)庫(kù)進(jìn)行水平切分，常見(jiàn)的水平切分算法有“范圍法”和“哈希法”。
范圍法，以用戶中心的業(yè)務(wù)主鍵uid為劃分依據(jù)，將數(shù)據(jù)水平切分到兩個(gè)數(shù)據(jù)庫(kù)實(shí)例上去：
- user-db1：存儲(chǔ)0到1千萬(wàn)的uid數(shù)據(jù)
- user-db2：存儲(chǔ)1到2千萬(wàn)的uid數(shù)據(jù)
范圍法的優(yōu)點(diǎn)是：
- 切分策略簡(jiǎn)單，根據(jù)uid，按照范圍，user- center很快能夠定位到數(shù)據(jù)在哪個(gè)庫(kù)上
- 擴(kuò)容簡(jiǎn)單，如果容量不夠，只要增加user-db3即可
范圍法的不足是：
- uid必須要滿足遞增的特性
- 數(shù)據(jù)量不均，新增的user-db3，在初期的數(shù)據(jù)會(huì)比較少
- 請(qǐng)求量不均，一般來(lái)說(shuō)，新注冊(cè)的用戶活躍度會(huì)比較高，故user-db2往往會(huì)比user-db1負(fù)載要高，導(dǎo)致服務(wù)器利用率不平衡
哈希法，也是以用戶中心的業(yè)務(wù)主鍵uid為劃分依據(jù)，將數(shù)據(jù)水平切分到兩個(gè)數(shù)據(jù)庫(kù)實(shí)例上去：
- user-db1：存儲(chǔ)uid取模得1的uid數(shù)據(jù)
- user-db2：存儲(chǔ)uid取模得0的uid數(shù)據(jù)
哈希法的優(yōu)點(diǎn)是：
- 切分策略簡(jiǎn)單，根據(jù)uid，按照hash，user-center很快能夠定位到數(shù)據(jù)在哪個(gè)庫(kù)上
- 數(shù)據(jù)量均衡，只要uid是均勻的，數(shù)據(jù)在各個(gè)庫(kù)上的分布一定是均衡的
- 請(qǐng)求量均衡，只要uid是均勻的，負(fù)載在各個(gè)庫(kù)上的分布一定是均衡的
哈希法的不足是：
- 擴(kuò)容麻煩，如果容量不夠，要增加一個(gè)庫(kù)，重新hash可能會(huì)導(dǎo)致數(shù)據(jù)遷移，如何平滑的進(jìn)行數(shù)據(jù)遷移，是一個(gè)需要解決的問(wèn)題
三、用戶中心水平切分后帶來(lái)的問(wèn)題
使用uid來(lái)進(jìn)行水平切分之后，整個(gè)用戶中心的業(yè)務(wù)訪問(wèn)會(huì)遇到什么問(wèn)題呢?
對(duì)于uid屬性上的查詢(xún)可以直接路由到庫(kù)，假設(shè)訪問(wèn)uid=124的數(shù)據(jù)，取模后能夠直接定位db-user1：
對(duì)于非uid屬性上的查詢(xún)，例如login_name屬性上的查詢(xún)，就悲劇了：
假設(shè)訪問(wèn)login_name=shenjian的數(shù)據(jù)，由于不知道數(shù)據(jù)落在哪個(gè)庫(kù)上，往往需要遍歷所有庫(kù)，當(dāng)分庫(kù)數(shù)量多起來(lái)，性能會(huì)顯著降低。
如何解決分庫(kù)后，非uid屬性上的查詢(xún)問(wèn)題，是后文要重點(diǎn)討論的內(nèi)容。
四、用戶中心非uid屬性查詢(xún)需求分析
任何脫離業(yè)務(wù)的架構(gòu)設(shè)計(jì)都是耍流氓，在進(jìn)行架構(gòu)討論之前，先來(lái)對(duì)業(yè)務(wù)進(jìn)行簡(jiǎn)要分析，看非uid屬性上有哪些查詢(xún)需求。
根據(jù)樓主這些年的架構(gòu)經(jīng)驗(yàn)，用戶中心非uid屬性上經(jīng)常有兩類(lèi)業(yè)務(wù)需求：
(1)用戶側(cè)，前臺(tái)訪問(wèn)，最典型的有兩類(lèi)需求
- 用戶登錄：通過(guò)login_name/phone/email查詢(xún)用戶的實(shí)體，1%請(qǐng)求屬于這種類(lèi)型
- 用戶信息查詢(xún)：登錄之后，通過(guò)uid來(lái)查詢(xún)用戶的實(shí)例，99%請(qǐng)求屬這種類(lèi)型
用戶側(cè)的查詢(xún)基本上是單條記錄的查詢(xún)，訪問(wèn)量較大，服務(wù)需要高可用，并且對(duì)一致性的要求較高。
(2)運(yùn)營(yíng)側(cè)，后臺(tái)訪問(wèn)，根據(jù)產(chǎn)品、運(yùn)營(yíng)需求，訪問(wèn)模式各異，按照年齡、性別、頭像、登陸時(shí)間、注冊(cè)時(shí)間來(lái)進(jìn)行查詢(xún)。
運(yùn)營(yíng)側(cè)的查詢(xún)基本上是批量分頁(yè)的查詢(xún)，由于是內(nèi)部系統(tǒng)，訪問(wèn)量很低，對(duì)可用性的要求不高，對(duì)一致性的要求也沒(méi)這么嚴(yán)格。
這兩類(lèi)不同的業(yè)務(wù)需求，應(yīng)該使用什么樣的架構(gòu)方案來(lái)解決呢?
五、用戶中心水平切分架構(gòu)思路
用戶中心在數(shù)據(jù)量較大的情況下，使用uid進(jìn)行水平切分，對(duì)于非uid屬性上的查詢(xún)需求，架構(gòu)設(shè)計(jì)的核心思路為：
- 針對(duì)用戶側(cè)，應(yīng)該采用“建立非uid屬性到uid的映射關(guān)系”的架構(gòu)方案
- 針對(duì)運(yùn)營(yíng)側(cè)，應(yīng)該采用“前臺(tái)與后臺(tái)分離”的架構(gòu)方案
六、用戶中心-用戶側(cè)最佳實(shí)踐
【索引表法】
思路：uid能直接定位到庫(kù)，login_name不能直接定位到庫(kù)，如果通過(guò)login_name能查詢(xún)到uid，問(wèn)題解決
解決方案：
- 建立一個(gè)索引表記錄login_name->uid的映射關(guān)系
- 用login_name來(lái)訪問(wèn)時(shí)，先通過(guò)索引表查詢(xún)到uid，再定位相應(yīng)的庫(kù)
- 索引表屬性較少，可以容納非常多數(shù)據(jù)，一般不需要分庫(kù)
- 如果數(shù)據(jù)量過(guò)大，可以通過(guò)login_name來(lái)分庫(kù)
潛在不足：多一次數(shù)據(jù)庫(kù)查詢(xún)，性能下降一倍
【緩存映射法】
思路：訪問(wèn)索引表性能較低，把映射關(guān)系放在緩存里性能更佳
解決方案：
- login_name查詢(xún)先到cache中查詢(xún)uid，再根據(jù)uid定位數(shù)據(jù)庫(kù)
- 假設(shè)cache miss，采用掃全庫(kù)法獲取login_name對(duì)應(yīng)的uid，放入cache
- login_name到uid的映射關(guān)系不會(huì)變化，映射關(guān)系一旦放入緩存，不會(huì)更改，無(wú)需淘汰，緩存命中率超高
- 如果數(shù)據(jù)量過(guò)大，可以通過(guò)login_name進(jìn)行cache水平切分
潛在不足：多一次cache查詢(xún)
【login_name生成uid】
思路：不進(jìn)行遠(yuǎn)程查詢(xún)，由login_name直接得到uid
解決方案：
- 在用戶注冊(cè)時(shí)，設(shè)計(jì)函數(shù)login_name生成uid，uid=f(login_name)，按uid分庫(kù)插入數(shù)據(jù)
- 用login_name來(lái)訪問(wèn)時(shí)，先通過(guò)函數(shù)計(jì)算出uid，即uid=f(login_name)再來(lái)一遍，由uid路由到對(duì)應(yīng)庫(kù)
潛在不足：該函數(shù)設(shè)計(jì)需要非常講究技巧，有uid生成沖突風(fēng)險(xiǎn)
【login_name基因融入uid】
思路：不能用login_name生成uid，可以從login_name抽取“基因”，融入uid中
假設(shè)分8庫(kù)，采用uid%8路由，潛臺(tái)詞是，uid的最后3個(gè)bit決定這條數(shù)據(jù)落在哪個(gè)庫(kù)上，這3個(gè)bit就是所謂的“基因”。
解決方案：
- 在用戶注冊(cè)時(shí)，設(shè)計(jì)函數(shù)login_name生成3bit基因，login_name_gene=f(login_name)，如上圖粉色部分
- 同時(shí)，生成61bit的全局唯一id，作為用戶的標(biāo)識(shí)，如上圖綠色部分
- 接著把3bit的login_name_gene也作為uid的一部分，如上圖屎黃色部分
- 生成64bit的uid，由id和login_name_gene拼裝而成，并按照uid分庫(kù)插入數(shù)據(jù)
- 用login_name來(lái)訪問(wèn)時(shí)，先通過(guò)函數(shù)由login_name再次復(fù)原3bit基因，login_name_gene=f(login_name)，通過(guò)login_name_gene%8直接定位到庫(kù)
七、用戶中心-運(yùn)營(yíng)側(cè)最佳實(shí)踐
前臺(tái)用戶側(cè)，業(yè)務(wù)需求基本都是單行記錄的訪問(wèn)，只要建立非uid屬性 login_name / phone / email 到uid的映射關(guān)系，就能解決問(wèn)題。
后臺(tái)運(yùn)營(yíng)側(cè)，業(yè)務(wù)需求各異，基本是批量分頁(yè)的訪問(wèn)，這類(lèi)訪問(wèn)計(jì)算量較大，返回?cái)?shù)據(jù)量較大，比較消耗數(shù)據(jù)庫(kù)性能。
如果此時(shí)前臺(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)正常用戶的訪問(wèn)(例如，登錄超時(shí))。
而且，為了滿足后臺(tái)業(yè)務(wù)各類(lèi)“奇形怪狀”的需求，往往會(huì)在數(shù)據(jù)庫(kù)上建立各種索引，這些索引占用大量?jī)?nèi)存，會(huì)使得用戶側(cè)前臺(tái)業(yè)務(wù)uid/login_name上的查詢(xún)性能與寫(xiě)入性能大幅度降低，處理時(shí)間增長(zhǎng)。
對(duì)于這一類(lèi)業(yè)務(wù)，應(yīng)該采用“前臺(tái)與后臺(tái)分離”的架構(gòu)方案：
用戶側(cè)前臺(tái)業(yè)務(wù)需求架構(gòu)依然不變，產(chǎn)品運(yùn)營(yíng)側(cè)后臺(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)db
- 不需要反向代理，不需要集群冗余
- 不需要訪問(wèn)實(shí)時(shí)庫(kù)，可以通過(guò)MQ或者線下異步同步數(shù)據(jù)
- 在數(shù)據(jù)庫(kù)非常大的情況下，可以使用更契合大量數(shù)據(jù)允許接受更高延時(shí)的“索引外置”或者“HIVE”的設(shè)計(jì)方案
八、總結(jié)
將以“用戶中心”為典型的“單KEY”類(lèi)業(yè)務(wù)，水平切分的架構(gòu)點(diǎn)，本文做了這樣一些介紹。
水平切分方式：
- 范圍法
- 哈希法
水平切分后碰到的問(wèn)題：
- 通過(guò)uid屬性查詢(xún)能直接定位到庫(kù)，通過(guò)非uid屬性查詢(xún)不能定位到庫(kù)
非uid屬性查詢(xún)的典型業(yè)務(wù)：
- 用戶側(cè)，前臺(tái)訪問(wèn)，單條記錄的查詢(xún)，訪問(wèn)量較大，服務(wù)需要高可用，并且對(duì)一致性的要求較高
- 運(yùn)營(yíng)側(cè)，后臺(tái)訪問(wèn)，根據(jù)產(chǎn)品、運(yùn)營(yíng)需求，訪問(wèn)模式各異，基本上是批量分頁(yè)的查詢(xún)，由于是內(nèi)部系統(tǒng)，訪問(wèn)量很低，對(duì)可用性的要求不高，對(duì)一致性的要求也沒(méi)這么嚴(yán)格
這兩類(lèi)業(yè)務(wù)的架構(gòu)設(shè)計(jì)思路：
- 針對(duì)用戶側(cè)，應(yīng)該采用“建立非uid屬性到uid的映射關(guān)系”的架構(gòu)方案
- 針對(duì)運(yùn)營(yíng)側(cè)，應(yīng)該采用“前臺(tái)與后臺(tái)分離”的架構(gòu)方案
用戶前臺(tái)側(cè)，“建立非uid屬性到uid的映射關(guān)系”最佳實(shí)踐：
- 索引表法：數(shù)據(jù)庫(kù)中記錄login_name->uid的映射關(guān)系
- 緩存映射法：緩存中記錄login_name->uid的映射關(guān)系
- login_name生成uid
- login_name基因融入uid
運(yùn)營(yíng)后臺(tái)側(cè)，“前臺(tái)與后臺(tái)分離”最佳實(shí)踐：
- 前臺(tái)、后臺(tái)系統(tǒng)web/service/db分離解耦，避免后臺(tái)低效查詢(xún)引發(fā)前臺(tái)查詢(xún)抖動(dòng)
- 可以采用數(shù)據(jù)冗余的設(shè)計(jì)方式
- 可以采用“外置索引”(例如ES搜索系統(tǒng))或者“大數(shù)據(jù)處理”(例如HIVE)來(lái)滿足后臺(tái)變態(tài)的查詢(xún)需求
【本文為51CTO專(zhuān)欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
