京東一元搶寶系統的數據庫架構優化
本文是根據凱明在京東內部進行的#京東技術節#《一元搶寶分庫分別策略與實現》技術分享整理而成。
一元搶寶系統是京東虛擬新興的一個業務系統，上線以來訂單量一直持續增長。在距離618前兩個月時，京東商城商品虛擬研發部對系統做了整體預估，訂單量快速增長及618大促的到來都將帶來單量劇增，屆時勢必會對數據庫容量和負載造成壓力。分析結果表明數據庫很可能成為影響性能的瓶頸，并決定對數據庫底層做分庫分表改造，確保數據水平動態擴展能力，滿足數據容量持續增長的需求，并提高下單效率。
1. 業務介紹
上圖是一元搶寶商品詳情頁，從圖中可以看出，一元搶寶的商品即商品項，其不同于其他京東商品的地方在于：有期次、總人次和剩余人次的概念;假設一個商品項有100個庫存，則會分100期次售賣，每期次一個售賣的是一個庫存;總人次即設置的每一期搶寶商品價格，假設1000人次，則商品總價是1000元(每人1元);當剩余人次為0時，本期搶寶結束，然后按照相應算法產生搶寶者;然后進行下一期搶寶。
通過技術改造，從整體上來說實現三個目標：1、底層路由策略實現;2、歷史數據遷移;3、業務改造。下面詳細介紹本次改造的過程。
2. 數據庫容器預估
分庫分表最重要的是要先做容器預估，依據數據量和業務特性估算出容器/庫/表的數量及分庫分表規則。
假設一天100萬訂單，一年則產生3.6億訂單量;假設數據結構是這樣的：訂單表10個字段，一個字段50個字符;一條訂單則需要500字節存儲，那么3.6億訂單則需要大約170GB存儲空間;假設每臺機器存儲空間為200GB，則每年增加一臺機器即可滿足容量需求。而實際需求要根據壓測結果來決定;如壓測其他一些指標是否滿足需求，如QPS、響應時間等。
3. 底層路由策略選擇及實現
分庫分表路由策略是基礎，影響整個系統架構，后期業務需求是否滿足和支持，使用是否方便都與此有關。路由策略設計合理，上層業務使用會很方便。一元搶寶項目的路由策略適配和實現是在DAO層實現，對上層業務層透明，可不用關心具體實現，并且路由策略不涉及結構上的改動，對上層不會產生影響。
我們知道常見的分表策略有兩種：
hash路由
優點：可實現數據分散，熱點分散;
不足：增加數據庫節點時，會影響路由策略，需做數據遷移;
分區路由(增量區間路由)
優點：策略支持動態擴容，理論上可***擴展;
不足：存在數據熱點問題，新產生的表，讀寫頻率較高;每次查詢需要經過路由策略表。
當然每種策略都不是***的，只有最適合業務場景的策略才是好的。該項目采用的是兩種方式的結合。
首先按搶寶項hash分庫，然后按搶寶期區間段分表，如下圖所示：
期的路由策略表規則如下：
為什么使用這種策略?
搶寶項是業務上層維度，可以理解為商品，大部分表中都有這個字段;此id生成時是連續的，長期來看，hash分庫后數據是均衡的。搶寶期是搶寶項下的一個維度，如一個項庫存是100，不停售前提下，會生成100期，在售的期次只有一個。為什么選擇期id區間作為分表路由策略呢，有朋友會認為也可以選擇訂單id，從路由策略上來說，沒有問題，但一元搶寶項目的業務場景，有根據項id和期id查詢訂單參與紀錄的場景，所以要考慮通過這兩個維度能查到訂單。另外，使用區間作為分表策略，可以動態擴展，即使每次查詢經過路由表，這點開銷可以忽略，而且都是通過緩存加載。
那以上策略，可以路由的維度有哪些呢?
1、通過訂單id路由:訂單號按照一定規則生成，其存儲了庫和表的信息，可以根據訂單號直接定位到相應的庫和表;
2、通過搶寶項id和搶寶期id路由:搶寶項hash定位到庫，搶寶期查詢路由策略表定位到表，具體圖示如下：
4. 聚合查詢及聚合數據同步的實現
有分就涉及到聚合查詢，我們如何實現呢?先看如下架構圖：
上圖是數據層改造后的架構圖，之前是單表主從模式，改造后為多個分庫、基礎庫。聚合采用了elastic search (以下簡稱ES)。
為什么使用它呢，首先，簡單便捷，容易接入;其次，支持動態擴容分片，對業務層透明等。系統中的聚合查詢主要使用了ES，當然我們有很多降級方案，后面會講到。ES不能當作庫來使用，它并不能***保證數據完整性，所以一定要有數據備份，我們使用了聚合表，保存一段時間內的數據，用于降級使用，一旦ES有延遲或集群不可用，就會降級查詢聚合表。
同步ES我們是怎么做的呢?我們使用了canal。有的朋友可能說了，為什么不在直接在代碼中插入時去同步，可以這樣做，但有兩個問題，一是同步失敗如何處理，如何保證事務，二是與業務代碼強耦合，借用術語，不beautify。使用canal，代碼解耦，不侵入與代碼。它其實是模擬了數據庫主從復制機制，偽裝為一個從庫，當數據庫(為不影響主庫生產，我們監聽的是從庫)binlog有變化時，canal監聽到，通過解析服務解析過濾binlog，把需要的日志過濾出來。解析后，我們通過發送MQ消息，消息體是表名和主鍵id，不是整條數據，消費端接到變化的表名和id，實時從庫中查詢***數據，同步到ES、聚合表。
為什么通過MQ消息呢?還可以用以上兩點來解釋，一是消息支持失敗重試，存儲失敗后拋異常，等待下次處理，二是系統間解耦。細心的朋友可以看到，一個消息隊列，通過多個消費訂閱(可以理解為每個消費者的隊列都是鏡像復制的)。這樣做為了在存儲時不相互影響;如果使用一個訂閱者處理，存儲ES失敗，其他兩個聚合存儲成功，那也要拋異常或其他處理方式，下次消費時，另兩個聚合還要存儲一次。
以上就是我們聚合和同步聚合的設計。查詢時，一部分業務會先查詢緩存，不存在再查詢ES，如果降級，才會查庫，正常的聚合查詢都不會查到庫。
5. 歷史數據遷移
由于我們系統上線時是單庫，分庫是上線幾個月后做的技改，所以數據需要遷移，主要遷移步驟如下：
前半部分，從掃描到同步到分庫是新代碼，后面canal到同步ES、聚合表都是復用上面邏輯，這樣設計，降低我們整體工作量，并且保證數據遷移完整。
具體遷移細節如下：
可以看出，主要分為兩部分，停機前和停機后。停機前是遷移歷史數據，支持重復遷移;停機后，只遷移增量部分，這樣，大大縮短我們的上線時間。停機后只需要遷移很少的數據量。
遷移就涉及到數據校驗，校驗邏輯整體來說比較簡單：
三個維度分別和基礎庫做對比，如果不同，重新遷移某一天數據。
6. 系統關鍵節點降級
這一部分也很重要，我們的降級主要有兩點，一是canal同步延遲降級，一是ES不可用降級。***種如下：
如果canal同步延遲，或者從庫掛掉，開啟開關，掃描主庫數據(最近幾小時)直接同步到ES、聚合表;這樣，即使從庫掛掉，也不影響業務數據，這一點很重要，實際業務場景中我們也遇到過。
ES降級，ES不可用時，關閉ES開關，直接查詢聚合表。
7. 總結
一個系統從設計到最終完成，依賴于整個團隊，每個人的想法、不同思路的碰撞和付出;再有前期合理細致的設計尤為重要，每個時間點和具體上線步驟和回滾方案做好詳細計劃;另外，就是細致深入測試，測試環境和線上多輪測試和回歸，也是正常上線的重要保證。
以上就是京東一元搶寶項目分庫分表的主要思想，希望有同樣想法的朋友可以深入交流，互相提升系統架構。
作者：匙凱明，京東高級開發工程師，在京東負責一元搶寶系統架構和開發工作;多年互聯網經驗，對于系統架構和設計有自己的見解和經驗。
【本文來自51CTO專欄作者張開濤的微信公眾號(開濤的博客)，公眾號id: kaitao-1234567】
