58沈劍：用uid分庫，uname上的查詢?cè)趺崔k？

作者：58沈劍 2017-04-17 07:00:54

用戶中心是幾乎每一個(gè)公司必備的基礎(chǔ)服務(wù)，當(dāng)數(shù)據(jù)量越來越大時(shí)，需要多用戶中心進(jìn)行水平切分。用uid分庫，如何高效實(shí)現(xiàn)上的查詢，是本文將要討論的問題。

一、緣起

用戶中心是幾乎每一個(gè)公司必備的基礎(chǔ)服務(wù)，用戶注冊(cè)、登錄、信息查詢與修改都離不開用戶中心。

當(dāng)數(shù)據(jù)量越來越大時(shí)，需要多用戶中心進(jìn)行水平切分。最常見的水平切分方式，按照uid取模分庫：

通過uid取模，將數(shù)據(jù)分布到多個(gè)數(shù)據(jù)庫實(shí)例上去，提高服務(wù)實(shí)例個(gè)數(shù)，降低單庫數(shù)據(jù)量，以達(dá)到擴(kuò)容的目的。

水平切分之后：

uid屬性上的查詢可以直接路由到庫，如上圖，假設(shè)訪問uid=124的數(shù)據(jù)，取模后能夠直接定位db-user1。

對(duì)于uname上的查詢，就不能這么幸運(yùn)了：

uname上的查詢，如上圖，假設(shè)訪問uname=shenjian的數(shù)據(jù)，由于不知道數(shù)據(jù)落在哪個(gè)庫上，往往需要遍歷所有庫【掃全庫法】，當(dāng)分庫數(shù)量多起來，性能會(huì)顯著降低。

用uid分庫，如何高效實(shí)現(xiàn)上的查詢，是本文將要討論的問題。

索引表法

思路：uid能直接定位到庫，uname不能直接定位到庫，如果通過uname能查詢到uid，問題解決

解決方案：

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

緩存映射法

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

解決方案：

潛在不足：多一次cache查詢

uname生成uid

思路：不進(jìn)行遠(yuǎn)程查詢，由uname直接得到uid

解決方案：

潛在不足：該函數(shù)設(shè)計(jì)需要非常講究技巧，有uid生成沖突風(fēng)險(xiǎn)

uname基因融入uid

思路：不能用uname生成uid，可以從uname抽取“基因”，融入uid中

假設(shè)分8庫，采用uid%8路由，潛臺(tái)詞是，uid的最后3個(gè)bit決定這條數(shù)據(jù)落在哪個(gè)庫上，這3個(gè)bit就是所謂的“基因”。

解決方案：

在用戶注冊(cè)時(shí)，設(shè)計(jì)函數(shù)uname生成3bit基因，uname_gene=f(uname)，如上圖粉色部分
同時(shí)，生成61bit的全局唯一id，作為用戶的標(biāo)識(shí)，如上圖綠色部分
接著把3bit的uname_gene也作為uid的一部分，如上圖屎黃色部分
生成64bit的uid，由id和uname_gene拼裝而成，并按照uid分庫插入數(shù)據(jù)
用uname來訪問時(shí)，先通過函數(shù)由uname再次復(fù)原3bit基因，uname_gene=f(uname)，通過uname_gene%8直接定位到庫

總結(jié)

業(yè)務(wù)場(chǎng)景：用戶中心，數(shù)據(jù)量大，通過uid分庫后，通過uname路由不到庫

解決方案：

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

責(zé)任編輯：趙寧寧來源： 51CTO專欄