一、緣起

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

當數據量越來越大時，需要多用戶中心進行水平切分。最常見的水平切分方式，按照uid取模分庫：

通過uid取模，將數據分布到多個數據庫實例上去，提高服務實例個數，降低單庫數據量，以達到擴容的目的。

水平切分之后：

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

對于uname上的查詢，就不能這么幸運了：

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

用uid分庫，如何高效實現上的查詢，是本文將要討論的問題。

索引表法

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

解決方案：

• 建立一個索引表記錄uname->uid的映射關系
• 用uname來訪問時，先通過索引表查詢到uid，再定位相應的庫
• 索引表屬性較少，可以容納非常多數據，一般不需要分庫
• 如果數據量過大，可以通過uname來分庫

潛在不足：多一次數據庫查詢，性能下降一倍

緩存映射法

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

解決方案：

• uname查詢先到cache中查詢uid，再根據uid定位數據庫
• 假設cache miss，采用掃全庫法獲取uname對應的uid，放入cache
• uname到uid的映射關系不會變化，映射關系一旦放入緩存，不會更改，無需淘汰，緩存命中率超高
• 如果數據量過大，可以通過name進行cache水平切分

潛在不足：多一次cache查詢

uname生成uid

思路：不進行遠程查詢，由uname直接得到uid

解決方案：

• 在用戶注冊時，設計函數uname生成uid，uid=f(uname)，按uid分庫插入數據
• 用uname來訪問時，先通過函數計算出uid，即uid=f(uname)再來一遍，由uid路由到對應庫

潛在不足：該函數設計需要非常講究技巧，有uid生成沖突風險

uname基因融入uid

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

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

解決方案：

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

總結

業務場景：用戶中心，數據量大，通過uid分庫后，通過uname路由不到庫

解決方案：

• 掃全庫法：遍歷所有庫
• 索引表法：數據庫中記錄uname->uid的映射關系
• 緩存映射法：緩存中記錄uname->uid的映射關系
• uname生成uid
• uname基因融入uid

【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文