當業務資料量非常大，單資料庫無法支撐的時候，有可能是單庫已經寫滿了，也可能資料庫讀寫比較頻繁，已經觸碰到單庫的io瓶頸了，這時就需要考慮分庫，
下面聊一下該怎么分庫，如何優化：
剛開始只有資料庫A, 后來又加了資料庫B，
假如資料表都是有時間戳欄位，而且資料查詢條件都帶一個時間戳欄位，這樣我們可以根據資料創建的時間范圍來分庫，比如給資料庫按年份命名db_2019， 到2020年新生成一個庫db_2020， 在業務端進行資料讀寫操作時，先根據時間戳條件獲取到年份，然后選擇相應年份的資料庫進行操作，
但上面這種方式只適合這種特定的業務場景，而且這種方式，可能舊資料很少讀取，新資料會比較頻繁讀取，會導致不同資料庫負載是不均勻的，所以會不會有更好的分片方式呢？ 答案是肯定的，幾乎任何一張表都會有鍵欄位，假如鍵值是數字型別，可以鍵值與資料庫數量取模的方式進行分片，比如鍵值是100，資料庫數量是2， 那么100%2得到0，就應該存盤到索引為0的資料庫，假如鍵值是字串呢，可以通過crc32(value)算出一個數字，然后再通過數字取模的方式得到相應的資料庫，
假如在使用程序中，資料庫又不夠用了，需要再擴容，怎么辦？
停服，根據新的分片邏輯進行資料遷移，起服上線新的分片邏輯，沒毛病，假如業務允許停機一段時間， 這也是一種穩妥方式，假如業務不允許停機，或只允許停機很短的時間，這時該如何資料庫擴容呢，或者說該如何平滑地進行資料庫遷移而不影響業務呢？
可以通過下面步驟來
方案一：
- 修改寫資料庫邏輯：對需要遷移的資料，進行雙寫（寫原資料庫和要遷往的資料庫）
- 寫一個遷移腳本：從原資料庫遷資料到目標資料庫
- 校驗原資料庫是否跟跟目標資料庫資料一致（在遷移的瞬間可能發生了原資料庫洗掉了資料，而目標資料庫依然寫入），刪掉目標資料庫多余的資料，
- 修改資料庫分片邏輯，去掉雙寫邏輯
- 刪掉各個資料庫冗余的資料
若資料庫雙倍分庫擴容有更好方案
方案二：
- 原資料庫和要遷往的資料庫設計成雙主同步
- 修改資料庫分片邏輯
- 刪掉各個資料庫冗余的資料
后面找個時間再補充一些圖表，以便讀者能更直觀得理解，
還有一些問題：
問題一：假如方案一中，進行雙寫的時候一個寫成功，一個寫失敗，該如何處理？
問題二：分庫后，如何分頁查詢資料？
后面會再寫一篇較大篇幅的文章分析如何跨資料庫分頁查詢資料，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/26009.html
標籤：架構設計
上一篇：k8s~部署EFK框架