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

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

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

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

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

1、元數(shù)據管理

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

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

2、自動化部署

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

主要功能點包含以下內容：

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

3、智能分析與診斷

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

 

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

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

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

  

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

    

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

慢SQL分析：

   

索引分析：

   

空間分析及預測：

  

鎖分析：

  

（3）故障自愈 

  

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

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

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

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

（1）分布式檢測 

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

（2）Master故障切換 

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

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

  

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

 

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

  

• 切換完成結果： 

  

（3）Slave故障切換 

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

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

  

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

 

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

  

（4）主從計劃性切換  

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

集群1

  

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

批量執(zhí)行切換：

  

切換子任務詳細信息，可查看到每個子任務的切換結果，執(zhí)行步驟及前后架構：

  

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

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

（1）架構設計   

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

 

架構具備以下幾個特點： 

調度觸發(fā)多樣化  

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

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

并發(fā)控制 

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

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

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

維護期間任務不丟失 

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

備份策略增刪改查 

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

失敗自動重試  

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

自動恢復檢測 

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

（2）調度設計 

 

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

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

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

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

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

備份策略管理：

  

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

備份詳情：

  

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

恢復檢測詳情：

  

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

二、數(shù)據庫變革 

1、過去 

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

（1）資源分配粒度過大 

數(shù)據庫服務器資源標準固定，粒度過大，為數(shù)據庫服務可提供的資源標準過少。 

（2）資源浪費嚴重 

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

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

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

2、現(xiàn)在 

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

 

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

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

  

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

 

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

（2）基于負載的彈性調度 

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

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

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

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

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

  

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

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

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

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

  

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

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

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

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

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

（3）不止于調度 

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

數(shù)據保護

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

流式查詢處理

 

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

無感知數(shù)據遷移 

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

兼容MySQL協(xié)議

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

路由規(guī)則透明

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

自助化服務

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

3、展望

過去已去，未來已來。

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

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