一、背景
幾年前我曾經服務過的一家電商公司，隨着業務增長我們每天的訂單量很快從30萬單增長到了100萬單，訂單總量也突破了一億。
當時用的Mysql數據庫。根據監控，我們的每秒最高訂單量已經達到了2000筆（不包括秒殺，秒殺TPS已經上萬了）。
不過，直到此時，訂單系統還是單庫單表，幸好當時數據庫服務器配置不錯，我們的系統才能撐住這么大的壓力。
業務量還在快速增長，再不重構系統早晚出大事，我們花了一天時間快速制定了重構方案。
重構？說這么高大上，不就是分庫分表嗎？的確，就是分庫分表。不過除了分庫分表，還包括管理端的解決方案，比如運營，客服和商務需要從多維度查詢訂單數據，分庫分表后，怎么滿足大家的需求？
分庫分表后，上線方案和數據不停機遷移方案都需要慎重考慮。為了保證系統穩定，還需要考慮相應的降級方案。
二、為什么要分庫分表？
當數據庫產生性能瓶頸：IO瓶頸或CPU瓶頸。兩種瓶頸最終都會導致數據庫的活躍連接數增加，進而達到數據庫可承受的最大活躍連接數閾值。
終會導致應用服務無連接可用，造成災難性后果。可以先從代碼，sql，索引幾方面進行優化。如果這幾方面已經沒有太多優化的余地，就該考慮分庫分表了。
1、IO瓶頸
磁盤讀IO瓶頸。由於熱點數據太多，數據庫緩存完全放不下，查詢時會產生大量的磁盤IO，查詢速度會比較慢，這樣會導致產生大量活躍連接，最終可能會發展成無連接可用的后果。
可以采用一主多從，讀寫分離的方案，用多個從庫分攤查詢流量。或者采用分庫+水平分表（把一張表的數據拆成多張表來存放，比如訂單表可以按user_id來拆分）的方案。
第二種：磁盤寫IO瓶頸。由於數據庫寫入頻繁，會產生頻繁的磁盤寫入IO操作，頻繁的磁盤IO操作導致產生大量活躍連接，最終同樣會發展成無連接可用的后果。
這時只能采用分庫方案，用多個庫來分攤寫入壓力。再加上水平分表的策略，分表后，單表存儲的數據量會更小，插入數據時索引查找和更新的成本會更低，插入速度自然會更快。
2、CPU瓶頸
SQL問題。如果SQL中包含join，group by，order by，非索引字段條件查詢等增加CPU運算的操作，會對CPU產生明顯的壓力。 這時可以考慮SQL優化，創建適當的索引，也可以把一些計算量大的SQL邏輯放到應用中處理。
單表數據量太大。由於單張表數據量過大，比如超過一億，查詢時遍歷樹的層次太深或者掃描的行太多，SQL效率會很低，也會非常消耗CPU。這時可以根據業務場景水平分表。
三、分庫分表方案
分庫分表主要有兩種方案：
1、利用MyCat，KingShard這種代理中間件分庫分表。好處是和業務代碼耦合度很低，只需做一些配置即可，接入成本低。缺點是這種代理中間件需要單獨部署，所以從調用鏈路上又多了一層。
而且分庫分表邏輯完全由代理中間件管理，對於程序員完全是黑盒，一旦代理本身出問題（比如出錯或宕機），會導致無法查詢和存儲相關業務數據，引發災難性的后果。
如果不熟悉代理中間件源碼，排查問題會非常困難。曾經有公司使用MyCat，線上發生故障后，被迫修改方案，三天三夜才恢復系統。
2、利用Sharding-Jdbc，TSharding等以Jar包形式呈現的輕量級組件分庫分表。缺點是，會有一定的代碼開發工作量，對業務有一些侵入性。
好處是對程序員透明，程序員對分庫分表邏輯的把控會更強，一旦發生故障，排查問題會比較容易。
3、直接使用雲平台的分布式數據庫服務，這些數據庫很多都支持分庫分表。例如，阿里雲的分布式數據庫服務PolarDB-X。優點是基本沒什么接入成本，配置一下，幾乎不用改代碼就可以了。
缺點是分庫分表邏輯都在分布式數據庫服務內部，可靠性完全靠雲平台，萬一出問題你一點辦法都沒有。
穩妥起見，我們選用了第二種方案，使用更輕量級的Sharding-Jdbc。
做系統重構前，我們首先要確定重構的目標，其次要對未來業務的發展有一個預期，這個可以找相關業務負責人了解。
根據目標和業務預期來確定重構方案。例如，我們希望經過本次重構，系統能支撐兩年，兩年內不再大改。業務方預期兩年內日單量達到1000萬。相當於兩年后日訂單量要翻10倍。
根據上面的數據，我們分成了16個數據庫。按日訂單量1000萬來算，每個庫平均的日訂單量就是62.5萬（1000萬/16），每秒最高訂單量理論上在1250左右 2000*（62.5萬/100萬）。
（注：文章前面描述過，100萬是當前每天的訂單量，2000是當前每秒鍾的訂單峰值）。這樣數據庫的壓力基本上是可控的，而且基本不會浪費服務器資源。
每個庫分了16張表，即便按照每天1000萬的訂單量，兩年總單量是73億（73億=1000萬*365*2），每個庫的數據量平均是4.56億（4.56億=73億/16），每張表的數據量平均是2850萬（2850萬=4.56億/16）。
可以看到未來兩到三年每張表的數據量也不算多，完全在可控范圍。
分庫分表主要是為了用戶端下單和查詢使用，按user_id的查詢頻率最高，其次是order_id。所以我們選擇user_id做為sharding column，按user_id做hash，將相同用戶的訂單數據存儲到同一個數據庫的同一張表中。
這樣用戶在網頁或者App上查詢訂單時只需要路由到一張表就可以獲取用戶的所有訂單了，這樣就保證了查詢性能。
另外我們在訂單ID（order_id）里摻雜了用戶ID（user_id）信息。簡單來說，order_id的設計思路就是，將order_id分為前后兩部分，前面的部分是user_id，后面的部分是具體的訂單編號，兩部分組合在一起就構成了order_id。
這樣我們很容易從order_id解析出user_id。通過order_id查詢訂單時，先從order_id中解析出user_id，然后就可以根據user_id路由到具體的庫表了。
另外，數據庫分成16個，每個庫分16張表還有一個好處。16是2的N次冪，所以hash值對16取模的結果與hash值和16按位“與運算”的結果是一樣的。我們知道位運算基於二進制，跨過各種編譯和轉化直接到最底層的機器語言，效率自然遠高於取模運算。
有讀者可能會問，查詢直接查數據庫，會不會有性能問題？是的。所以我們在上層加了Redis，Redis做了分片集群，用於存儲活躍用戶最近50條訂單。
這樣一來，只有少部分在Redis查不到訂單的用戶請求才會到數據庫查詢訂單，這樣就減小了數據庫查詢壓力，而且每個分庫還有兩個從庫，查詢操作只走從庫，進一步分攤了每個分庫的壓力。
有讀者可能會問，為什么沒采用一致性hash方案？用戶查詢最近50條之前的訂單怎么辦？
四、更好的分庫分表方案
通過前面的描述，不難看出我們的分庫分表方案有一些缺陷，比如采用hash取模的方式會產生數據分布不均勻的情況，擴容縮容也非常麻煩。
這些問題可以用一致性hash方案解決。基於虛擬節點設計原理的一致性hash可以讓數據分布更均勻。
而且一致性hash采用環形設計思路，在增減節點時，使得數據遷移的成本會更低，只需要遷移臨近節點的數據。
不過需要擴容時基本上要成倍擴容，在hash環上每個節點間隙都增加新的節點，這樣才能分攤所有原有節點的訪問和存儲壓力。
五、關於數據傾斜問題
分庫分表，采用Hash取模的方式路由庫表，經常會出現數據傾斜問題，比如可能會導致某些表的數據特別多，遠超過其他表。嚴重時，甚至可能影響系統性能和穩定性。
數據傾斜特別嚴重時，就要考慮二次分表了，也就是添加一定數量的表，然后按照相應規則將對應的數據遷移到新表中。
上面我們提到了一致性哈希算法，這里我們就可以利用一致性哈希算法對傾斜的數據表進行二次分表。
首先，一致性哈希算法可以動態添加虛擬節點，在不增加表的情況下，減少數據傾斜。其次，一致性Hash算法在應對增加一張表這種場景時，只會引發部分數據遷移，不會像普通的Hash算法一樣導致需要遷移幾乎所有數據。
如果沒明白上面兩句話的意思，不要緊，繼續往下看。
一致性hash采用環形設計思路，根據節點（庫，表）的Hash值將所有節點映射到Hash環上，在我們查詢和寫入數據時，會根據該數據的Hash值計算出該數據在Hash環上的位置，
然后從該位置開始按順時針方向找到Hash環上最近一個節點，這個節點就是該數據對應的節點（庫，表）。
實際使用中，由於服務器節點數量有限，很有可能出現數據分布不均勻的情況。這個時候會出現大量數據都被映射到某一個節點的情況，
如下圖左側所示。
為了解決這個問題，一致性Hash算法巧妙利用了虛擬節點。虛擬節點是實際節點在Hash環上的復制品，一個實際節點可以對應很多的虛擬節點。虛擬節點越多，Hash環上的節點也就越多，數據分布也會越均勻。
如上圖右側所示，B'、C'、D' 是原始節點復制出來的虛擬節點，原本映射到節點D上的數據1和4，分別被映射到了B'和D'，最終會落到對應的真實節點B和D上。我們可以看到，虛擬節點讓數據分布更均勻了。
如果需要增加新的節點（庫，表）。例如新增了節點D，位置落在數據2和3之間。按照順時針原則，數據2依然在節點C上，而數據3就會路由到節點D。
所以利用一致性Hash算法，在增加節點后我們只需要將很少的數據遷移到新節點上，在這里只需要將C節點的部分數據遷移到D上。
六、管理端技術方案
分庫分表后，不同用戶的訂單數據散落在不同的庫和表中，如果需要根據用戶ID之外的其他條件查詢訂單。
例如，運營同學想從后台查出某天iphone7的訂單量，就需要從所有數據庫的表中查出數據然后在聚合到一起。這樣代碼實現非常復雜，而且查詢性能也會很差。
所以我們需要一種更好的方案來解決這個問題。
我們采用了ES（Elastic Search）+HBase組合的方案，將索引與數據存儲隔離。
可能參與條件檢索的字段都會在ES中建一份索引，例如商家，商品名稱，訂單日期等。所有訂單數據全量保存到HBase中。
我們知道HBase支持海量存儲，而且根據rowkey查詢速度超快。而ES的多條件檢索能力非常強大。可以說，這個方案把ES和HBase的優點發揮地淋漓盡致。
看一下該方案的查詢過程：先根據輸入條件去ES相應的索引上查詢符合條件的rowkey值，然后用rowkey值去HBase查詢，后面這一步查詢速度極快，查詢時間幾乎可以忽略不計。
如下圖：
該方案，解決了管理端通過各種字段條件查詢訂單的業務需求，同時也解決了商家端按商家ID和其他條件查詢訂單的需求。如果用戶希望查詢最近50條訂單之前的歷史訂單，也同樣可以用這個方案。
每天產生數百萬的訂單數據，如果管理后台想查到最新的訂單數據，就需要頻繁更新ES索引。在海量訂單數據的場景下，索引頻繁更新會不會對ES產生太大壓力？
ES索引有一個segment（片段）的概念。ES把每個索引分成若干個較小的 segment 片段。每一個 segement 都是一個完整的倒排索引，在搜索查詢時會依次掃描相關索引的所有 segment。
每次 refresh（刷新索引） 的時候，都會生成一個新的 segement，因此 segment 實際上記錄了索引的一組變化值。由於每次索引刷新只涉及個別segement片段，更新索引的成本就很低了。
所以，即便默認的索引刷新（refresh）間隔只有1秒鍾，ES也能從容應對。
不過，由於每個 segement 的存儲和掃描都需要占用一定的內存和CPU等資源，因此ES后台進程需要不斷的進行segement合並來減少 segement 的數量，從而提升掃描效率以及降低資源消耗。
Mysql中的訂單數據需要實時同步到Hbase和ES中。同步方案是什么？
我們利用Canal實時獲取Mysql庫表中的增量訂單數據，然后把訂單數據推到消息隊列RocketMQ中，消費端獲取消息后把數據寫到Hbase，並在ES更新索引。
上面是Canal的原理圖，
（1）Canal模擬mysql slave的交互協議，把自己偽裝成mysql的從庫；
（2）向mysql master發送dump協議；
（3） mysql master收到dump協議，發送binary log給slave（Canal)；
（4）Canal解析binary log字節流對象，根據應用場景對binary log字節流做相應的處理；
為了保證數據一致性，不丟失數據。我們使用了RocketMQ的事務型消息，保證消息一定能成功發送。另外，在Hbase和ES都操作成功后才做ack操作，保證消息正常消費。
七、不停機數據遷移
在互聯網行業，很多系統的訪問量很高，即便在凌晨兩三點也有一定的訪問量。由於數據遷移導致服務暫停，是很難被業務方接受的！下面就聊一下在用戶無感知的前提下，我們的不停機數據遷移方案！
數據遷移過程我們要注意哪些關鍵點呢？第一，保證遷移后數據准確不丟失，即每條記錄准確而且不丟失記錄；第二，不影響用戶體驗，尤其是訪問量高的C端業務需要不停機平滑遷移；第三，保證遷移后的系統性能和穩定性。
常用的數據遷移方案主要包括：掛從庫，雙寫以及利用數據同步工具三種方案。下面分別做一下介紹。
1、掛從庫
在主庫上建一個從庫。從庫數據同步完成后，將從庫升級成主庫（新庫），再將流量切到新庫。
這種方式適合表結構不變，而且空閑時間段流量很低，允許停機遷移的場景。一般發生在平台遷移的場景，如從機房遷移到雲平台，從一個雲平台遷移到另一個雲平台。
大部分中小型互聯網系統，空閑時段訪問量很低。在空閑時段，幾分鍾的停機時間，對用戶影響很小，業務方是可以接受的。所以我們可以采用停機遷移的方案。步驟如下：
（1）新建從庫（新數據庫），數據開始從主庫向從庫同步。
（2）數據同步完成后，找一個空閑時間段。為了保證主從數據庫數據一致，需要先停掉服務，然后再把從庫升級為主庫。如果訪問數據庫用的是域名，直接解析域名到新數據庫（從庫升級成的主庫），如果訪問數據庫用的是IP，將IP改成新數據庫IP。
（3）最后啟動服務，整個遷移過程完成。
這種遷移方案的優勢是遷移成本低，遷移周期短。缺點是，切換數據庫過程需要停止服務。我們的並發量比較高，而且又做了分庫分表，表結構也變了，所以不能采取這種方案！
2、雙寫
老庫和新庫同時寫入，然后將老數據批量遷移到新庫，最后流量切換到新庫並關閉老庫讀寫。
這種方式適合數據結構發生變化，不允許停機遷移的場景。一般發生在系統重構時，表結構發生變化，如表結構改變或者分庫分表等場景。
有些大型互聯網系統，平常並發量很高，即便是空閑時段也有相當的訪問量。幾分鍾的停機時間，對用戶也會有明顯的影響，甚至導致一定的用戶流失，這對業務方來說是無法接受的。
所以我們需要考慮一種用戶無感知的不停機遷移方案。
聊一下我們的具體遷移方案，步驟如下：
（1）代碼准備。在服務層對訂單表進行增刪改的地方，要同時操作新庫（分庫分表后的數據庫表）和老庫，需要修改相應的代碼（同時寫新庫和老庫）。准備遷移程序腳本，用於做老數據遷移。准備校驗程序腳本，用於校驗新庫和老庫的數據是否一致。
（2）開啟雙寫，老庫和新庫同時寫入。注意：任何對數據庫的增刪改都要雙寫；對於更新操作，如果新庫沒有相關記錄，需要先從老庫查出記錄，將更新后的記錄寫入新庫；為了保證寫入性能，老庫寫完后，可以采用消息隊列異步寫入新庫。
（3）利用腳本程序，將某一時間戳之前的老數據遷移到新庫。
注意：a，時間戳一定要選擇開啟雙寫后的時間點，比如開啟雙寫后10分鍾的時間點，避免部分老數據被漏掉；
b，遷移過程遇到記錄沖突直接忽略，因為第2步的更新操作，已經把記錄拉到了新庫；
c，遷移過程一定要記錄日志，尤其是錯誤日志，如果有雙寫失敗的情況，我們可以通過日志恢復數據，以此來保證新老庫的數據一致。
（4）第3步完成后，我們還需要通過腳本程序檢驗數據，看新庫數據是否准確以及有沒有漏掉的數據
（5）數據校驗沒問題后，開啟雙讀，起初給新庫放少部分流量，新庫和老庫同時讀取。由於延時問題，新庫和老庫可能會有少量數據記錄不一致的情況，所以新庫讀不到時需要再讀一遍老庫。
然后再逐步將讀流量切到新庫，相當於灰度上線的過程。遇到問題可以及時把流量切回老庫
（6）讀流量全部切到新庫后，關閉老庫寫入（可以在代碼里加上熱配置開關），只寫新庫
（7）遷移完成，后續可以去掉雙寫雙讀相關無用代碼。
3、利用數據同步工具
我們可以看到上面雙寫的方案比較麻煩，很多數據庫寫入的地方都需要修改代碼。有沒有更好的方案呢？
我們還可以利用Canal，DataBus等工具做數據同步。以阿里開源的Canal為例。
利用同步工具，就不需要開啟雙寫了，服務層也不需要編寫雙寫的代碼，直接用Canal做增量數據同步即可。相應的步驟就變成了：
（1）代碼准備。准備Canal代碼，解析binary log字節流對象，並把解析好的訂單數據寫入新庫。准備遷移程序腳本，用於做老數據遷移。准備校驗程序腳本，用於校驗新庫和老庫的數據是否一致。
（2）運行Canal代碼，開始增量數據（線上產生的新數據）從老庫到新庫的同步。
（3）利用腳本程序，將某一時間戳之前的老數據遷移到新庫。
注意：a，時間戳一定要選擇開始運行Canal程序后的時間點（比如運行Canal代碼后10分鍾的時間點），避免部分老數據被漏掉；
b，遷移過程一定要記錄日志，尤其是錯誤日志，如果有些記錄寫入失敗，我們可以通過日志恢復數據，以此來保證新老庫的數據一致。
（4）第3步完成后，我們還需要通過腳本程序檢驗數據，看新庫數據是否准確以及有沒有漏掉的數據
（5）數據校驗沒問題后，開啟雙讀，起初給新庫放少部分流量，新庫和老庫同時讀取。由於延時問題，新庫和老庫可能會有少量數據記錄不一致的情況，所以新庫讀不到時需要再讀一遍老庫。
逐步將讀流量切到新庫，相當於灰度上線的過程。遇到問題可以及時把流量切回老庫
（6）讀流量全部切到新庫后，將寫入流量切到新庫（可以在代碼里加上熱配置開關。注：由於切換過程Canal程序還在運行，仍然能夠獲取老庫的數據變化並同步到新庫，所以切換過程不會導致部分老庫數據無法同步新庫的情況）
（7）關閉Canal程序
（8）遷移完成。
九、降級方案
在大促期間訂單服務壓力過大時，可以將同步調用改為異步消息隊列方式，來減小訂單服務壓力並提高吞吐量。
大促時某些時間點瞬間生成訂單量很高。我們采取異步批量寫數據庫的方式，來減少數據庫訪問頻次，進而降低數據庫的寫入壓力。
詳細步驟：后端服務接到下單請求，直接放進消息隊列，訂單服務取出消息后，先將訂單信息寫入Redis，每隔100ms或者積攢10條訂單，批量寫入數據庫一次。
前端頁面下單后定時向后端拉取訂單信息，獲取到訂單信息后跳轉到支付頁面。用這種異步批量寫入數據庫的方式大幅減少了數據庫寫入頻次，從而明顯降低了訂單數據庫寫入壓力。
不過，因為訂單是異步寫入數據庫的，就會存在數據庫訂單和相應庫存數據暫時不一致的情況，以及用戶下單后不能及時查到訂單的情況。
因為畢竟是降級方案，可以適當降低用戶體驗，我們保證數據最終一致即可。根據系統壓力情況，可以在大促開始時開啟異步批量寫的降級開關，大促結束后再關閉降級開關。流程如下圖：
