用uid分庫，uname上的查詢怎么辦？
用戶中心是幾乎每一個公司必備的基礎(chǔ)服務(wù)，用戶注冊、登錄、信息查詢與修改都離不開用戶中心。
當(dāng)數(shù)據(jù)量越來越大時，需要多用戶中心進(jìn)行水平切分。最常見的水平切分方式，按照uid取模分庫：
通過uid取模，將數(shù)據(jù)分布到多個數(shù)據(jù)庫實例上去，提高服務(wù)實例個數(shù)，降低單庫數(shù)據(jù)量，以達(dá)到擴(kuò)容的目的。
水平切分之后：
uid屬性上的查詢可以直接路由到庫，如上圖，假設(shè)訪問uid=124的數(shù)據(jù)，取模后能夠直接定位db-user1。
對于uname上的查詢，就不能這么幸運了：
uname上的查詢，如上圖，假設(shè)訪問uname=shenjian的數(shù)據(jù)，由于不知道數(shù)據(jù)落在哪個庫上，往往需要遍歷所有庫(掃全庫法)，當(dāng)分庫數(shù)量多起來，性能會顯著降低。
用uid分庫，如何高效實現(xiàn)上的查詢，是本文將要討論的問題。
方案一：索引表法
思路：uid能直接定位到庫，uname不能直接定位到庫，如果通過uname能查詢到uid，問題解決。
解決方案：
(1)建立一個索引表記錄uname到uid的映射關(guān)系;
(2)用uname來訪問時，先通過索引表查詢到uid，再定位相應(yīng)的庫;
(3)索引表屬性較少，可以容納非常多數(shù)據(jù)，一般不需要分庫;
(4)如果數(shù)據(jù)量過大，可以通過uname來分庫;
潛在不足：多一次數(shù)據(jù)庫查詢，性能下降一倍。
方案二：緩存映射法
思路：訪問索引表性能較低，把映射關(guān)系放在緩存里性能更佳。
解決方案：
(1)uname查詢先到cache中查詢uid，再根據(jù)uid定位數(shù)據(jù)庫;
(2)假設(shè)cache miss，采用掃全庫法獲取uname對應(yīng)的uid，放入cache;
(3)uname到uid的映射關(guān)系不會變化，映射關(guān)系一旦放入緩存，不會更改，無需淘汰，緩存命中率超高;
(4)如果數(shù)據(jù)量過大，可以通過name進(jìn)行cache水平切分;
潛在不足：多一次cache查詢。
方案三：uname生成uid
思路：不進(jìn)行遠(yuǎn)程查詢，由uname直接得到uid。
解決方案：
(1)在用戶注冊時，設(shè)計函數(shù)uname生成uid，uid=f(uname)，按uid分庫插入數(shù)據(jù);
(2)用uname來訪問時，先通過函數(shù)計算出uid，即uid=f(uname)再來一遍，由uid路由到對應(yīng)庫;
潛在不足：該函數(shù)設(shè)計需要非常講究技巧，有uid生成沖突風(fēng)險。
方案四：基因法，uname基因融入uid
思路：不能用uname生成uid，可以從uname抽取“基因”，融入uid中。
假設(shè)分8庫，采用uid%8路由，潛臺詞是，uid的最后3個bit決定這條數(shù)據(jù)落在哪個庫上，這3個bit就是所謂的“基因”。
解決方案：
(1)在用戶注冊時，設(shè)計函數(shù)uname生成3bit基因，uname_gene=f(uname)，如上圖粉色部分;
(2)同時，生成61bit的全局唯一id，作為用戶的標(biāo)識，如上圖綠色部分;
(3)接著把3bit的uname_gene也作為uid的一部分，如上圖屎黃色部分;
(4)生成64bit的uid，由id和uname_gene拼裝而成，并按照uid分庫插入數(shù)據(jù);
(5)用uname來訪問時，先通過函數(shù)由uname再次復(fù)原3bit基因，uname_gene=f(uname)，通過uname_gene%8直接定位到庫;
總結(jié)
業(yè)務(wù)場景：用戶中心，數(shù)據(jù)量大，通過uid分庫后，通過uname路由不到庫。
解決方案：
(1)掃全庫法：遍歷所有庫;
(2)索引表法：數(shù)據(jù)庫中記錄uname到uid的映射關(guān)系;
(3)緩存映射法：緩存中記錄uname到uid的映射關(guān)系;
(4)uname生成uid;
(5)基因法：uname基因融入uid;
【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
