數據庫分庫解決方案

當業務數據量很是大，單數據庫沒法支撐的時候，有多是單庫已經寫滿了，也可能數據庫讀寫比較頻繁，已經觸碰到單庫的io瓶頸了，這時就須要考慮分庫。

下面聊一下該怎麼分庫，如何優化：

剛開始只有數據庫A, 後來又加了數據庫B。

假如數據表都是有時間戳字段，並且數據查詢條件都帶一個時間戳字段，這樣咱們能夠根據數據建立的時間範圍來分庫，好比給數據庫按年份命名db_2019， 到2020年新生成一個庫db_2020， 在業務端進行數據讀寫操做時，先根據時間戳條件獲取到年份，而後選擇相應年份的數據庫進行操做。

但上面這種方式只適合這種特定的業務場景，並且這種方式，可能舊數據不多讀取，新數據會比較頻繁讀取，會致使不一樣數據庫負載是不均勻的。因此會不會有更好的分片方式呢？ 答案是確定的。幾乎任何一張表都會有鍵字段，假如鍵值是數字類型，能夠鍵值與數據庫數量取模的方式進行分片，好比鍵值是100，數據庫數量是2， 那麼100%2獲得0，就應該存儲到索引爲0的數據庫。假如鍵值是字符串呢，能夠經過crc32(value)算出一個數字，而後再經過數字取模的方式獲得相應的數據庫。

假如在使用過程當中，數據庫又不夠用了，須要再擴容，怎麼辦？ 

停服，根據新的分片邏輯進行數據遷移，起服上線新的分片邏輯。沒毛病，假如業務容許停機一段時間， 這也是一種穩妥方式。假如業務不容許停機，或只容許停機很短的時間，這時該如何數據庫擴容呢，或者說該如何平滑地進行數據庫遷移而不影響業務呢？

 

能夠經過下面步驟來

方案一：

• 修改寫數據庫邏輯：對須要遷移的數據，進行雙寫（寫原數據庫和要遷往的數據庫）
• 寫一個遷移腳本：從原數據庫遷數據到目標數據庫
• 校驗原數據庫是否跟跟目標數據庫數據一致（在遷移的瞬間可能發生了原數據庫刪除了數據，而目標數據庫依然寫入），刪掉目標數據庫多餘的數據。
• 修改數據庫分片邏輯，去掉雙寫邏輯
• 刪掉各個數據庫冗餘的數據

 

若數據庫雙倍分庫擴容有更好方案

方案二：

• 原數據庫和要遷往的數據庫設計成雙主同步
• 修改數據庫分片邏輯
• 刪掉各個數據庫冗餘的數據

後面找個時間再補充一些圖表，以便讀者能更直觀得理解。

 

還有一些問題：

問題一：假如方案一中，進行雙寫的時候一個寫成功，一個寫失敗，該如何處理？

問題二：分庫後，如何分頁查詢數據？

 

後面會再寫一篇較大篇幅的文章分析如何跨數據庫分頁查詢數據。