【緣起】
使用者中心是幾乎每一個公司必備的基礎服務，使用者注冊、登入、資訊查詢與修改都離不開使用者中心。
當資料量越來越大時，需要多使用者中心進行水準切分。最常見的水準切分方式，按照uid取模分庫：
通過uid取模，将資料分布到多個資料庫執行個體上去，提高服務執行個體個數，降低單庫資料量，以達到擴容的目的。
水準切分之後：
uid屬性上的查詢可以直接路由到庫，如上圖，假設通路uid=124的資料，取模後能夠直接定位db-user1。
對于uname上的查詢，就不能這麼幸運了：
uname上的查詢，如上圖，假設通路uname=shenjian的資料，由于不知道資料落在哪個庫上，往往需要周遊所有庫【掃全庫法】，當分庫數量多起來，性能會顯著降低。
用uid分庫，如何高效實作上的查詢，是本文将要讨論的問題。
【索引表法】
思路：uid能直接定位到庫，uname不能直接定位到庫，如果通過uname能查詢到uid，問題解決
解決方案：
1）建立一個索引表記錄uname->uid的映射關系
2）用uname來通路時，先通過索引表查詢到uid，再定位相應的庫
3）索引表屬性較少，可以容納非常多資料，一般不需要分庫
4）如果資料量過大，可以通過uname來分庫
潛在不足：多一次資料庫查詢，性能下降一倍
【緩存映射法】
思路：通路索引表性能較低，把映射關系放在緩存裡性能更佳
1）uname查詢先到cache中查詢uid，再根據uid定位資料庫
2）假設cache miss，采用掃全庫法擷取uname對應的uid，放入cache
3）uname到uid的映射關系不會變化，映射關系一旦放入緩存，不會更改，無需淘汰，緩存命中率超高
4）如果資料量過大，可以通過name進行cache水準切分
潛在不足：多一次cache查詢
【uname生成uid】
思路：不進行遠端查詢，由uname直接得到uid
1）在使用者注冊時，設計函數uname生成uid，uid=f(uname)，按uid分庫插入資料
2）用uname來通路時，先通過函數計算出uid，即uid=f(uname)再來一遍，由uid路由到對應庫
潛在不足：該函數設計需要非常講究技巧，有uid生成沖突風險
【uname基因融入uid】
思路：不能用uname生成uid，可以從uname抽取“基因”，融入uid中
假設分8庫，采用uid%8路由，潛台詞是，uid的最後3個bit決定這條資料落在哪個庫上，這3個bit就是所謂的“基因”。
1）在使用者注冊時，設計函數uname生成3bit基因，uname_gene=f(uname)，如上圖粉色部分
2）同時，生成61bit的全局唯一id，作為使用者的辨別，如上圖綠色部分
3）接着把3bit的uname_gene也作為uid的一部分，如上圖屎黃色部分
4）生成64bit的uid，由id和uname_gene拼裝而成，并按照uid分庫插入資料
5）用uname來通路時，先通過函數由uname再次複原3bit基因，uname_gene=f(uname)，通過uname_gene%8直接定位到庫
【總結】
業務場景：使用者中心，資料量大，通過uid分庫後，通過uname路由不到庫
1）掃全庫法：周遊所有庫
2）索引表法：資料庫中記錄uname->uid的映射關系
3）緩存映射法：緩存中記錄uname->uid的映射關系
4）uname生成uid
5）uname基因融入uid
==【完】==