面試連環炮系列（十七）：你們的專案為什么要分庫分表-有解無憂

你們的專案為什么要分庫分表？
隨著業務的發展，公司專案的榷訓翻了幾十倍，訂單表Order每月新增資料100萬左右，有部分場景查詢效率不太高了，通過升級配置、業務規避、快取集群、歸檔歷史資料等手段，也能夠滿足當前的查詢要求，但是業務是呈加速度增長的，未來的資料會更多，雖然深知過早優化的弊端，但是資料分片一定要做的，不可能等到崩了再做，于是決定分庫分表，
具體怎么實施的，遇到了哪些問題？
我們采用了中間件Mycat，它是一個資料庫代理，支持多種分片策略，由于只是代理，改造代碼的作業量少一些，我們主要對訂單表order實施分庫分表，一般會有幾個方面的問題要解決：
- 分布式唯一ID：我們的訂單編號在一開始就是全域唯一ID，采用zookeeper生成的，格式是YYMMDDHHMMSS+ZK自增ID，比如2012091015163000002，所以分布式ID不是問題，
- 分片策略：我們選擇按Hash取模的方案，比起按范圍分片，這種方式資料分布比較均勻，我們希望此次分片操作能滿足未來五年的資料增長，于是設定資料庫12個，每個庫中有1024個資料表，訂單編號2012091015163000002，按照上述的路由策略，可得：
```
中間變數　＝ 2012091015163000002 %（12 * 1024）;
庫序號　＝　取整（中間變數／1024;
表序號　＝　中間變數 ％ 1024;
```
- 查詢改造：由于Mycat不支持某些SQL寫法，比如Order by欄位必須出現在select中，要逐一排查改寫，
- 分布式事務：創建訂單資料的邏輯沒有事務，不存在分布式事務的困擾，
- 不停機部署上線：在整個改造程序中，我們的系統始終正常運行，保證服務的穩定性和資料的完整性，
詳細說說不停機部署上線怎么做的？
1. 資料庫雙寫：采用中間件Canal訂閱老庫的增量資料，根據分片規則寫入新庫中，
2. 遷移歷史資料：根據新庫最小create_time欄位劃分增量和歷史資料，早于create_time的資料屬于歷史資料，利用遷移工具將資料遷移到新庫中，
3. 資料一致性：新老資料庫資料總量是否一致，
4. 改寫后的代碼上生產，并切換新資料源，
Canal的原理你清楚嗎？
canal模擬MySQL slave的互動協議，偽裝自己為MySQL slave，向MySQL master發送dump協議，MySQL master收到dump請求，推送binary log給canal，canal決議binary log物件(原始為byte流)，

參考(摘抄的文字著作權屬于原作者)：

https://blog.csdn.net/Coder_Joker/article/details/82696641
https://blog.csdn.net/qq_41534566/article/details/82758960
https://blog.csdn.net/educast/article/details/50013355
https://www.jianshu.com/p/71f062893d1e
http://www.mamicode.com/info-detail-1682950.html

雞湯：時間真的能改變一個人，比如你以前丑，現在更丑，

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/10544.html

標籤：其他

上一篇：ielts.neea.cn進不去，但ping得通，且網路正常，可能是DNS或wifi的問題，求助

下一篇：決議http2的C++的開源庫