[[243998]]

圖片來自包圖網(wǎng)

然而變革不是一蹴而就，也經(jīng)歷過從手工到腳本化、自動(dòng)化、平臺(tái)化、智能化的艱難轉(zhuǎn)變。

所以說是需求在驅(qū)動(dòng)運(yùn)維體系的建設(shè)，而運(yùn)維自動(dòng)化的真諦在于解放運(yùn)維人員，促進(jìn)人率提升，減少人為故障，要學(xué)會(huì)培養(yǎng)自己“懶”這個(gè)好習(xí)慣。

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

• 京東數(shù)據(jù)庫(kù)智能運(yùn)維平臺(tái)
• 數(shù)據(jù)庫(kù)變革
• 展望

京東數(shù)據(jù)庫(kù)智能運(yùn)維平臺(tái)

京東業(yè)務(wù)每年都在以爆發(fā)的形式在增長(zhǎng)，數(shù)據(jù)庫(kù)服務(wù)器的數(shù)量眾多，產(chǎn)品線也多達(dá)上千條，要支持如此龐大的業(yè)務(wù)體系，需要一套完善的運(yùn)維自動(dòng)化管理平臺(tái)。

目前京東 MySQL 數(shù)據(jù)庫(kù)管理平臺(tái)簡(jiǎn)稱 DBS，主要涵蓋以下內(nèi)容：完善的資產(chǎn)管理系統(tǒng)、數(shù)據(jù)庫(kù)流程管理系統(tǒng)、數(shù)據(jù)庫(kù)監(jiān)控系統(tǒng)、數(shù)據(jù)庫(kù)故障管理系統(tǒng)、數(shù)據(jù)庫(kù)報(bào)表系統(tǒng)、彈性數(shù)據(jù)庫(kù)系統(tǒng)以及數(shù)據(jù)庫(kù)輔助運(yùn)維工具等。

涉及到了 DBA 運(yùn)維的方方面面，實(shí)現(xiàn)了 DBA 對(duì) MySQL 的自動(dòng)化、自助化、可視化、智能化、服務(wù)化管理，避免 DBA 因手工操作失誤帶來的生產(chǎn)事故，保障京東數(shù)據(jù)庫(kù)的安全、穩(wěn)定、高效運(yùn)行。

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

 

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

作為自動(dòng)化運(yùn)維的基石，它的準(zhǔn)確性直接關(guān)系到整個(gè)數(shù)據(jù)庫(kù)管理平臺(tái)的可靠性。

 

京東數(shù)據(jù)庫(kù)管理平臺(tái)從數(shù)據(jù)庫(kù)業(yè)務(wù)方、DBA 的運(yùn)維習(xí)慣等方面出發(fā)，涵蓋機(jī)房、主機(jī)、業(yè)務(wù)、集群、實(shí)例、庫(kù)、表等多個(gè)維度：

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

自動(dòng)化部署

面對(duì)繁雜的數(shù)據(jù)庫(kù)新增，擴(kuò)容等運(yùn)維工作，利用自動(dòng)安裝部署平臺(tái)可以徹底解放 DBA。

目前京東的自動(dòng)化部署系統(tǒng)包含申請(qǐng)服務(wù)器、部署數(shù)據(jù)庫(kù)實(shí)例、同步數(shù)據(jù)、一致性校驗(yàn)、拆分及切換等操作，整個(gè)過程流程化，包含各級(jí)業(yè)務(wù)及 DBA 的操作審批，最終達(dá)到全面的 MySQL 服務(wù)的自動(dòng)化和流程化部署，如下圖：

 

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

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

智能分析與診斷

 

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

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

監(jiān)控系統(tǒng)為數(shù)據(jù)庫(kù)管理提供了精準(zhǔn)的數(shù)據(jù)依據(jù)，能夠讓運(yùn)維人員對(duì)生產(chǎn)服務(wù)系統(tǒng)運(yùn)行情況了如指掌，核心的監(jiān)控指標(biāo)包含：OS 負(fù)載、MySQL 核心指標(biāo)、數(shù)據(jù)庫(kù)日志等。

通過分析獲得的監(jiān)控信息，判斷被監(jiān)控?cái)?shù)據(jù)庫(kù)的運(yùn)行狀態(tài)，對(duì)可能出現(xiàn)的問題進(jìn)行預(yù)測(cè)，并給出優(yōu)化方案，保證整個(gè)系統(tǒng)穩(wěn)定、高效。

京東的分布式監(jiān)控系統(tǒng)采用被動(dòng)模式，Server 端和 Proxy 端均做高可用，防止單點(diǎn)故障。

以下是整體架構(gòu)和流程圖：

 

監(jiān)控性能分析

 

數(shù)據(jù)庫(kù)性能智能分析，主要是對(duì)數(shù)據(jù)庫(kù)監(jiān)控?cái)?shù)據(jù)的二次分析，排除安全隱患。

在實(shí)際的生產(chǎn)中，有些隱患沒有達(dá)到設(shè)置的報(bào)警閾值，處于一個(gè)報(bào)警的臨界點(diǎn)。

其實(shí)這種情況是最危險(xiǎn)的，隨時(shí)可能爆發(fā)，為解決這些隱患，我們通過對(duì)監(jiān)控?cái)?shù)據(jù)的環(huán)比、同比、TOP 指標(biāo)等方面進(jìn)行分組匯總分析，提前發(fā)現(xiàn)隱患。

慢 SQL 分析：

 

索引分析：

 

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

 

鎖分析：

 

故障自愈

 

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

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

智能切換系統(tǒng)

京東數(shù)據(jù)庫(kù)服務(wù)器的量級(jí)較大，會(huì)導(dǎo)致出故障的概率相對(duì)提高，同時(shí)對(duì)系統(tǒng)穩(wěn)定性的要求也較為苛刻。

因此為確保實(shí)現(xiàn)數(shù)據(jù)庫(kù)高可用，保證 7*24 小時(shí)的持續(xù)服務(wù)，我們團(tuán)隊(duì)自主研發(fā)了數(shù)據(jù)庫(kù)自動(dòng)切換平臺(tái)，實(shí)現(xiàn)了自動(dòng)和半自動(dòng)兩種切換方式，實(shí)現(xiàn)了按單集群級(jí)別、多集群級(jí)別、機(jī)房級(jí)別等多維度的場(chǎng)景切換。

切換過程包含監(jiān)控的修改、資產(chǎn)信息的修改、備份策略的修改、主從角色的修改等，一鍵化完成，避免人為因素帶來的二次故障。

分布式檢測(cè)

作為切換系統(tǒng)的核心組件，分布式檢測(cè)功能主要解決系統(tǒng)容災(zāi)方面的問題。

按照京東數(shù)據(jù)庫(kù)服務(wù)器多數(shù)據(jù)中心部署的特征，獨(dú)立的數(shù)據(jù)中心各部署了一個(gè)檢測(cè)節(jié)點(diǎn)，并通過特殊標(biāo)識(shí)的接口域名區(qū)分。

當(dāng)發(fā)生切換操作時(shí)，切換系統(tǒng)會(huì)根據(jù)傳入的故障主機(jī) IP 等信息，隨機(jī)選取兩個(gè)機(jī)房接口執(zhí)行調(diào)用，探活操作如果發(fā)現(xiàn)有一個(gè)節(jié)點(diǎn)主機(jī)存活，那么認(rèn)為主機(jī)存活;如果發(fā)現(xiàn)兩個(gè)節(jié)點(diǎn)都探測(cè)為宕機(jī)，那么認(rèn)為主機(jī)宕機(jī)。

Master 故障切換

主庫(kù)實(shí)例故障，切換系統(tǒng)會(huì)首先通過分布式檢測(cè)系統(tǒng)檢查實(shí)例存活狀態(tài)，確認(rèn)宕機(jī)后將根據(jù)基礎(chǔ)信息中的實(shí)例切換標(biāo)識(shí)，選擇使用自動(dòng)切換或手動(dòng)切換，兩種切換方式原理相同。

先在切換系統(tǒng)上創(chuàng)建切換任務(wù)，手動(dòng)切換需要 DBA 執(zhí)行切換按鈕，切換操作會(huì)通過 Insert 方式插入數(shù)據(jù)以驗(yàn)證實(shí)例運(yùn)行狀態(tài)，避免實(shí)例夯住和硬盤只讀的情況。

如果沒有存活的從庫(kù)，則放棄本次操作并以郵件和短信的方式通知 DBA。新主庫(kù)是按照先本地(先連接數(shù)少，后 QPS 負(fù)載低)，后異地的原則選擇，執(zhí)行切換成功后將變更相應(yīng)元數(shù)據(jù)信息，示例如下：

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

 

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

 

選目標(biāo)實(shí)例，假如例子中的 4 個(gè)從都是存活的，那么根據(jù)先本地后異地原則，選出 10.66.66.68:3366，10.66.66.69:3366。

然后再去查連接數(shù)，在連接數(shù)都相同的情況下，則去比較 QPS，選出 QPS 負(fù)載低的 10.66.66.69:3366 作為目標(biāo)實(shí)例：

 

切換完成結(jié)果如下圖：

 

Slave 故障切換

從庫(kù)實(shí)例故障，將故障實(shí)例下的域名變更到該集群下的非故障實(shí)例上，選擇目標(biāo)實(shí)例方式與主庫(kù)實(shí)例選擇規(guī)則一致。

切換成功或失敗都會(huì)發(fā)郵件及短信告知相應(yīng)的 DBA。故障實(shí)例恢復(fù)后，DBA 判斷是否需要回切。示例如下：

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

 

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

 

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

 

主從計(jì)劃性切換

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

 

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

批量執(zhí)行切換：

 

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

 

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

數(shù)據(jù)庫(kù)自動(dòng)化備份恢復(fù)

架構(gòu)設(shè)計(jì)

京東數(shù)據(jù)庫(kù)備份系統(tǒng)在設(shè)計(jì)之初，就是為了將 DBA 從繁雜的備份管理工作中解脫出來，實(shí)現(xiàn)自動(dòng)處理，減少人為干預(yù)，并提高備份文件的可用性。

關(guān)于備份文件可用性問題，以輪詢恢復(fù)的策略確保每個(gè)集群在一個(gè)周期內(nèi)都被恢復(fù)到。

系統(tǒng)架構(gòu)設(shè)計(jì)如下圖所示：

 

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

調(diào)度觸發(fā)多樣化，調(diào)度中心支持三種類型的觸發(fā)方式：

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

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

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

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

備份策略增刪改查：之前公司的備份系統(tǒng)是需要指定特定的 IP，經(jīng)常因?yàn)榉?wù)器維護(hù)而導(dǎo)致備份失敗，故在設(shè)計(jì)之初就將備份策略與高可用結(jié)合在一起，備份策略指定域名而不是 IP。

從庫(kù)因?yàn)楣收锨袚Q時(shí) DBS 會(huì)將此從庫(kù)上的域名切換到集群內(nèi)的其他從庫(kù)，相應(yīng)的備份也跟隨到了此從庫(kù)，保證了備份服務(wù)器是可用的。

失敗自動(dòng)重試：備份很可能因?yàn)榕既灰蛩囟。虼思尤肓藗浞葜卦嚨墓δ?，?huì)對(duì) 6 小時(shí)以內(nèi)的備份失敗任務(wù)進(jìn)行備份重試，最多重試 3 次，來獲得更高的備份成功率。

自動(dòng)恢復(fù)檢測(cè)：備份在每一步都要嚴(yán)格地驗(yàn)證，但是也無法絕對(duì)保證備份文件可用，因此引入了自動(dòng)恢復(fù)檢測(cè)機(jī)制，來幫助 DBA 對(duì)備份文件進(jìn)行檢測(cè)，及時(shí)發(fā)現(xiàn)因?yàn)楦鞣N未考慮到的情況導(dǎo)致備份文件不可用的情況。

并且恢復(fù)檢測(cè)也是審計(jì)的一個(gè)硬性要求，自動(dòng)恢復(fù)檢測(cè)也將 DBA 從繁重的恢復(fù)檢測(cè)工作中徹底解脫了出來。

調(diào)度設(shè)計(jì)

 

整個(gè)自動(dòng)化備份恢復(fù)系統(tǒng)主要由調(diào)度系統(tǒng)、備份系統(tǒng)、恢復(fù)系統(tǒng)、恢復(fù)檢測(cè)系統(tǒng)、自動(dòng)修復(fù)系統(tǒng)組成。

其中調(diào)度系統(tǒng)是整個(gè)系統(tǒng)核心，通過調(diào)度系統(tǒng)來協(xié)調(diào)其他系統(tǒng)運(yùn)行。調(diào)度系統(tǒng)可以部署 Standby 來實(shí)現(xiàn)高可用，執(zhí)行器以集群部署來實(shí)現(xiàn)高可用和橫向擴(kuò)容。

備份系統(tǒng)每次備份時(shí)都會(huì)進(jìn)行實(shí)例健康狀態(tài)檢查、備份運(yùn)行狀態(tài)檢查等，防止對(duì)無效的數(shù)據(jù)庫(kù)實(shí)例進(jìn)行備份。

恢復(fù)系統(tǒng)主要是在需要進(jìn)行數(shù)據(jù)恢復(fù)、彈性擴(kuò)容等需要從備份文件恢復(fù)成運(yùn)行的數(shù)據(jù)庫(kù)實(shí)例時(shí)使用，能夠讓 DBA 通過簡(jiǎn)單地操作即可完成數(shù)據(jù)的恢復(fù)。

恢復(fù)檢測(cè)在調(diào)度系統(tǒng)的指揮下自動(dòng)對(duì)備份文件可用性進(jìn)行檢測(cè)，來幫助 DBA 及時(shí)發(fā)現(xiàn)不可用的備份文件。

備份失敗有些是能夠通過失敗自動(dòng)重試來解決，但有一部分是重試所不能解決的，需要進(jìn)行相應(yīng)修復(fù)，因此開發(fā)了自動(dòng)修復(fù)系統(tǒng)來自動(dòng)修復(fù)因?yàn)榄h(huán)境等問題引起的備份失敗。

這里調(diào)度系統(tǒng)是最核心的一個(gè)系統(tǒng)，是整個(gè)備份恢復(fù)系統(tǒng)的大腦，當(dāng)時(shí)考察了幾種實(shí)現(xiàn)方式。

例如 Linux 的 crontab、Azkaban 和 Python 的開源框架 APScheduler，最終認(rèn)為 APScheduler 更加靈活小巧，調(diào)度方式也更加多樣化，使用 Python 開發(fā)后期維護(hù)成本更低，因此采用 APScheduler 開發(fā)了調(diào)度中心。

系統(tǒng)前端

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

備份策略管理：

 

備份策略管理的頁(yè)面包含了備份狀態(tài)分布情況、存儲(chǔ)使用情況以及每個(gè)集群的當(dāng)前備份策略狀態(tài)。

如果已經(jīng)添加了備份策略則可以在這里進(jìn)行(時(shí)間、服務(wù)器、備份方式)修改、暫停(繼續(xù))、刪除操作，如果沒有添加備份策略，則可以進(jìn)行添加。

備份詳情：

 

備份詳情里面展示了最近備份總數(shù)、成功數(shù)、成功率、當(dāng)天備份任務(wù)運(yùn)行狀態(tài)、備份任務(wù) 24 小時(shí)分布曲線圖以及備份詳細(xì)記錄。

備份詳細(xì)的記錄可以根據(jù)集群名、項(xiàng)目名等信息進(jìn)行查詢，方便 DBA 更好地掌握備份運(yùn)行狀況。

恢復(fù)檢測(cè)詳情：

 

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

數(shù)據(jù)庫(kù)變革

過去

在 ContainerDB 之前，京東的數(shù)據(jù)庫(kù)服務(wù)實(shí)現(xiàn)了容器化，雖然數(shù)據(jù)庫(kù)服務(wù)已經(jīng)完全通過 Docker 容器實(shí)現(xiàn)了數(shù)據(jù)庫(kù)服務(wù)的快速交付和自動(dòng)故障切換等基本功能，在一定程度上提高了數(shù)據(jù)庫(kù)服務(wù)的穩(wěn)定性和效率。

但是數(shù)據(jù)庫(kù)服務(wù)的運(yùn)維和使用方式與傳統(tǒng)方式基本無異，比較典型的問題如下：

資源分配粒度過大

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

資源浪費(fèi)嚴(yán)重

資源分配的標(biāo)準(zhǔn)由 DBA 根據(jù)經(jīng)驗(yàn)決定，存在很大的主觀性，不能根據(jù)業(yè)務(wù)的實(shí)際情況進(jìn)行準(zhǔn)確評(píng)估。

而 DBA 在分配資源的時(shí)候一般都會(huì)考慮在 3 年以內(nèi)不需要對(duì)服務(wù)進(jìn)行遷移或者擴(kuò)容，而一次分配比較多的資源，存在嚴(yán)重資源浪費(fèi)。

而且由于數(shù)據(jù)庫(kù)資源標(biāo)準(zhǔn)固定，標(biāo)準(zhǔn)過大，導(dǎo)致宿主機(jī)中的碎片過大，經(jīng)常出現(xiàn)一臺(tái)宿主機(jī)只能創(chuàng)建一個(gè)容器，而剩下的資源滿足不了任何資源標(biāo)準(zhǔn)，導(dǎo)致宿主機(jī)上資源使用率過低。

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

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

現(xiàn)在

基于以上的問題，單純的數(shù)據(jù)庫(kù)服務(wù)容器化已經(jīng)無法解決，我們需要讓數(shù)據(jù)庫(kù)服務(wù)更聰明，讓數(shù)據(jù)庫(kù)的資源能夠動(dòng)起來，提供資源分期交付的功能，于是 ContainerDB 應(yīng)運(yùn)而生。

ContainerDB 基于負(fù)載的彈性調(diào)度為京東的數(shù)據(jù)庫(kù)資源賦予了智慧，令其資源真正地流動(dòng)起來，并已成功服務(wù)于多次 618 和 11.11 大促。

 

ContainerDB 針對(duì)每個(gè)業(yè)務(wù)應(yīng)用都有邏輯庫(kù)，邏輯庫(kù)中定義了針對(duì)整個(gè)業(yè)務(wù)所有表的拆分鍵(Sharding Key)進(jìn)行哈希取模運(yùn)算時(shí)模的范圍(KeySpace)，在每個(gè)邏輯庫(kù)中可以創(chuàng)建多張表，但是每個(gè)表中必須定義 Sharding Key。

通過該 Sharding Key 將表中的數(shù)據(jù)拆分成多個(gè)分片(Shard)，每個(gè)分片都對(duì)應(yīng)一個(gè) KeyRange，KeyRange 表示對(duì) Sharding Key 進(jìn)行哈希取模運(yùn)算之后得到的值(Sharding Index)的一個(gè)范圍。

每個(gè) Shard 都由一整套 MySQL 主從架構(gòu)提供數(shù)據(jù)庫(kù)服務(wù)支撐。應(yīng)用程序只跟 Gate 集群進(jìn)行交互，由 Gate 根據(jù)元數(shù)據(jù)信息和 SQL 語(yǔ)句完成數(shù)據(jù)寫入和查詢的自動(dòng)路由。

ContainerDB 中的監(jiān)控中心會(huì)對(duì)所有的基礎(chǔ)服務(wù)和資源使用狀況進(jìn)行實(shí)時(shí)監(jiān)控，并通過在監(jiān)控中心注冊(cè)的 Hook 程序自動(dòng)進(jìn)行動(dòng)態(tài)擴(kuò)容、故障自愈、分片管理等，而這一系列操作對(duì)應(yīng)用程序來說是完全無感知的。

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

 

數(shù)據(jù)庫(kù)以前的服務(wù)存在資源浪費(fèi)的一個(gè)主要原因就是資源初始分配粒度太大，一開始就為業(yè)務(wù)提前預(yù)支 3 年甚至 5 年的資源。

而資源池中的資源是有限的，不可能讓所有業(yè)務(wù)都提前預(yù)支資源，從而導(dǎo)致有些業(yè)務(wù)沒有資源。ContainerDB 采用流式的方式進(jìn)行資源的持續(xù)交付。

每個(gè)業(yè)務(wù)接入初始都只會(huì)分配標(biāo)準(zhǔn)的 64G 硬盤，隨著業(yè)務(wù)的發(fā)展和數(shù)據(jù)量的持續(xù)增加，會(huì)持續(xù)增加硬盤容量直到到達(dá)硬盤限制的上限 256G。

 

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

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

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

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

遞增資源是指資源的使用率不會(huì)在短時(shí)間之內(nèi)出現(xiàn)嚴(yán)重的波動(dòng)，而是會(huì)緩慢增加，并且支持遞增，不會(huì)出現(xiàn)減少的情況，這種資源主要包括硬盤。ContainerDB 對(duì)于不同的資源采取了不同的調(diào)度策略。

針對(duì)于瞬時(shí)資源，ContainerDB 為每個(gè)數(shù)據(jù)庫(kù)分配三種標(biāo)準(zhǔn)：

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

每個(gè)容器分配的初始資源為標(biāo)準(zhǔn)的下限值，當(dāng)數(shù)據(jù)庫(kù)服務(wù)出現(xiàn) CPU 負(fù)載過高或者內(nèi)存不足時(shí)，會(huì)嘗試申請(qǐng)多于下限的 CPU 或者內(nèi)存。

但絕對(duì)不會(huì)超過上限，待負(fù)載恢復(fù)后釋放多申請(qǐng)的資源，直至恢復(fù)至 CPU 和內(nèi)存的下限為止。

 

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

垂直升級(jí)：首先會(huì)進(jìn)行資源 check，看宿主機(jī)是否有足夠的剩余硬盤資源進(jìn)行垂直升級(jí)，若 check 通過，則會(huì)在宿主機(jī)施加全局資源鎖，并對(duì)硬盤進(jìn)行垂直擴(kuò)容再增加 64G。

若 Check 不通過，則在宿主機(jī)上提供一個(gè)硬盤大小為：磁盤容量+64G 大小，CPU 和內(nèi)存與當(dāng)前容器相同的新容器，并將數(shù)據(jù)庫(kù)服務(wù)遷移到新的容器上。垂直升級(jí)是瞬間完成的不會(huì)影響數(shù)據(jù)庫(kù)服務(wù)。

在線 Resharding：申請(qǐng)兩個(gè)新的 Shard，新 Shard 中的數(shù)據(jù)庫(kù) Container 的硬盤、CPU 和內(nèi)存標(biāo)準(zhǔn)與當(dāng)前 Shard 中的完全一致。

根據(jù)當(dāng)前 Shard 中的數(shù)據(jù)庫(kù)主從關(guān)系，對(duì)新 Shard 中的所有數(shù)據(jù)庫(kù)重建 MySQL 主從關(guān)系，然后啟動(dòng) Schema 信息拷貝和過濾復(fù)制，最后更新路由規(guī)則并將讀寫流量切換到新的 Shard 上，將舊的 Shard 資源下線。

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

目前 ContainerDB 的親和/反親和性策略如下：

 

每個(gè) KeySpace 都有一個(gè)主機(jī)房，屬于同一個(gè) Shard 中的數(shù)據(jù)庫(kù)實(shí)例(目前一個(gè) Shard 中包含一主二從)的資源分配盡量應(yīng)該滿足：Master 必須屬于主機(jī)房，不能有任意兩個(gè)實(shí)例屬于同一機(jī)架，不能有任意三個(gè)實(shí)例在同一 IDC。

這種策略可以避免某一機(jī)柜掉電而導(dǎo)致主從同時(shí)出現(xiàn)故障，也可以避免 IDC 故障從而導(dǎo)致所有數(shù)據(jù)庫(kù)實(shí)例均不可用。

由于是盡量滿足，所以當(dāng)資源池中的資源分布不均時(shí)，就有可能在資源分配的時(shí)候滿足不了上述的反親和性策略。

因此 ContainerDB 有一個(gè)常駐后臺(tái)進(jìn)程，不停的輪詢集群中的所有 Shard，判斷 Shard 中的實(shí)例分布是否滿足反親和性規(guī)則，若不滿足，就會(huì)嘗試進(jìn)行實(shí)例重新分布。重新分布時(shí)為了不影響線上業(yè)務(wù)，會(huì)優(yōu)先進(jìn)行從庫(kù)重分布。

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

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

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

不止于調(diào)度

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

數(shù)據(jù)保護(hù)：在傳統(tǒng)的直連數(shù)據(jù)庫(kù)的方案下，當(dāng) Master 出現(xiàn)網(wǎng)絡(luò)不可達(dá)時(shí)，一般都會(huì)選擇新的 Slave 變?yōu)?Master，然后將原來 Master 上的域名漂移到新的 Master 上。

但是這種方案在網(wǎng)絡(luò)抖動(dòng)的情況下很容易由于 AppServer 上的 DNS 緩存，而導(dǎo)致雙 Master，并且出現(xiàn)臟寫的情況。從整體架構(gòu)圖可以看出，ContainerDB 與用戶之間通過 Gate 連接。

Gate 是一個(gè)集群化服務(wù)，多個(gè) Gate 服務(wù)都映射到一個(gè)域名下，Gate 通過 IP 地址直接訪問各個(gè) MySQL 服務(wù)，而且 Gate 對(duì)各個(gè) MySQL 角色的識(shí)別完全依賴于元數(shù)據(jù)服務(wù)：Topology。

當(dāng) ContainerDB 中某個(gè) MySQL 的 Master 產(chǎn)生網(wǎng)絡(luò)不可達(dá)時(shí)，會(huì)選出新的 Master，并更新路由元數(shù)據(jù)信息，最后才做 Master 切換。

這樣就避免了由于網(wǎng)絡(luò)抖動(dòng)和 DNS 緩存而在成雙主和數(shù)據(jù)臟寫，從而對(duì)數(shù)據(jù)進(jìn)行了嚴(yán)格的保護(hù)。

 

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

無感知數(shù)據(jù)遷移：ContainerDB 通過交叉在 Window 函數(shù)中分別執(zhí)行部分存量數(shù)據(jù)拷貝和增量數(shù)據(jù)追加的算法，開發(fā)了在線數(shù)據(jù)遷移和接入工具 JTransfer。

通過 JTransfer 可以將傳統(tǒng) MySQL 數(shù)據(jù)庫(kù)中的動(dòng)態(tài)數(shù)據(jù)遷移到 ContainerDB 中。

當(dāng) ContainerDB 中的數(shù)據(jù)與源 MySQL 中的數(shù)據(jù)的 lag 小于 5 秒時(shí)，首先會(huì)將源 MySQL 停寫，待 lag 變?yōu)?0 時(shí)將源 MySQL 的域名漂移到 Gate 集群，整個(gè)遷移過程用戶 AppServer 無感知。

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

路由規(guī)則透明：ContainerDB 與用戶之間通過 Gate 集群進(jìn)行連接，Gate 根據(jù)用戶發(fā)送的查詢語(yǔ)句形成的語(yǔ)法樹和查詢執(zhí)行計(jì)劃得到查詢中涉及到的所有表。

并根據(jù) Topology 中的元數(shù)據(jù)信息獲得各個(gè)表的分片信息，最后結(jié)合語(yǔ)句中的 Join 中的關(guān)聯(lián)條件和 Where 字句中的謂詞信息，將查詢或者寫入路由到正確的分片。整個(gè)過程都是 Gate 自動(dòng)完成的，對(duì)用戶完全透明。

自助化服務(wù)：ContainerDB 將對(duì)數(shù)據(jù)庫(kù)服務(wù)的實(shí)例化、DDL/DML 執(zhí)行、分片升級(jí)和擴(kuò)容等功能抽象成為獨(dú)立的接口。

并借助于流程引擎提供了流程化的完全自助的用戶接入服務(wù)，用戶申請(qǐng)數(shù)據(jù)庫(kù)服務(wù)成功后，ContainerDB 會(huì)將數(shù)據(jù)庫(kù)訪問口令自動(dòng)推送到用戶郵箱。

展望

過去已去，未來已來。我們后續(xù)會(huì)更多的從用戶的角度去思考數(shù)據(jù)庫(kù)能夠產(chǎn)生的價(jià)值。

我們相信京東以后的數(shù)據(jù)庫(kù)服務(wù)會(huì)：

• More Smart：我們會(huì)基于各個(gè)數(shù)據(jù)庫(kù)實(shí)例中 CPU/內(nèi)存/硬盤等各種不同資源的監(jiān)控?cái)?shù)據(jù)進(jìn)行深度學(xué)習(xí)和聚類分析。

分析出各個(gè)不同數(shù)據(jù)庫(kù)實(shí)例的傾向資源，并智能化調(diào)高每個(gè)數(shù)據(jù)庫(kù)實(shí)例傾向資源的限制并調(diào)低非傾向資源的限制。

• More Quick：我們會(huì)實(shí)時(shí)分析宿主機(jī)和容器的對(duì)應(yīng)關(guān)系、各個(gè)容器的限制參數(shù)以及各個(gè)容器的歷史資源增長(zhǎng)速率，預(yù)先對(duì)容器所在宿主機(jī)碎片進(jìn)行整理，從而盡量保證各個(gè)容器以垂直升級(jí)的方式實(shí)現(xiàn)擴(kuò)容，從而極大地加快擴(kuò)容速度。
• More Cheap：我們會(huì)提供完全自主研發(fā)的存儲(chǔ)引擎，計(jì)劃實(shí)現(xiàn)查詢引擎與存儲(chǔ)引擎的集成，并提供多模型數(shù)據(jù)庫(kù)引擎，從而實(shí)現(xiàn)多種數(shù)據(jù)模型的統(tǒng)一，極大節(jié)省數(shù)據(jù)庫(kù)服務(wù)所需資源以及研發(fā)成本。
• More Friendly：無論是 ContainerDB 還是我們自主研發(fā)的多模型數(shù)據(jù)庫(kù)，我們都會(huì)完全兼容 MySQL 協(xié)議及語(yǔ)法，從而使得現(xiàn)有應(yīng)用的遷移成本趨近于 0。
• More Open：ContainerDB 會(huì)在經(jīng)過京東內(nèi)部的各種場(chǎng)景的磨練之后會(huì)擁抱開源，并希望與業(yè)界各位同仁一起將 ContainerDB 不斷完善。

同時(shí)我們后續(xù)的多模型數(shù)據(jù)庫(kù)最終也會(huì)貢獻(xiàn)給開源社區(qū)，并期待其服務(wù)于業(yè)界。

作者：京東商城技術(shù)架構(gòu)部-數(shù)據(jù)庫(kù)技術(shù)部

簡(jiǎn)介：負(fù)責(zé)為京東商城提供高效穩(wěn)定的數(shù)據(jù)庫(kù)服務(wù)以及數(shù)據(jù)庫(kù)生態(tài)商品的研發(fā)，主要關(guān)注：數(shù)據(jù)庫(kù) AIOps 系統(tǒng)、數(shù)據(jù)庫(kù)內(nèi)核、多模型數(shù)據(jù)庫(kù)系統(tǒng)、彈性數(shù)據(jù)庫(kù)、BinLake、JTransfer 以及數(shù)據(jù)知識(shí)圖譜等產(chǎn)品的研發(fā)，部門秉承技術(shù)至上、不斷創(chuàng)新的理念在數(shù)據(jù)庫(kù)領(lǐng)域不斷前進(jìn)。