使用者中心是幾乎每乙個公司必備的基礎服務，使用者註冊、登入、資訊查詢與修改都離不開使用者中心。
當資料量越來越大時，需要多使用者中心進行水平切分。最常見的水平切分方式，按照userid取模分庫：
例如：
通過userid取模，將資料分布到多個資料庫例項上去，提高服務例項個數，降低單庫資料量，以達到擴容的目的。
這樣水平切分之後，userid屬性上的查詢可以直接路由到庫，如上圖，假設訪問uid=10的資料，取模後能夠直接定位db1。
但是分庫之後，對於其他欄位的查詢，就不能這麼幸運了。假設訪問username=」lizhi」的資料，由於不知道資料落在哪個庫上，往往需要遍歷所有庫，當分庫數量多起來，效能會顯著降低。
所以我要們尋找如何高效查詢的方法！（以下用username為例）
思路：userid直接定位到庫，username不能直接定位到庫，如果通過username能查詢到userid，問題解決。
解決方案：
1）建立乙個索引表記錄username->userid的對映關係
2）用username來訪問時，先通過索引表查詢到userid，再定位相應的庫
3）索引表屬性較少，可以容納非常多資料，一般不需要分庫
4）如果資料量過大，可以通過username來分庫
潛在不足：多一次資料庫查詢，效能下降一倍。
思路：訪問索引表效能較低，把對映關係放在快取裡效能更佳。
解決方案：
1）username查詢先到cache中查詢userid，再根據userid定位資料庫
2）假設cache miss，採用掃全庫法獲取username對應的userid，放入cache
3）username到userid的對映關係不會變化，對映關係一旦放入快取，不會更改，無需淘汰，快取命中率超高
4）如果資料量過大，可以通過username進行cache水平切分
潛在不足：多一次cache查詢
思路：不進行遠端查詢，由username直接得到userid
解決方案：
1）在使用者註冊時，設計函式username生成userid，userid=f(username)，按userid分庫插入資料
2）用username來訪問時，先通過函式計算出userid，即userid=f(username)再來一遍，由userid路由到對應庫
潛在不足：該函式設計需要非常講究技巧，有userid生成衝突風險
思路：不能用username生成userid，可以從username抽取「基因」，融入userid中
假設分8庫，採用userid%8路由，潛台詞是，userid的最後3個bit決定這條資料落在哪個庫上，這3個bit就是所謂的「基因」。
解決方案：
1）在使用者註冊時，設計函式username生成3bit基因，username_gene=f(username)
2）同時，生成61bit的全域性唯一id，作為使用者的標識
3）接著把3bit的username_gene也作為userid的一部分
4）生成64bit的userid，由id和username_gene拼裝而成，並按照userid庫插入資料
5）用username來訪問時，先通過函式由username再次復原3bit基因，username_gene=f(username)，通過username_gene%8直接定位到庫
談談 分庫 分表 怎麼用
重中之重，什麼是分庫分表？什麼情況下用到分庫分表？其次為分庫分表的方式？怎麼用？二 資料分庫 三 注意點 什麼是？顧名思義，將乙個庫的資料分散到多個庫中，把乙個表的資料分到多個表中儲存。什麼情況下用到？當乙個庫被建立後，隨著時間和業務量的增加，或者業務流量本來就很多的情況下，資料庫中的資料會越來越多...
怎麼進行分庫分表以及資料遷移
已經明白為啥要分庫分表了，你也知道常用的分庫分表中介軟體了，你也設計好你們如何分庫分表的方案了 水平拆分 垂直拆分 分表 那問題來了，你接下來該怎麼把你那個單庫單錶的系統給遷移到分庫分表上去？友情提示 3個庫，每個庫里分了4個表，每個表要放50萬的資料量 假設你已經選擇了乙個分庫分表的資料庫中介軟體...
怎麼才能通過壓力測試？
在學校寫的程式就是玩具。是實驗室才有的東西。實際情況好像差不多。看看我這種人寫的程式。但問題是什麼？缺少實踐，那麼實踐的意義就不只是寫很多的程式，而應該符合實際開發的程式寫了多少！缺少思考，是的，我寫程式好幾年了，雖然都能滿足各種功能的實現，但效能不可而知。資料庫的日誌檔案，吃了興奮劑似得瘋長。事務...