面試連環炮系列（十七）：你們的項目為什么要分庫分表

1. 你們的項目為什么要分庫分表？
   隨着業務的發展，公司項目的日活翻了幾十倍，訂單表Order每月新增數據100萬左右，有部分場景查詢效率不太高了。通過升級配置、業務規避、緩存集群、歸檔歷史數據等手段，也能夠滿足當前的查詢要求。但是業務是呈加速度增長的，未來的數據會更多。雖然深知過早優化的弊端，但是數據分片一定要做的，不可能等到崩了再做，於是決定分庫分表。

2. 具體怎么實施的，遇到了哪些問題？
   我們采用了中間件Mycat，它是一個數據庫代理，支持多種分片策略。由於只是代理，改造代碼的工作量少一些。我們主要對訂單表order實施分庫分表，一般會有幾個方面的問題要解決：

   • 分布式唯一ID：我們的訂單編號在一開始就是全局唯一ID，采用zookeeper生成的，格式是YYMMDDHHMMSS+ZK自增ID，比如2012091015163000002，所以分布式ID不是問題。
   • 分片策略：我們選擇按Hash取模的方案，比起按范圍分片，這種方式數據分布比較均勻。我們希望此次分片操作能滿足未來五年的數據增長，於是設定數據庫12個，每個庫中有1024個數據表，訂單編號2012091015163000002，按照上述的路由策略，可得：

   中間變量　＝ 2012091015163000002 %（12 * 1024）;
   庫序號　＝　取整（中間變量／1024;
   表序號　＝　中間變量 ％ 1024;
   

   • 查詢改造：由於Mycat不支持某些SQL寫法，比如Order by字段必須出現在select中，要逐一排查改寫。
   • 分布式事務：創建訂單數據的邏輯沒有事務，不存在分布式事務的困擾。
   • 不停機部署上線：在整個改造過程中，我們的系統始終正常運行，保證服務的穩定性和數據的完整性。

3. 詳細說說不停機部署上線怎么做的？

   1. 數據庫雙寫：采用中間件Canal訂閱老庫的增量數據，根據分片規則寫入新庫中。
   2. 遷移歷史數據：根據新庫最小create_time字段划分增量和歷史數據，早於create_time的數據屬於歷史數據，利用遷移工具將數據遷移到新庫中。
   3. 數據一致性：新老數據庫數據總量是否一致。
   4. 改寫后的代碼上生產，並切換新數據源。

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

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