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