運維自動化來源于工作中的痛點，京東數(shù)據(jù)庫團隊面對的是商城成千上萬的研發(fā)工程師，這種壓力推動我們不斷變革，然而變革不是一蹴而就，也經(jīng)歷過從手工到腳本化、自動化、平臺化、智能化的艱難轉(zhuǎn)變，所以說是需求在驅(qū)動運維體系的建設(shè)，而運維自動化的真諦在于解放運維人員，促進(jìn)人率提升，減少人為故障，要學(xué)會培養(yǎng)自己“懶”這個好習(xí)慣。

京東的自動化運維體系建設(shè)始于2012年，下面從兩個方面進(jìn)行介紹：

一、京東數(shù)據(jù)庫智能運維平臺

京東業(yè)務(wù)每年都在以爆發(fā)的形式在增長，數(shù)據(jù)庫服務(wù)器的數(shù)量眾多，產(chǎn)品線也多達(dá)上千條，要支持如此龐大的業(yè)務(wù)體系，需要一套完善的運維自動化管理平臺。目前京東MySQL數(shù)據(jù)庫管理平臺簡稱DBS，主要涵蓋以下內(nèi)容：完善的資產(chǎn)管理系統(tǒng)、數(shù)據(jù)庫流程管理系統(tǒng)、數(shù)據(jù)庫監(jiān)控系統(tǒng)、數(shù)據(jù)庫故障管理系統(tǒng)、數(shù)據(jù)庫報表系統(tǒng)、彈性數(shù)據(jù)庫系統(tǒng)以及數(shù)據(jù)庫輔助運維工具，涉及DBA運維的方方面面，實現(xiàn)了DBA對MySQL的自動化、自助化、可視化、智能化、服務(wù)化管理，避免DBA因手工操作失誤帶來的生產(chǎn)事故，保障京東數(shù)據(jù)庫的安全、穩(wěn)定、高效運行。

這里著重介紹以下部分核心功能組件：

1、元數(shù)據(jù)管理

作為自動化運維的基石，它的準(zhǔn)確性直接關(guān)系到整個數(shù)據(jù)庫管理平臺的可靠性。京東數(shù)據(jù)庫管理平臺從數(shù)據(jù)庫業(yè)務(wù)方、DBA的運維習(xí)慣等方面出發(fā)，涵蓋機房、主機、業(yè)務(wù)、集群、實例、庫、表等多個維度：

• 機房和主機維度：主要記錄硬件方面的信息。
• 業(yè)務(wù)維度：主要記錄業(yè)務(wù)的名稱、等級及業(yè)務(wù)部門相關(guān)信息。
• 集群維度：主要記錄MySQL集群架構(gòu)信息。
• 實例維度：主要記錄MySQL的相關(guān)參數(shù)，為后續(xù)自動化運維提供保障。
• 庫維度：主要記錄數(shù)據(jù)庫名稱及業(yè)務(wù)人員聯(lián)系信息。

2、自動化部署

面對繁雜的數(shù)據(jù)庫新增，擴容等運維工作，利用自動安裝部署平臺可以徹底解放DBA。目前京東的自動化部署系統(tǒng)包含申請服務(wù)器、部署數(shù)據(jù)庫實例、同步數(shù)據(jù)、一致性校驗、拆分及切換等操作，整個過程流程化，包含各級業(yè)務(wù)及DBA的操作審批，最終達(dá)到全面的MySQL服務(wù)的自動化和流程化部署，如下圖：

主要功能點包含以下內(nèi)容：

• 安裝部署MySQL實例，架構(gòu)搭建，域名申請。分配規(guī)則要求同一集群主從實例不能在同一機柜，硬件性能好的主機優(yōu)先為主庫。
• 監(jiān)控部署，備份部署，資產(chǎn)注冊。
• MySQL服務(wù)采用鏡像的形式創(chuàng)建，鏡像依賴于K8S的鏡像倉庫。
• 應(yīng)用賬號是應(yīng)用方通過自動化上線系統(tǒng)申請創(chuàng)建的。
• 主從數(shù)據(jù)一致性校驗，通常會選擇夜間業(yè)務(wù)低峰期定時執(zhí)行。

3、智能分析與診斷

京東的智能分析與診斷涵蓋4部分重要的內(nèi)容，數(shù)據(jù)庫監(jiān)控指標(biāo)采集、診斷分析、故障自愈、趨勢分析：

（1）監(jiān)控系統(tǒng)

監(jiān)控系統(tǒng)為數(shù)據(jù)庫管理提供了精準(zhǔn)的數(shù)據(jù)依據(jù)，能夠讓運維人員對生產(chǎn)服務(wù)系統(tǒng)運行情況了如指掌，核心的監(jiān)控指標(biāo)包含：OS負(fù)載、MySQL核心指標(biāo)、數(shù)據(jù)庫日志等。通過分析獲得的監(jiān)控信息，判斷被監(jiān)控數(shù)據(jù)庫的運行狀態(tài)，對可能出現(xiàn)的問題進(jìn)行預(yù)測，并給出優(yōu)化方案，保證整個系統(tǒng)穩(wěn)定、高效。

京東的分布式監(jiān)控系統(tǒng)采用被動模式，server端和proxy端均做高可用，防止單點故障。以下是整體架構(gòu)和流程圖：

（2）監(jiān)控性能分析

數(shù)據(jù)庫性能智能分析，主要是對數(shù)據(jù)庫監(jiān)控數(shù)據(jù)的二次分析，排除安全隱患。在實際的生產(chǎn)中，有些隱患沒有達(dá)到設(shè)置的報警閾值，處于一個報警的臨界點，其實這種情況是最危險的，隨時可能爆發(fā)，為解決這些隱患，我們通過對監(jiān)控數(shù)據(jù)的環(huán)比、同比、TOP指標(biāo)等方面進(jìn)行分組匯總分析，提前發(fā)現(xiàn)隱患。 

慢SQL分析：

索引分析：

空間分析及預(yù)測：

鎖分析：

（3）故障自愈 

故障出現(xiàn)的形態(tài)千奇百怪，而最核心的內(nèi)容依賴于監(jiān)控的輔助分析，如何提供最為精準(zhǔn)的信息，所做內(nèi)容如下： 

• 告警過濾：將告警中不重要的告警以及重復(fù)告警過濾掉 
• 生成派生告警：根據(jù)關(guān)聯(lián)關(guān)系生成各類派生告警 
• 告警關(guān)聯(lián)：同一個時間窗內(nèi)不同類型派生告警是否存在關(guān)聯(lián) 
• 權(quán)重計算：根據(jù)預(yù)先設(shè)置的各類告警的權(quán)重，計算成為根源告警的可能性 
• 生成根源告警：將權(quán)重最大的派生告警標(biāo)記為根源告警 
• 根源告警合并：若多類告警計算出的根源告警相同，則將其合并 

4、智能切換系統(tǒng)  

京東數(shù)據(jù)庫服務(wù)器的量級較大，會導(dǎo)致出故障的概率相對提高，同時對系統(tǒng)穩(wěn)定性的要求也較為苛刻。因此為確保實現(xiàn)數(shù)據(jù)庫高可用，保證7*24小時的持續(xù)服務(wù)，我們團隊自主研發(fā)了數(shù)據(jù)庫自動切換平臺，實現(xiàn)了自動和半自動兩種切換方式，實現(xiàn)了按單集群級別、多集群級別、機房級別等多維度的場景切換。切換過程包含監(jiān)控的修改、資產(chǎn)信息的修改、備份策略的修改、主從角色的修改等，一鍵化完成，避免人為因素帶來的二次故障。 

（1）分布式檢測 

作為切換系統(tǒng)的核心組件，分布式檢測功能主要解決系統(tǒng)容災(zāi)方面的問題。按照京東數(shù)據(jù)庫服務(wù)器多數(shù)據(jù)中心部署的特征，獨立的數(shù)據(jù)中心各部署了一個檢測節(jié)點，并通過特殊標(biāo)識的接口域名區(qū)分。當(dāng)發(fā)生切換操作時，切換系統(tǒng)會根據(jù)傳入的故障主機IP等信息，隨機選取兩個機房接口執(zhí)行調(diào)用，探活操作如果發(fā)現(xiàn)有一個節(jié)點主機存活，那么認(rèn)為主機存活；如果發(fā)現(xiàn)兩個節(jié)點都探測為宕機，那么認(rèn)為主機宕機。 

（2）Master故障切換 

主庫實例故障，切換系統(tǒng)會首先通過分布式檢測系統(tǒng)檢查實例存活狀態(tài)，確認(rèn)宕機后將根據(jù)基礎(chǔ)信息中的實例切換標(biāo)識，選擇使用自動切換或手動切換，兩種切換方式原理相同：先在切換系統(tǒng)上創(chuàng)建切換任務(wù)，手動切換需要DBA執(zhí)行切換按鈕，切換操作會通過insert方式插入數(shù)據(jù)以驗證實例運行狀態(tài)，避免實例夯住和硬盤只讀的情況。如果沒有存活的從庫，則放棄本次操作并以郵件和短信的方式通知DBA。新主庫是按照先本地（先連接數(shù)少，后QPS負(fù)載低），后異地的原則選擇，執(zhí)行切換成功后將變更相應(yīng)元數(shù)據(jù)信息，示例如下： 

某一主四從的集群，主庫 10.66.66.66:3366故障，需要切換，如下： 

• 監(jiān)控系統(tǒng)檢測到主庫宕機，則自動創(chuàng)建切換任務(wù)，進(jìn)行自動切換或者手動切換，以手動切換為例： 

• 選目標(biāo)實例，假如例子中的4個從都是存活的，那么根據(jù)先本地后異地原則，選出10.66.66.68:3366，10.66.66.69:3366，然后再去查連接數(shù)，在連接數(shù)都相同的情況下，則去比較QPS，選出QPS負(fù)載低的10.66.66.69:3366作為目標(biāo)實例：

• 切換完成結(jié)果： 

（3）Slave故障切換 

從庫實例故障，將故障實例下的域名變更到該集群下的非故障實例上，選擇目標(biāo)實例方式與主庫實例選擇規(guī)則一致。切換成功或失敗都會發(fā)郵件及短信告知相應(yīng)的DBA。故障實例恢復(fù)后，DBA判斷是否需要回切。示例如下： 

有一主四從的集群，從庫 10.88.88.89:3366故障，需要切換，如下：

監(jiān)控系統(tǒng)會自動創(chuàng)建任務(wù)，并根據(jù)先本地后異地原則，然后再查連接數(shù)、QPS，確定目標(biāo)實例為10.88.88.88:3366，進(jìn)行自動切換，DBA可在切換任務(wù)列表查看詳情。 

切換成功的任務(wù)會顯示回切按鈕，DBA可以執(zhí)行回切，并查看回切的具體信息。

（4）主從計劃性切換  

主從計劃性切換實現(xiàn)了按單集群，多集群的批量切換。執(zhí)行批量切換時可以查看子任務(wù)切換的具體步驟，切換后會有前后架構(gòu)的對比，具體示例如下： 

集群1

批量創(chuàng)建任務(wù)，選擇原則根據(jù)先本地后異地，先連接數(shù)后QPS，10.66.66.66:3366選擇目標(biāo)主庫為：10.88.88.89:3366。 

批量執(zhí)行切換：

切換子任務(wù)詳細(xì)信息，可查看到每個子任務(wù)的切換結(jié)果，執(zhí)行步驟及前后架構(gòu)：

京東MySQL數(shù)據(jù)庫切換系統(tǒng)各功能模塊都已組件化、服務(wù)簡化了DBA的操作流程，縮短了數(shù)據(jù)庫切換的時間。 

5、數(shù)據(jù)庫自動化備份恢復(fù) 

（1）架構(gòu)設(shè)計   

京東數(shù)據(jù)庫備份系統(tǒng)在設(shè)計之初，就是為了將DBA從繁雜的備份管理工作中解脫出來，實現(xiàn)自動處理，減少人為干預(yù)，并提高備份文件的可用性。關(guān)于備份文件可用性問題，以輪詢恢復(fù)的策略確保每個集群在一個周期內(nèi)都被恢復(fù)到。系統(tǒng)架構(gòu)設(shè)計如下圖所示： 

架構(gòu)具備以下幾個特點： 

調(diào)度觸發(fā)多樣化  

調(diào)度中心支持三種類型的觸發(fā)方式interval、crontab和date： 

• interval是周期調(diào)度，可以指定固定間隔時長的任務(wù)調(diào)度，支持時間單位有weeks、days、hours、minutes、seconds，并支持設(shè)定調(diào)度開始時間和結(jié)束時間以及時區(qū)設(shè)置。 
• crontab是定時調(diào)度，與Linux的crontab基本相同，支持year、month、day、week、day_of_week、hour、minute、second，并且支持設(shè)置調(diào)度開始時間和結(jié)束時間以及時區(qū)設(shè)置。 
• date是一次性定時調(diào)度，支持時區(qū)設(shè)置。 

并發(fā)控制 

由于調(diào)度任務(wù)設(shè)置具有不均衡性，可能某一時刻需要調(diào)度的任務(wù)較多，容易引起調(diào)度系統(tǒng)出現(xiàn)問題，因此執(zhí)行任務(wù)通過控制并發(fā)數(shù)來使任務(wù)調(diào)度執(zhí)行運行更加平穩(wěn)。 

觸發(fā)和執(zhí)行分層 

任務(wù)觸發(fā)本身是輕量級集的，而任務(wù)執(zhí)行一般都比較重，因此對觸發(fā)和執(zhí)行進(jìn)行了分層設(shè)計，來防止因為執(zhí)行時間過長導(dǎo)致后續(xù)觸發(fā)出現(xiàn)問題。 

維護期間任務(wù)不丟失 

Linux的crontab在停機維護期間要運行的任務(wù)開機后并不會再次執(zhí)行，而基于APScheduler的調(diào)度中心則會在啟動后運行指定間隔內(nèi)尚未執(zhí)行的任務(wù)，減少因維護而錯失任務(wù)的執(zhí)行。 

備份策略增刪改查 

之前公司的備份系統(tǒng)是需要指定特定的IP，經(jīng)常因為服務(wù)器維護而導(dǎo)致備份失敗，故在設(shè)計之初就將備份策略與高可用結(jié)合在一起，備份策略指定域名而不是IP。從庫因為故障切換時DBS會將此從庫上的域名切換到集群內(nèi)的其他從庫，相應(yīng)的備份也跟隨到了此從庫，保證了備份服務(wù)器是可用的。 

失敗自動重試  

備份很可能因為偶然因素而失敗，因此加入了備份重試的功能，會對6小時以內(nèi)的備份失敗任務(wù)進(jìn)行備份重試，最多重試3次，來獲得更高的備份成功率。 

自動恢復(fù)檢測 

備份在每一步都要嚴(yán)格地驗證，但是也無法絕對保證備份文件可用，因此引入了自動恢復(fù)檢測機制，來幫助DBA對備份文件進(jìn)行檢測，及時發(fā)現(xiàn)因為各種未考慮到的情況導(dǎo)致備份文件不可用的情況，并且恢復(fù)檢測也是審計的一個硬性要求，自動恢復(fù)檢測也將DBA從繁重的恢復(fù)檢測工作中徹底解脫了出來。 

（2）調(diào)度設(shè)計 

整個自動化備份恢復(fù)系統(tǒng)主要由調(diào)度系統(tǒng)、備份系統(tǒng)、恢復(fù)系統(tǒng)、恢復(fù)檢測系統(tǒng)、自動修復(fù)系統(tǒng)組成。其中調(diào)度系統(tǒng)是整個系統(tǒng)核心，通過調(diào)度系統(tǒng)來協(xié)調(diào)其他系統(tǒng)運行。調(diào)度系統(tǒng)可以部署Standby來實現(xiàn)高可用，執(zhí)行器以集群部署來實現(xiàn)高可用和橫向擴容。 

備份系統(tǒng)每次備份時都會進(jìn)行實例健康狀態(tài)檢查、備份運行狀態(tài)檢查等，防止對無效的數(shù)據(jù)庫實例進(jìn)行備份；恢復(fù)系統(tǒng)主要是在需要進(jìn)行數(shù)據(jù)恢復(fù)、彈性擴容等等需要從備份文件恢復(fù)成運行的數(shù)據(jù)庫實例時使用，能夠讓DBA通過簡單地操作即可完成數(shù)據(jù)的恢復(fù)；恢復(fù)檢測在調(diào)度系統(tǒng)的指揮下自動對備份文件可用性進(jìn)行檢測，來幫助DBA及時發(fā)現(xiàn)不可用的備份文件；備份失敗有些是能夠通過失敗自動重試來解決，但有一部分是重試所不能解決的，需要進(jìn)行相應(yīng)修復(fù)，因此開發(fā)了自動修復(fù)系統(tǒng)來自動修復(fù)因為環(huán)境等問題引起的備份失敗。 

調(diào)度系統(tǒng)是最核心的一個系統(tǒng)，是整個備份恢復(fù)系統(tǒng)的大腦，當(dāng)時考察了幾種實現(xiàn)方式，例如Linux的crontab、Azkaban和python的開源框架Apscheduler，最終認(rèn)為Apscheduler更加靈活小巧，調(diào)度方式也更加多樣化，使用Python開發(fā)后期維護成本更低，因此采用Apscheduler開發(fā)了調(diào)度中心。 

（3）系統(tǒng)前端 

主要分為備份策略管理、備份詳情、備份黑名單管理、恢復(fù)詳情四個模塊： 

備份策略管理：

備份策略管理的頁面包含了備份狀態(tài)分布情況、存儲使用情況以及每個集群的當(dāng)前備份策略狀態(tài)，如果已經(jīng)添加了備份策略則可以在這里進(jìn)行（時間、服務(wù)器、備份方式）修改、暫停（繼續(xù)）、刪除操作，如果沒有添加備份策略，則可以進(jìn)行添加。 

備份詳情：

備份詳情里面展示了最近備份總數(shù)、成功數(shù)、成功率、當(dāng)天備份任務(wù)運行狀態(tài)、備份任務(wù)24小時分布曲線圖以及備份詳細(xì)記錄。備份詳細(xì)的記錄可以根據(jù)集群名、項目名等信息進(jìn)行查詢，方便DBA更好地掌握備份運行狀況。 

恢復(fù)檢測詳情：

恢復(fù)檢測頁面包含最近每天恢復(fù)檢測數(shù)、恢復(fù)檢測成功數(shù)、成功率柱狀圖、當(dāng)天恢復(fù)檢測任務(wù)運行狀態(tài)餅圖和近期恢復(fù)檢測完成率，有助于DBA對恢復(fù)概況有更清晰的了解。 

二、數(shù)據(jù)庫變革 

1、過去 

在ContainerDB之前，京東的數(shù)據(jù)庫服務(wù)實現(xiàn)了容器化，雖然數(shù)據(jù)庫服務(wù)已經(jīng)完全通過Docker容器實現(xiàn)了數(shù)據(jù)庫服務(wù)的快速交付和自動故障切換等基本功能，在一定程度上提高了數(shù)據(jù)庫服務(wù)的穩(wěn)定性和效率，但是數(shù)據(jù)庫服務(wù)的運維和使用方式與傳統(tǒng)方式基本無異，比較典型的問題如下： 

（1）資源分配粒度過大 

數(shù)據(jù)庫服務(wù)器資源標(biāo)準(zhǔn)固定，粒度過大，為數(shù)據(jù)庫服務(wù)可提供的資源標(biāo)準(zhǔn)過少。 

（2）資源浪費嚴(yán)重 

資源分配的標(biāo)準(zhǔn)有DBA根據(jù)經(jīng)驗決定，存在很大的主觀性，不能根據(jù)業(yè)務(wù)的實際情況進(jìn)行準(zhǔn)確評估，而DBA在分配資源的時候一般都會考慮在3年以內(nèi)不需要對服務(wù)進(jìn)行遷移或者擴容，而一次分配比較多的資源，存在嚴(yán)重資源浪費。而且由于數(shù)據(jù)庫資源標(biāo)準(zhǔn)固定，標(biāo)準(zhǔn)過大，導(dǎo)致宿主機中的碎片過大，經(jīng)常出現(xiàn)一臺宿主機只能創(chuàng)建一個容器，而剩下的資源滿足不了任何資源標(biāo)準(zhǔn)，導(dǎo)致宿主機上資源使用率過低。 

（3）資源靜態(tài)無調(diào)度  

數(shù)據(jù)庫服務(wù)一旦提供，所占據(jù)的資源就會固定，不能根據(jù)數(shù)據(jù)庫的負(fù)載進(jìn)行在線動態(tài)的調(diào)度，而一旦數(shù)據(jù)庫的硬盤使用率過高，需要DBA人工介入進(jìn)行擴容處理，效率低下。 

2、現(xiàn)在 

基于以上的問題，單純的數(shù)據(jù)庫服務(wù)容器化已經(jīng)無法解決，我們需要讓數(shù)據(jù)庫服務(wù)更聰明，讓數(shù)據(jù)庫的資源能夠動起來，提供資源分期交付的功能，于是ContainerDB應(yīng)運而生。ContainerDB基于負(fù)載的彈性調(diào)度為京東的數(shù)據(jù)庫資源賦予了智慧，令其資源真正地流動起來，并已成功服務(wù)于多次618和11.11大促。

ContainerDB針對每個業(yè)務(wù)應(yīng)用都有邏輯庫，邏輯庫中定義了針對整個業(yè)務(wù)所有表的拆分鍵（Sharding Key）進(jìn)行哈希取模運算時模的范圍（KeySpace），在每個邏輯庫中可以創(chuàng)建多張表，但是每個表中必須定義Sharding Key。通過該Sharding Key將表中的數(shù)據(jù)拆分成多個分片（Shard），每個分片都對應(yīng)一個KeyRange，KeyRange表示對Sharding Key進(jìn)行哈希取模運算之后得到的值（Sharding Index）的一個范圍，每個Shard都由一整套MySQL主從架構(gòu)提供數(shù)據(jù)庫服務(wù)支撐。應(yīng)用程序只跟Gate集群進(jìn)行交互，由Gate根據(jù)元數(shù)據(jù)信息和SQL語句完成數(shù)據(jù)寫入和查詢的自動路由。ContainerDB中的監(jiān)控中心會對所有的基礎(chǔ)服務(wù)和資源使用狀況進(jìn)行實時監(jiān)控，并通過在監(jiān)控中心注冊的Hook程序自動進(jìn)行動態(tài)擴容、故障自愈、分片管理等，而這一系列操作對應(yīng)用程序來說是完全無感知的。 

（1）流式資源持續(xù)交付

數(shù)據(jù)庫以前的服務(wù)存在資源浪費的一個主要原因就是資源初始分配粒度太大，一開始就為業(yè)務(wù)提前預(yù)支3年甚至5年的資源。而資源池中的資源是有限的，不可能讓所有業(yè)務(wù)都提前預(yù)支資源，從而導(dǎo)致有些業(yè)務(wù)沒有資源。ContainerDB采用流式的方式進(jìn)行資源的持續(xù)交付。每個業(yè)務(wù)接入初始都只會分配標(biāo)準(zhǔn)的64G硬盤，隨著業(yè)務(wù)的發(fā)展和數(shù)據(jù)量的持續(xù)增加，會持續(xù)增加硬盤容量直到到達(dá)硬盤限制的上限256G。 

通過這種方式，我們極大地拉長了數(shù)據(jù)庫資源的交付周期，進(jìn)而可以在三年或者五年的所有資源預(yù)算到位之前就首先為所有服務(wù)提供數(shù)據(jù)庫服務(wù)，提升了數(shù)據(jù)庫的業(yè)務(wù)支撐能力。 

（2）基于負(fù)載的彈性調(diào)度 

數(shù)據(jù)庫服務(wù)使用的資源分為兩類：瞬時資源和遞增資源。 

瞬時資源是指會資源的使用率在短時間之內(nèi)會出現(xiàn)嚴(yán)重波動，這種資源主要包括CPU和內(nèi)存。 

遞增資源是指資源的使用率不會再短時間之內(nèi)出現(xiàn)嚴(yán)重的波動，而是會緩慢增加，并且支持遞增，不會出現(xiàn)減少的情況，這種資源主要包括硬盤。ContainerDB對于不同的資源采取了不同的調(diào)度策略。針對于瞬時資源，ContainerDB為每個數(shù)據(jù)庫分配三種標(biāo)準(zhǔn)： 

• 下限：2C/4G，上限：4C/8G  
• 下限：4C/8G，上限：8C/16G 
• 下限：8C/16G，上限：16C/32G 

每個容器分配的初始資源為標(biāo)準(zhǔn)的下限值，當(dāng)數(shù)據(jù)庫服務(wù)出現(xiàn)CPU負(fù)載過高或者內(nèi)存不足時，會嘗試申請多于下限的CPU或者內(nèi)存，但絕對不會超過上限，待負(fù)載恢復(fù)后釋放多申請的資源，直至恢復(fù)至CPU和內(nèi)存的下限為止。 

針對遞增資源：磁盤，在業(yè)務(wù)接入之初，統(tǒng)一分配64G的硬盤，每當(dāng)當(dāng)前磁盤使用率達(dá)到80%，且沒有達(dá)到256G上限的時候，則進(jìn)行垂直升級；若容器當(dāng)前磁盤達(dá)到了256G上限則進(jìn)行在線Resharding。 

垂直升級：首先會進(jìn)行資源check，看宿主機是否有足夠的剩余硬盤資源進(jìn)行垂直升級，若check通過，則會在宿主機施加全局資源鎖，并對硬盤進(jìn)行垂直擴容再增加64G。若check不通過，則在宿主機上提供一個硬盤大小為：磁盤容量+64G大小，CPU和內(nèi)存與當(dāng)前容器相同的新容器，并將數(shù)據(jù)庫服務(wù)遷移到新的容器上。垂直升級是瞬間完成的不會影響數(shù)據(jù)庫服務(wù)。 

在線Resharding：申請兩個新的Shard，新Shard中的數(shù)據(jù)庫Container的硬盤、CPU和內(nèi)存標(biāo)準(zhǔn)與當(dāng)前Shard中的完全一致，根據(jù)當(dāng)前Shard中的數(shù)據(jù)庫主從關(guān)系，對新Shard中的所有數(shù)據(jù)庫重建MySQL主從關(guān)系，然后啟動Schema信息拷貝和過濾復(fù)制，最后更新路由規(guī)則并將讀寫流量切換到新的Shard上，將舊的Shard資源下線。 

無論是垂直升級還是在線Resharding，都需要注意一個問題：在保證每個分片的Master在主機房的前提下，盡量不要將所有的資源都分配在一個宿主機/機架/機房，ContainerDB提供了強大的親和/反親和性資源分配能力。目前ContainerDB的親和/反親和性策略如下：

每個KeySpace都有一個主機房，屬于同一個Shard中的數(shù)據(jù)庫實例（目前一個shard中包含1主2從）的資源分配盡量應(yīng)該滿足：Master必須屬于主機房，不能有任意兩個實例屬于同一機架，不能有任意三個實例在同一IDC，這種策略可以避免某一機柜掉電而導(dǎo)致主從同時出現(xiàn)故障，也可以避免IDC故障從而導(dǎo)致所有數(shù)據(jù)庫實例均不可用。 

由于是盡量滿足，所以當(dāng)資源池中的資源分布不均時，就有可能在資源分配的時候滿足不了上述的反親和性策略。因此ContainerDB有一個常駐后臺進(jìn)程，不停的輪詢集群中的所有Shard，判斷Shard中的實例分布是否滿足反親和性規(guī)則，若不滿足，就會嘗試進(jìn)行實例重新分布。重新分布時為了不影響線上業(yè)務(wù)，會優(yōu)先進(jìn)行從庫重分布。 

基于彈性調(diào)度的能力ContainerDB實現(xiàn)了如下三個功能： 

• 在線擴容：當(dāng)某個Shard的數(shù)據(jù)庫負(fù)載達(dá)到閾值后，會自動觸發(fā)Shard的在線垂直升級、遷移或者Resharding。 
• 在線自愈：當(dāng)Shard中的某個MySQL實例出現(xiàn)故障，ContainerDB首先判斷出現(xiàn)故障的實例是否為master，若是master，則選擇GTID最大的slave作為新的主，并進(jìn)行復(fù)制關(guān)系重建和Slave補齊；若不是master，則直接進(jìn)行slave補齊。 
• 在線接入：ContainerDB允許用戶以完全自助化的方式啟動數(shù)據(jù)在線遷移與接入任務(wù)，該任務(wù)會將傳統(tǒng)MySQL數(shù)據(jù)庫中的數(shù)據(jù)在線遷移到ContainerDB中，待數(shù)據(jù)遷移完畢后，自動進(jìn)行域名切換，完成業(yè)務(wù)系統(tǒng)數(shù)據(jù)源的在線無感知遷移。 

ContainerDB通過在線服務(wù)能力擴容、在線自愈和在線接入三大功能，實現(xiàn)了京東數(shù)據(jù)庫服務(wù)的Always Online保證。 

（3）不止于調(diào)度 

彈性和流式的資源交付與調(diào)度是ContainerDB的基石，但是除了這兩個核心功能之外，ContainerDB還在用戶易用性、兼容性和數(shù)據(jù)安全性等方面做了很多工作，包括： 

數(shù)據(jù)保護

在傳統(tǒng)的直連數(shù)據(jù)庫的方案下，當(dāng)Master出現(xiàn)網(wǎng)絡(luò)不可達(dá)時，一般都會選擇新的Slave變?yōu)镸aster，然后將原來Master上的域名漂移到新的Master上。但是這種方案在網(wǎng)絡(luò)抖動的情況下很容易由于AppServer上的DNS緩存，而導(dǎo)致雙Master，并且出現(xiàn)臟寫的情況。從整體架構(gòu)圖可以看出，ContainerDB與用戶之間通過Gate連接。Gate是一個集群化服務(wù)，多個Gate服務(wù)都映射到一個域名下，Gate通過IP地址直接訪問各個MySQL服務(wù)，而且Gate對各個MySQL角色的識別完全依賴于元數(shù)據(jù)服務(wù)：Topology。當(dāng)ContainerDB中某個MySQL的Master產(chǎn)生網(wǎng)絡(luò)不可達(dá)時，會選出新的Master，并更新路由元數(shù)據(jù)信息，最后才做Master切換，這樣就避免了由于網(wǎng)絡(luò)抖動和DNS緩存而在成雙主和數(shù)據(jù)臟寫，從而對數(shù)據(jù)進(jìn)行了嚴(yán)格的保護。

流式查詢處理

ContainerDB通過在Gate層實現(xiàn)基于優(yōu)先級的歸并排序提供了快速流式查詢的功能，在進(jìn)行大批量數(shù)據(jù)查詢時，能瞬時返回部分查詢結(jié)果數(shù)據(jù)，極大提高客戶體驗。 

無感知數(shù)據(jù)遷移 

ContainerDB通過在交叉在Window函數(shù)中分別執(zhí)行部分存量數(shù)據(jù)拷貝和增量數(shù)據(jù)追加的算法，開發(fā)了在線數(shù)據(jù)遷移和接入工具JTransfer，通過JTransfer可以將傳統(tǒng)MySQL數(shù)據(jù)庫中的動態(tài)數(shù)據(jù)遷移到ContainerDB中，當(dāng)ContainerDB中的數(shù)據(jù)與源MySQL中的數(shù)據(jù)的lag小于5秒時，首先會將源MySQL停寫，待lag變?yōu)?時將源MySQL的域名漂移到Gate集群，整個遷移過程用戶AppServer無感知。

兼容MySQL協(xié)議

ContainerDB完全兼容MySQL協(xié)議，支持標(biāo)準(zhǔn)MySQL客戶端和官方驅(qū)動程序接入，并且支持大部分ANSI SQL語法。

路由規(guī)則透明

ContainerDB與用戶之間通過Gate集群進(jìn)行連接，Gate根據(jù)用戶發(fā)送的查詢語句形成的語法樹和查詢執(zhí)行計劃得到查詢中涉及到的所有表，并根據(jù)Topology中的元數(shù)據(jù)信息獲得各個表的分片信息，最后結(jié)合語句中的Join中的關(guān)聯(lián)條件和Where字句中的謂詞信息，將查詢或者寫入路由到正確的分片。整個過程都是Gate自動完成的，對用戶完全透明。

自助化服務(wù)

ContainerDB將對數(shù)據(jù)庫服務(wù)的實例化、DDL/DML執(zhí)行、分片升級和擴容等功能抽象成為獨立的接口，并借助于流程引擎提供了流程化的完全自助的用戶接入服務(wù)，用戶申請數(shù)據(jù)庫服務(wù)成功后，ContainerDB會將數(shù)據(jù)庫訪問口令自動推送到用戶郵箱。

3、展望

過去已去，未來已來。

我們后續(xù)會更多的從用戶的角度去思考數(shù)據(jù)庫能夠產(chǎn)生的價值。我們相信京東以后的數(shù)據(jù)庫服務(wù)會： 

• More Smart：我們會基于各個數(shù)據(jù)庫實例中CPU/內(nèi)存/硬盤等各種不同資源的監(jiān)控數(shù)據(jù)進(jìn)行深度學(xué)習(xí)和聚類分析，分析出各個不同數(shù)據(jù)庫實例的傾向資源，并智能化調(diào)高每個數(shù)據(jù)庫實例傾向資源的限制并調(diào)低非傾向資源的限制。 
• More Quick：我們會實時分析宿主機和容器的對應(yīng)關(guān)系、各個容器的限制參數(shù)以及各個容器的歷史資源增長速率，預(yù)先對容器所在宿主機碎片進(jìn)行整理，從而盡量保證各個容器以垂直升級的方式實現(xiàn)擴容，從而極大地加快擴容速度。 
• More Cheap：我們會提供完全自主研發(fā)的存儲引擎，計劃實現(xiàn)查詢引擎與存儲引擎的集成，并提供多模型數(shù)據(jù)庫引擎，從而實現(xiàn)多種數(shù)據(jù)模型的統(tǒng)一，極大節(jié)省數(shù)據(jù)庫服務(wù)所需資源以及研發(fā)成本。 
• More Friendly：無論是ContainerDB還是我們自主研發(fā)的多模型數(shù)據(jù)庫，我們都會完全兼容MySQL協(xié)議及語法，從而使得現(xiàn)有應(yīng)用的遷移成本趨近于0。 
• More Open：ContainerDB會在經(jīng)過京東內(nèi)部的各種場景的磨練之后會擁抱開源，并希望與業(yè)界各位同仁一起將ContainerDB不斷完善。同時我們后續(xù)的多模型數(shù)據(jù)庫最終也會貢獻(xiàn)給開源社區(qū)，并期待其服務(wù)于業(yè)界。