單KEY業(yè)務(wù)，數(shù)據(jù)庫(kù)水平切分架構(gòu)實(shí)踐

提醒，本文較長(zhǎng)，可提前收藏/轉(zhuǎn)發(fā)。

本文將以“用戶中心”為例，介紹“單KEY”類業(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è)、登錄、信息查詢與修改的服務(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屬性上的查詢可以直接路由到庫(kù)，假設(shè)訪問(wèn)uid=124的數(shù)據(jù)，取模后能夠直接定位db-user1： 


對(duì)于非uid屬性上的查詢，例如login_name屬性上的查詢，就悲劇了：

假設(shè)訪問(wèn)login_name=shenjian的數(shù)據(jù)，由于不知道數(shù)據(jù)落在哪個(gè)庫(kù)上，往往需要遍歷所有庫(kù)，當(dāng)分庫(kù)數(shù)量多起來(lái)，性能會(huì)顯著降低。

如何解決分庫(kù)后，非uid屬性上的查詢問(wèn)題，是后文要重點(diǎn)討論的內(nèi)容。

四、用戶中心非uid屬性查詢需求分析

---

任何脫離業(yè)務(wù)的架構(gòu)設(shè)計(jì)都是耍流氓，在進(jìn)行架構(gòu)討論之前，先來(lái)對(duì)業(yè)務(wù)進(jìn)行簡(jiǎn)要分析，看非uid屬性上有哪些查詢需求。

根據(jù)樓主這些年的架構(gòu)經(jīng)驗(yàn)，用戶中心非uid屬性上經(jīng)常有兩類業(yè)務(wù)需求：
（1）用戶側(cè)，前臺(tái)訪問(wèn)，最典型的有兩類需求
用戶登錄：通過(guò)login_name/phone/email查詢用戶的實(shí)體，1%請(qǐng)求屬于這種類型
用戶信息查詢：登錄之后，通過(guò)uid來(lái)查詢用戶的實(shí)例，99%請(qǐng)求屬這種類型

用戶側(cè)的查詢基本上是單條記錄的查詢，訪問(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)行查詢。

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

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

五、用戶中心水平切分架構(gòu)思路

---

用戶中心在數(shù)據(jù)量較大的情況下，使用uid進(jìn)行水平切分，對(duì)于非uid屬性上的查詢需求，架構(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能查詢到uid，問(wèn)題解決

解決方案：
?建立一個(gè)索引表記錄login_name->uid的映射關(guān)系
?用login_name來(lái)訪問(wèn)時(shí)，先通過(guò)索引表查詢到uid，再定位相應(yīng)的庫(kù)
?索引表屬性較少，可以容納非常多數(shù)據(jù)，一般不需要分庫(kù)
?如果數(shù)據(jù)量過(guò)大，可以通過(guò)login_name來(lái)分庫(kù)

潛在不足：多一次數(shù)據(jù)庫(kù)查詢，性能下降一倍

【緩存映射法】

思路：訪問(wèn)索引表性能較低，把映射關(guān)系放在緩存里性能更佳

解決方案：
?login_name查詢先到cache中查詢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查詢

【login_name生成uid】

思路：不進(jìn)行遠(yuǎ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)，這類訪問(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)求”的“批量查詢”的“低效”訪問(wèn)，導(dǎo)致數(shù)據(jù)庫(kù)的cpu偶爾瞬時(shí)100%，影響前臺(tái)正常用戶的訪問(wèn)（例如，登錄超時(shí)）。

而且，為了滿足后臺(tái)業(yè)務(wù)各類“奇形怪狀”的需求，往往會(huì)在數(shù)據(jù)庫(kù)上建立各種索引，這些索引占用大量?jī)?nèi)存，會(huì)使得用戶側(cè)前臺(tái)業(yè)務(wù)uid/login_name上的查詢性能與寫入性能大幅度降低，處理時(shí)間增長(zhǎng)。

對(duì)于這一類業(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”類業(yè)務(wù)，水平切分的架構(gòu)點(diǎn)，本文做了這樣一些介紹。

水平切分方式：
?范圍法
?哈希法

水平切分后碰到的問(wèn)題：
?通過(guò)uid屬性查詢能直接定位到庫(kù)，通過(guò)非uid屬性查詢不能定位到庫(kù)

非uid屬性查詢的典型業(yè)務(wù)：
?用戶側(cè)，前臺(tái)訪問(wèn)，單條記錄的查詢，訪問(wèn)量較大，服務(wù)需要高可用，并且對(duì)一致性的要求較高
?運(yùn)營(yíng)側(cè)，后臺(tái)訪問(wèn)，根據(jù)產(chǎn)品、運(yùn)營(yíng)需求，訪問(wèn)模式各異，基本上是批量分頁(yè)的查詢，由于是內(nèi)部系統(tǒng)，訪問(wèn)量很低，對(duì)可用性的要求不高，對(duì)一致性的要求也沒(méi)這么嚴(yán)格

這兩類業(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)低效查詢引發(fā)前臺(tái)查詢抖動(dòng)
?可以采用數(shù)據(jù)冗余的設(shè)計(jì)方式
?可以采用“外置索引”（例如ES搜索系統(tǒng)）或者“大數(shù)據(jù)處理”（例如HIVE）來(lái)滿足后臺(tái)變態(tài)的查詢需求

其他類型業(yè)務(wù)的水平切分架構(gòu)方案，未來(lái)和大家聊。