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

當用戶中心單庫數據量越來越大時，怎么辦？

單庫存不下，水平切分，用多庫。

用什么業務屬性水平切分？

主鍵uid。

如何進行數據路由？

uid取模直接路由，例如：

如上圖所示，假設訪問uid=124的數據，取模后能夠直接路由db1。

那對于登錄名uname上的查詢怎么辦？

方案一：掃全庫法。

如上圖所示，假設訪問uname=shenjian的數據，由于不知道數據落在哪個庫上，往往需要遍歷所有庫。

其潛在不足是：當分庫數量多起來，性能會顯著降低。

還有沒有其他更加高效的方法呢？

常見的方案有以下幾種。

方案二：索引表法。

其設計思路是：uid能直接路由到庫，uname不能直接路由到庫，如果通過uname能查詢到uid，則問題解決。

其具體步驟是：

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

其潛在不足是：增加了一次數據庫查詢。

方案三：緩存映射法。

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

其具體步驟是：

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

其潛在不足是：增加了一次cache查詢。

方案四：uname生成uid。

其設計思路是：無需遠程查詢，本地計算由uname直接得到uid。

其具體步驟是：

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

如何設計單向函數，通過uname來生成uid？

最簡單的單向函數是MD5：

• 如果uid是128bit的，uid=MD5(uname);
• 如果uid是64bit的，uid=MD5(uname)/2；

畫外音，128bit折半的方法有很多，例如：取前一半，或者取后一半，或者前一半與后一半異或。

其潛在不足是：當用戶量非常巨大的時候，有uid沖突的風險，需要一個補丁機制，來解決沖突問題。

方案五：基因法。

其設計思路是：不用uname生成uid，從uname抽取“基因”，融入uid中。

什么是uname基因，如何將基因融入uid？

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

其具體步驟是：

• 在用戶注冊時，設計單向函數uname生成3bit基因，uname_gene=f(uname)，如上圖粉色部分；
• 同時，使用ID生成器生成全局唯一uid的前61bit，如上圖綠色部分；
• 把前61bit與后3bit基因組合，生成64bit的最終uid，并用最終uid水平切分數據；
• 用uname來訪問時，先通過單向函數由uname再次復原3bit基因，uname_gene=f(uname)，通過uname_gene%8直接路由到庫；

如何設計單向函數，通過uname來生成基因？

uname_gene=MD5(uname)再取最后3bit。

會不會導致數據分布不均勻？

不會，MD5具備完全隨機性。

其潛在不足是：

• uid一旦生成就無法更改，需要提前規劃基因位數，例如：10年內最多分256庫，提前預留8bit基因位；
• 登錄名不允許修改（該前提一般都滿足）；
• uid確定以后，登錄名以外的郵箱登陸，手機號登陸不能復用；

畫外音：郵箱登陸，手機號登陸可使用通用方案2與方案3。

稍作總結

使用uid分庫，uname查詢有五種方法：

• 掃全庫法：遍歷所有庫；
• 索引表法：數據庫中記錄uname到uid的映射關系；
• 緩存映射法：緩存中記錄uname到uid的映射關系；
• uname單向函數生成uid：小概率沖突；
• 基因法：uname單向函數生成基因融入uid，需要提前規劃基因位數；

知其然，知其所以然。

思路比結論更重要。