京東彈性數(shù)據(jù)庫不是一個單一的產(chǎn)品，而是京東在對數(shù)據(jù)庫的使用、運維和開發(fā)過程中遇到的一系列問題的解決方案，和運維經(jīng)驗的總結(jié)升華進(jìn)而形成的一套產(chǎn)品系列，主要包括三大功能模塊：

核心功能模塊：JED，提供數(shù)據(jù)查詢和寫入的自動路由、自動彈性伸縮、自動FailOver、自動負(fù)載調(diào)度和數(shù)據(jù)庫服務(wù)智能自治的功能。 實時數(shù)據(jù)發(fā)布與訂閱模塊： BinLake，完全自助、無狀態(tài)、自動負(fù)載、完全自治、可橫向擴展的集群化Binlog采集和訂閱服務(wù)。 自動化運維模塊：DBS，實現(xiàn)了京東線上所有數(shù)據(jù)庫服務(wù)申請、DDL/DML上線、數(shù)據(jù)抽取等的流程化和自動化。

分享大綱：

1、發(fā)展歷程

2、功能特性

3、整體架構(gòu)

4、實現(xiàn)細(xì)節(jié)

5、使用情況

一、發(fā)展歷程

在我2011年加入京東之初，京東的數(shù)據(jù)庫正是處于諸侯混戰(zhàn)的階段，各種數(shù)據(jù)庫都有，包括：MySQL、PostGre、Oracle、SQL Sever，在2011年之后，開始去IOE，到了2014年，京東基本上完成了去IOE，所有的業(yè)務(wù)系統(tǒng)都遷移到了MySQL上。

在大規(guī)模使用MySQL的過程中，我們發(fā)現(xiàn)，隨著業(yè)務(wù)數(shù)據(jù)量的增長，很多業(yè)務(wù)開始了漫長的分庫、分表之旅，起初各個業(yè)務(wù)系統(tǒng)在自己的業(yè)務(wù)代碼中維護(hù)分庫分表的路由規(guī)則，而且各個業(yè)務(wù)系統(tǒng)的路由規(guī)則和整體設(shè)計都不一樣，后來由于人員更迭以至于業(yè)務(wù)代碼無法維護(hù)，不同業(yè)務(wù)使用的數(shù)據(jù)庫分庫分表模式不盡相同，導(dǎo)致數(shù)據(jù)庫的維護(hù)工作也難如登天。這時我們開始重新思考應(yīng)該提供什么樣的數(shù)據(jù)庫服務(wù)，得出了以下幾點：

統(tǒng)一分庫分表標(biāo)準(zhǔn) 路由針對業(yè)務(wù)透明 數(shù)據(jù)庫服務(wù)伸縮無感知 統(tǒng)一數(shù)據(jù)服務(wù) 業(yè)務(wù)研發(fā)自助申請服務(wù) 數(shù)據(jù)庫運維工作自動化

為了實現(xiàn)上述功能特點，我們分為兩步走：第一步是優(yōu)先解決業(yè)務(wù)和運維窘境，從而爭取足夠的時間和技術(shù)buffer進(jìn)一步完善產(chǎn)品，第二步是最終完美形態(tài)的產(chǎn)品研發(fā)。

因此，我們首先在2015年開發(fā)了JProxy，優(yōu)先解決緊急的業(yè)務(wù)和運維難題：分庫分表規(guī)則統(tǒng)一化和路由透明化。在拿到充分的時間buffer后，我們從2016年開始以匠人的精神精雕細(xì)琢京東彈性數(shù)據(jù)庫。

二、功能特性

如前面所說：京東彈性數(shù)據(jù)庫是一個產(chǎn)品系列，主要是解決數(shù)據(jù)庫的運維、使用和研發(fā)過程中的問題，具備動態(tài)伸縮、高可用、查詢透明路由、集群化日志服務(wù)和自動化運維等功能。

本章將就京東彈性數(shù)據(jù)庫三個核心模塊的功能進(jìn)行詳細(xì)說明。

1、JED（JD Elastic DataBase）

JED是JProxy功能的父集，它除了具備透明路由、統(tǒng)一分庫分表標(biāo)準(zhǔn)之外，還提供了五大功能：

（1）在線動態(tài)擴容

起初某個業(yè)務(wù)可能申請了4個分庫，后面隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)量越來越大，可能需要擴容到 8個分庫，一般的數(shù)據(jù)庫中間件在擴容時，需要與業(yè)務(wù)研發(fā)部門協(xié)商一個業(yè)務(wù)低谷期停業(yè)務(wù)，然后進(jìn)行擴容，擴容完畢后重新啟動業(yè)務(wù)。為了解決這個問題，JED提供了在線動態(tài)擴容功能，擴容只會對業(yè)務(wù)造成秒級影響，且無需人工介入。我們現(xiàn)在可以觸發(fā)自動擴容，設(shè)置的策略是當(dāng)磁盤的使用率達(dá)到80%，就自動進(jìn)行擴容。

（2）自動Failover

Master一旦出現(xiàn)宕機，哨兵檢測系統(tǒng)就會第一時間檢測到，會自動觸發(fā)注冊在哨兵檢測系統(tǒng)中的Hook程序，Hook程序就會選擇一個最新的Slave替換Master，然后更新ETCD中的元數(shù)據(jù)信息，業(yè)務(wù)方的下一次請求就會發(fā)送新的Master上。

（3）兼容MySQL協(xié)議

JED是完全兼容MySQL協(xié)議的，即通過MySQL的Client端或者標(biāo)準(zhǔn)的JDBC Driver都可以連接到JED的Gate層，然后進(jìn)行查詢和計算。

（4）多源數(shù)據(jù)遷移

我們基于ghost進(jìn)行改造，開發(fā)了京東的數(shù)據(jù)傳輸和接入工具： JTransfer，實現(xiàn)了業(yè)務(wù)數(shù)據(jù)的動態(tài)遷移。如果以前你的業(yè)務(wù)是運行在MySQL上的，現(xiàn)在要遷到JED上，你不需要停止任何業(yè)務(wù)，直接啟動JTransfer的數(shù)據(jù)遷移服務(wù)，就可以在后臺自動完成數(shù)據(jù)的同步和遷移。遷移完畢后，JTransfer會自行比對JED上的數(shù)據(jù)與原來數(shù)據(jù)的一致性和lag計算，當(dāng)數(shù)據(jù)完全一致，且lag小于5秒時，就會郵件通知業(yè)務(wù)方進(jìn)行復(fù)驗，復(fù)驗沒有問題，業(yè)務(wù)方直接將數(shù)據(jù)庫連接指向到JED就可以正常提供服務(wù)了。

（5） 數(shù)據(jù)庫審計

JED具有數(shù)據(jù)庫審計的功能，該功能實現(xiàn)在Gate層，在Gate層我們會得到應(yīng)用發(fā)送給JED的所有SQL，然后將SQL語句或者SQL模板發(fā)送給MQ。由于是在Gate層實現(xiàn)的，而Gate層與MySQL服務(wù)不在一個容器上，因此對MySQL服務(wù)不會產(chǎn)生任何的負(fù)面影響。

2、BinLake

BinLake只做一樣工作：集群化Binlog的采集和訂閱服務(wù)。BinLake之前，我們使用Canal進(jìn)行binlog采集，但我們發(fā)現(xiàn)存在資源浪費等問題：若一個業(yè)務(wù)需要采集MySQL Binlog，并且還需要HA保證的話，我們至少需要兩臺服務(wù)器。那多個業(yè)務(wù)怎么辦？于是我們開發(fā)了BinLake，其功能特性如下：

（1） 無狀態(tài)集群化BinLog采集

BinLake是一個集群化的BinLog采集和訂閱服務(wù)，并且與常規(guī)意義上的集群不一樣，我們的集群是沒有master節(jié)點的，而且集群中的所有工作節(jié)點都是完全平等的，這也就意味著，只要集群中的節(jié)點沒有全部宕機，BinLake集群可以一直提供服務(wù)。

（2） 高可用與自動故障轉(zhuǎn)移

針對于某個Mya實例的采集instance（每個instance代表一個線程）一旦掛掉，會在集群中的負(fù)載最低的工作節(jié)點上重新啟動一個instance，繼續(xù)從上次掛掉的Offset進(jìn)行采集，不會造成Binlog的丟失和重復(fù)。

（3） 負(fù)載自動均衡

假設(shè)所有Binlog的集群有八個節(jié)點，其中有七個節(jié)點的負(fù)載比較高，當(dāng)你在接入Binlog時，在沒有人工介入的衡量下，整個集群會將以新接入的一個Instance采集實例，自動選擇一個健康度最高的Wave服務(wù)，然后啟動Binlog采集。

（4） 支持多種MQ

BinLake采集到的所有binlog的event會被封裝成Message發(fā)送給MQ，目前我們支持JMQ和Kafka兩種MQ產(chǎn)品。

（5） 支持集群橫向擴容

當(dāng)BinLake集群的服務(wù)能力達(dá)到了瓶頸，我們可以簡單地將新的工作節(jié)點啟動，只需要在新的工作節(jié)點配置文件中配置上與線上的工作節(jié)點相同的ZooKeeper路徑，新的工作節(jié)點就會自動加入到已存在的BinLake集群中。

3、DBS

DBS主要完成自動化運維的工作。它可以完成數(shù)據(jù)庫服務(wù)的自動化交付、數(shù)據(jù)庫操作的流程化管理、數(shù)據(jù)庫健康指數(shù)全面監(jiān)控、數(shù)據(jù)庫自動備份及結(jié)轉(zhuǎn)，以及調(diào)度作業(yè)的多樣化調(diào)度（包括定時、依賴以及觸發(fā)三種調(diào)度模式）。

三、整體架構(gòu)

這是京東數(shù)據(jù)庫的一個整體架構(gòu)圖?？梢钥吹?，最底層是JDOS2.0，JDOS 2.0是京東新一代的容器技術(shù)，是Docker的管理平臺，實際上京東所有的數(shù)據(jù)庫服務(wù)現(xiàn)在已經(jīng)完全運行在Docker之上了，這一點是讓我們比較引以為豪的工作成績，而這些都離不開京東JDOS的底層支持。

JED包括六大組件：

JED-Gate：實現(xiàn)分庫分表的透明化路由和審計功能。 JED-Ctl：命令行控制工具。 JED-Ctld：也提供集群控制功能，但是它是以服務(wù)的方式提供API接口。 Topology：是整個JED的元數(shù)據(jù)管理中心，所有的元數(shù)據(jù)是通過Topology進(jìn)行管理的。 JED –Tablet：是每一個MySQL前端的Proxy，提供MySQL查詢緩存和流復(fù)制等。 JTransfer：在線數(shù)據(jù)遷移和接入工具。

BinLake的服務(wù)角色比較簡單，只有兩種服務(wù)：Wave和Tower。

BinLake整個集群是完全無狀態(tài)的。我們所知道的大部分集群化服務(wù)都是有狀態(tài)集群和不對等集群。所謂不對等集群就是集群里要有Master服務(wù)角色，負(fù)責(zé)整個集群的管理；還要有Worker服務(wù)角色，負(fù)責(zé)實際任務(wù)的執(zhí)行。但整個BinLake是沒有任何Master的，只有一種服務(wù)角色：Wave，就是你的工作節(jié)點。Tower只是一個可以與集群進(jìn)行交互式操作的HTTP服務(wù)。Tower與傳統(tǒng)Master節(jié)點的不同之處在于：它不負(fù)責(zé)任何元數(shù)據(jù)的管理，它只是向Topology服務(wù)發(fā)送命令，更新或者獲取存儲在ETCD或ZooKeeper中的元數(shù)據(jù)信息。

DBS是構(gòu)建于我們的API Platform之上的，API Platform是我們自己開發(fā)的一個簡單的Faas平臺，有了API Platform，在京東只要是會寫代碼的人，不管你用何種開發(fā)語言，只要是滿足Restful協(xié)議的服務(wù)，都可以注冊到API Platform中，并不斷豐富DBS。

DBS包括幾個核心模塊：

JGurd 是一個分布式檢測系統(tǒng)，它提供了對MySQL服務(wù)的完全分布式檢測，避免了因為網(wǎng)絡(luò)抖動而產(chǎn)生對MySQL健康狀況的誤判。 Scheduler是調(diào)度平臺，是基于Oozie改造開發(fā)的集群調(diào)度平臺。 JProcess Maker是DBS的流程引擎。 DBS-Tools是我們在數(shù)據(jù)庫運維過程中需要用到的一些數(shù)據(jù)庫工具，比如說AWS報告、監(jiān)控工具、Master切換工具、域名漂移工具等。 Authentication是京東內(nèi)部的身份認(rèn)證和權(quán)限控制組件。

下面我們針對JED、BinLake和DBS的架構(gòu)進(jìn)行詳細(xì)講解。

1、JED

JED的前端是AppServer，從整體架構(gòu)上，JED和Appserver直接打交道的只有一個角色，就是JED-Gate，JED-Gate完全兼容MySQL協(xié)議，AppServer可以一些查詢語句發(fā)送給JED-Gate，JED-Gate層對所有查詢的查詢執(zhí)行計劃都會做緩存，并且根據(jù)查詢執(zhí)行計劃，通過Topology服務(wù)獲得查詢所涉及表的路由源數(shù)據(jù)信息，根據(jù)元數(shù)據(jù)信息將查詢語句改寫或者拆分發(fā)送到底層的Shard上去。目前JED已經(jīng)滿足了廣域分布架構(gòu)，實現(xiàn)了異地多活。

2、BinLake

針對上圖的BinLake架構(gòu)圖，可以看到BinLake集群中的每個工作節(jié)點叫做Wave，每個Wave節(jié)點上有多個instance，這個instance就是針對于每個MySQL實例的Binlog采集線程，在同一個Wave實例上的多個instance實例通過Epoll模型實現(xiàn)高效網(wǎng)絡(luò)監(jiān)聽和通訊。當(dāng)用戶新采集一個MySQL的Binlog或者某個instance線程掛掉了，會根據(jù)當(dāng)前集群中各個Wave服務(wù)的健康狀況選擇一個健康度最高的Wave實例，去實例化這個新的instance線程。而每個Wave實例上的健康度是根據(jù)Zabbix的監(jiān)控數(shù)據(jù)進(jìn)行動態(tài)計算的。

從圖中可以看到，Tower服務(wù)其實沒有跟Wave服務(wù)做任何直接的通訊或者聯(lián)系，Tower只會跟ZK或ETCD集群直接做交互，它對ZK或者ETCD集群任何元數(shù)據(jù)的更改都被Wave服務(wù)及時發(fā)現(xiàn)，發(fā)現(xiàn)之后，Wave服務(wù)會采取一系列相應(yīng)的措施，來對元數(shù)據(jù)的更改進(jìn)行響應(yīng)。

3、DBS

DBS依賴于兩個基礎(chǔ)的服務(wù)進(jìn)行構(gòu)建，第一個是API Platform，第二個是JDOS， 通過API Platform實現(xiàn)DBS整個系統(tǒng)所有功能模塊的完全解耦，因為所有的底層操作都是單獨開發(fā)的符合Restful標(biāo)準(zhǔn)的HTTP服務(wù)，并通過API Platform暴露出來。不管是研發(fā)人員還是DBA，無論使用什么樣的開發(fā)語言，只要能夠開發(fā)出符合Restful的HTTP服務(wù)，就可以將其注冊到API Platform上，并實現(xiàn)DBS系統(tǒng)中特定的功能。

其實無論是JGuard、JProcessMaker、DBS-Tools還是Scheduler，它們做的所有工作都只有一樣：調(diào)用API Platform上所暴露的接口。API Platform會根據(jù)你的注冊信息，去調(diào)用Tower暴露的API接口，或者是調(diào)用MHA的一些腳本或者其它接口。

另外，不管是DBS的應(yīng)用服務(wù)器、MySQL服務(wù)器、API Platform，后端寫的所有接口，我們都會采集這些服務(wù)上的所有日志，采集了之后接入到Unilog Platform，用于后續(xù)的日志的審計和檢查。

四、實現(xiàn)細(xì)節(jié)

由于京東彈性數(shù)據(jù)庫包含的功能和組件很多，下面我選出幾個特定的功能，在實現(xiàn)細(xì)節(jié)上詳細(xì)說明。

1、動態(tài)在線擴容

Step1：創(chuàng)建兩個目標(biāo)Shard

假設(shè)某個業(yè)務(wù)方在JED中起初申請了一個Shard，這個Shard大家可以把它簡單地想象成是一套MySQL集群，這時我要將它擴容成兩個Shard。

假設(shè)現(xiàn)在有一萬條記錄，要擴成兩個Shard，那么每個目標(biāo)Shard里面就有5000條。在JED里，在觸發(fā)擴容這個動作時，首先會通過 JDOS接口，將目標(biāo)Shard的所有POD都創(chuàng)建并啟動起來，如果每個目標(biāo)Shard都是1主2從，總共會啟動6個POD，12個Container（一個POD中有2兩個Container，1個Container中是Tablet服務(wù)，1個Container是MySQL服務(wù)），然后每個POD都是 Not Sevring狀態(tài)，其中每三個POD實例組成一個Target shard。可以看到，Source Shard中的sharding key對應(yīng)的key range是：0x00-OxFF，這里的 KeyRange也就是你的sharding key經(jīng)過哈希之后能夠落到多大的范圍，現(xiàn)在要將一個Source Shard分為兩個Target Shard，所以Source Target對應(yīng)的Key Range也要就要一分為二，可以看到兩個Target Shard 對應(yīng)的KeyRange是0x00-Ox80，Ox80-Oxff，并且是Not Serving狀態(tài)。

Step2：全量數(shù)據(jù)過濾克隆

兩個Target Shard建立之后，會根據(jù)ETCD里的默認(rèn)配置針對每個Target Shard建立MySQL的復(fù)制關(guān)系，比如一主兩從：一個Master，一個Replication，一個ReadOnly；一主三從，一個Master，兩個Replication，一個Readonly；一主四從，一個Master，兩個Replication和兩個ReadOnly。

建立完復(fù)制關(guān)系之后，首先會通過JED-Worker將Source Shard中的Schema信息復(fù)制到兩個TargetShard中，然后將Source Shard中的ReadOnly Pod從MySQL復(fù)制關(guān)系中摘除下來，最后通過JED-Worker將ReadOnly中的數(shù)據(jù)過濾拷貝到兩個TargetShard中。

Step3：增量數(shù)據(jù)過濾到兩個目標(biāo)Shard

現(xiàn)在我們以最簡單的一拖二的方式來講述。當(dāng)你的兩個TargetShard建立完成后，你要做的就是先把你的這一萬行記錄拷到兩個shard上，拷完之后去建立過濾復(fù)制。

完成了Step2的過濾拷貝之后，將ReadOnly重新掛到Source Shard上，然后JED-Worker通過Replication中的接口創(chuàng)建binlog的過濾復(fù)制，會在Replication上啟動兩個協(xié)程，并根據(jù)Target Shard的Key Range分別將binlog復(fù)制到對應(yīng)的TargetShard上。

Step4：數(shù)據(jù)一致性校驗

當(dāng)TargetShard中的binglog與SourceShard中的binlog的lag小于5秒的時候，會啟動數(shù)據(jù)的一致性校驗，該過程是在JED-Worker上完成的。過程很簡單，就是通過大量的后臺協(xié)程Target和Source上去取出數(shù)據(jù)一條一條對比，如果數(shù)據(jù)的一致性校驗通過，就開始進(jìn)行Shard切換。

Step5：切Shard

首先將SourceShard中Slave的Serving狀態(tài)切換成Not Serving，同事將TargetShard中Slave的Not Serving狀態(tài)更改為Serving，最后將Source中的Master停寫，等Target中的Master與Source中的Master無復(fù)制延時后，將Source Master停寫，通過JED-Worker將過濾復(fù)制斷掉，然后將Target的Master置為Serving狀態(tài)，并接受寫入。

上述的所有Serving與NotServing狀態(tài)的改變均是通過改變etcd中的元數(shù)據(jù)來完成的。當(dāng)前端性業(yè)務(wù)再發(fā)送新的查詢過來時，Gate就會根據(jù)最新的元數(shù)據(jù)信息，將你的這條SQL發(fā)送到最新的Target Shard。

2、自動FailOver

以1主3從的MySQL主從架構(gòu)對JED的自動FailOver機制進(jìn)行說明。

如果Master發(fā)生異常，JGuard會通過分布式檢測（JGuard是通過ORC改造之后形成了一個分支檢測服務(wù)）檢測異常，檢測到異常之后會通過郵件和短信通知業(yè)務(wù)接口人，通知完之后，不會等業(yè)務(wù)接口人進(jìn)行處理，直接從當(dāng)前整個MySQL集群當(dāng)中選擇一個GTID最大的一個MySQL實例，將這個MySQL實例切成Master，并根據(jù)新的Master重建新MySQL主從復(fù)制關(guān)系，將剩余的Replication和ReadOnly重新掛載到新的Master上，再調(diào)用JED-Ctrld服務(wù)的接口更新ETCD中的元數(shù)據(jù)，這樣后續(xù)的DDL/DML就會發(fā)到最新的Master之上。最后缺失的一個Tablet需要人工補入。

3、Streaming Process

JED實現(xiàn)了查詢的流式處理，以查詢語句select table_a.age from table_a order by table_a.age為例說明流式處理的過程。JED-Gate接收到該查詢語句之后，會根據(jù)ETCD中的分片元數(shù)據(jù)，將該語句分發(fā)到三個Shard中，各個Shard返回給JED-Gate數(shù)據(jù)本身就是有序的，在JED-Gate中針對每個Shard都會有一個buffer與之對應(yīng)，每個buffer用來流式的接收每個Shard返回的排序完畢的數(shù)據(jù)，因此該buffer中的數(shù)據(jù)也是有序的。然后將每個buffer的首地址存儲到一個PriorityQueue里面， PriorityQueue是一個堆排序的優(yōu)先級隊列，會根據(jù)每個buffer中的首元素不斷的進(jìn)行排序。每從PriorityQueue中取出一個元素，PriorityQueue都會調(diào)整Buffer的先后順序，JED-Gate會將元數(shù)一個一個地取出來，以流式的方式發(fā)給前端，從而實現(xiàn)整體流式排序。

4、Join處理

現(xiàn)在我們看下如何在JED上執(zhí)行Join查詢的，在下面所有的說明中，我們都有一個假設(shè)條件，就是所有的表的sharding key都是ID。

對Join查詢的處理，要分情況：

第一種情況：Join Key與Sharding Key相同。這種情況下由于Join Key 和 Sharding Key是完全相同的，因此是可以將Join查詢語句直接發(fā)送到下面的每個shard，在JED-Gate匯聚各個shard的部分查詢結(jié)果，并返回給前端應(yīng)用。

第二種情況：Join Key與Sharding Key相同。如上圖所示，比如Select a.col,b.col.from a join b on b.id_2=a.id where a.id=0。針對該查詢語句，JED-Gate首先對其進(jìn)行SQL語句改寫，改寫為兩條語句：select a.col,a.id from a where a.id=0和select b.col from b where b.id_2=a.id。在第二個查詢語句中的a.id是綁定變量。JED-Gate會首先根據(jù)select a.col,a.id from a where a.id=0，定位到該SQL需要定位到哪個shard，然后將SQL發(fā)送到相應(yīng)的Shard執(zhí)行，并流式的獲取其結(jié)果，然后將結(jié)果中的a.id字段的值取出，并將值賦給select b.col from b where b.id_2=a.id語句中的綁定變量a.id，然后將復(fù)制后的第二條SQL語句依次發(fā)送給所有的shard，并將結(jié)果與第一條SQL語句中的結(jié)果組合，流式地返回給前端。

當(dāng)多級Join的時候，也是相同的思路，這里不再贅述。

5、BinLake元數(shù)據(jù)架構(gòu)圖

前面已經(jīng)提到BinLake有一個很大的特點：一個完全無狀態(tài)的集群，沒有Master管理節(jié)點。而要實現(xiàn)這個特性最重要的就是要有合理的元數(shù)據(jù)設(shè)計。之所以沒有Master節(jié)點，是因為把Master節(jié)點的功能委托給了ZooKeeper或ETCD。通過借助ZooKeeper中的ephemeral znode實現(xiàn)了Wave服務(wù)乃至instance的自動發(fā)現(xiàn)和HA，并最終實現(xiàn)了無Master，無狀態(tài)的完全對等集群。

根據(jù)上面的元數(shù)據(jù)架構(gòu)我們對BinLake的所有元數(shù)據(jù)進(jìn)行詳細(xì)說明。

一個BinLake集群的root znode是一個名為wave的znode，在wave之下是一系列的形式為：“MySQL域名命名:port”的znode。這樣的每個znode都對應(yīng)了一個MySQL實例。而在每個MySQL實例對應(yīng)的znode下面是該MySQL實例的管理、信息保存和選舉znode。其中counter節(jié)點中記錄了當(dāng)前MySQL實例對應(yīng)的instanc重啟了幾次，若連續(xù)重啟超過7次，就會發(fā)出報警信息。而dynamic節(jié)點則記錄了每個MySQL實例對應(yīng)的Binlog采集線程對應(yīng)的快照信息，包括：當(dāng)前采集到的Binlog文件、Offset、Timestamp、GTID、最近的10個時間點Binglog位置和Filter Rules等，從而保證instance重啟后，可以利用這些信息繼續(xù)進(jìn)行Binlog采集。后面的sequencenumber對應(yīng)的一系列znode是由Curator自動創(chuàng)建的znode，來保證選舉的正確性和防止羊群效應(yīng)。而“Bingdleader：wavehost”對應(yīng)的znode，主要用于人工介入binlake，從而指定讓下次instance leader選舉的時候，固定在wavehost對應(yīng)的Wave節(jié)點上。

如果我某個MySQL采集的Instance掛了，Curator就會在后面的第一個znode對應(yīng)的wave服務(wù)上首先進(jìn)行l(wèi)eader選舉，若成功選舉，就接入，否則依次對后面對應(yīng)的每個Wave實例進(jìn)行選舉，直到成功選舉出leader。選舉出新的leader之后，就會在對應(yīng)的Wave服務(wù)上重啟Binlog采集的instance線程，該instance就會根據(jù)dynamic znode中存儲的快照信息重建MySQL的復(fù)制關(guān)系，繼續(xù)進(jìn)行Binlog采集。

6、集群化Binlog訂閱

BinLake中的Binlog采集方式有兩種：時序和亂序。

時序：通過NIO實現(xiàn)的類似Epoll的網(wǎng)絡(luò)模型監(jiān)聽所有與MySQL之間的鏈接的網(wǎng)絡(luò)事件等檢測到與某個MySQL之間的連接有byte流到達(dá)時，就會盡量多的讀取所有的byte流，將其全部放到一個Byte Buffer里，然后通過Worker Thread對ByteBuffer中的Byte進(jìn)行Decode，并解析成一個個的EventMsg，進(jìn)而將EventMsg也放到一個MessageBuffer中，在MessageBuffer后面有一個Handler線程，這個Handler線程會根據(jù)ZooKeeper里的一些元數(shù)據(jù)信息（比如：Topics、FilterRules、MQ類型和地址等）對EventMessage進(jìn)行處理，然后使用protobuff進(jìn)行序列化后發(fā)送到正確MQ中的特定的Topic里。這里的處理包括：根據(jù)庫表類型過濾、列過濾、事務(wù)頭Event和尾Event過濾等。

亂序：同從上圖中可以看出亂序處理與時序處理的前半部分是相同的，只是在EventMessage Buffer后面是通過線程池進(jìn)行并發(fā)處理的，測試結(jié)果表明亂序處理的性能是時序處理性能的10倍。

五、落地使用

從上圖可以看出，JED數(shù)據(jù)庫中間件服務(wù)通過JTransfer來實現(xiàn)MySQL和JED之間的數(shù)據(jù)正反向同步和傳輸。現(xiàn)在JED可以實現(xiàn)MySQL向Oracle、Postgres等多種數(shù)據(jù)庫的實時數(shù)據(jù)同步和傳輸。BinLake可以對MySQL和JED中的Binlog進(jìn)行采集，并發(fā)送到JMQ或者Kafka，在MQ后端有兩種使用方式：

通過Spark Streaming把它同步到HBase里，目前京東內(nèi)部實際上是有一個項目叫做實時數(shù)據(jù)快照，就是通過這種方式，實現(xiàn)了HBase中的數(shù)據(jù)與線上MySQL實例中的數(shù)據(jù)的完全實時同步更新。

下游各個業(yè)務(wù)部門各自通過Consumer消費，進(jìn)而進(jìn)行訂單積壓監(jiān)控、智能報表以及營銷實時推薦等。當(dāng)然JED以及BinLake、Jtransfer都是通過DBS進(jìn)行自動化運維、調(diào)度和管理的。

京東彈性數(shù)據(jù)庫落地狀況

這些是在9月份從DBS系統(tǒng)里面拿到的，服務(wù)線上業(yè)務(wù)是指上線項目的個數(shù)，目前京東彈性數(shù)據(jù)庫服務(wù)了線上3122個項目，管理的MySQL實例個數(shù)有將近兩萬個，管理的Table就比較多了，有660多萬個，并且完成了自動在線切換2700余次，自動化上線有27000余次?，F(xiàn)在京東有一般的業(yè)務(wù)都遷到了JED上，當(dāng)然還有一半的業(yè)務(wù)正在容器化的MySQL服務(wù)上并逐步地進(jìn)行遷移。

分片數(shù)與OPS、延時的關(guān)系情況

上圖是JED的分片數(shù)與OPS以及分片數(shù)延時的一些關(guān)系。從圖中可以看出，隨著分片數(shù)的增加JED的服務(wù)能力也出現(xiàn)線性增長的趨勢。而隨著分片數(shù)的增加延時幾乎沒有變化（延時的單位是毫秒）。

Gate數(shù)與OPS、延時的關(guān)系情況

上圖是Gate數(shù)目與OPS以及Gate數(shù)目與延時的關(guān)系。從圖中可以看出，通過簡單的增加Gate的數(shù)目而實現(xiàn)JED數(shù)據(jù)庫服務(wù)能力的橫向擴展，不會導(dǎo)致明顯的延時增加。

問答環(huán)節(jié)

【問題1】想咨詢一下咱們的JED做故障切換之后，如果存在數(shù)據(jù)的復(fù)制延遲，這時直接把它切為Read Write狀態(tài)，有部分的Binlog數(shù)據(jù)還沒追上來，臟數(shù)據(jù)怎么辦？這部分臟數(shù)據(jù)是人工介入進(jìn)行處理，還是有什么其它方案來把它自動處理？

答：JED在做Master FailOver時，實際就是你在后端做分片的時候，看MySQL的復(fù)制模式是半同步還是異步，如果是半同步，一旦發(fā)現(xiàn)你的Master Fail Over，不會出現(xiàn)所有Slave都lag Master的Binlog。

追問：就是說在Binlog追上之前還是ReadOnly狀態(tài)，binlog完全追上之后，才切換為ReadWrite嗎？

答：舉個例子，比如說你后端Master下掛了兩個Slave或者是多個Slave，因為你啟用的是半同步，那么只要你里面沒有任何一個追上Master（相當(dāng)于是你的Master都是 ReadOnly狀態(tài)），這個并不是說在Failover里存在這個問題，而是即使單純的MySQL服務(wù)啟用的若是半同步，當(dāng)沒有任何一個Slave追上Mater的時候，Master肯定是ReadOnly。

【問題2】老師好，因為剛才我聽了JED，想問一下JED里有沒有異構(gòu)數(shù)據(jù)庫？比如說，如果我要像你說到的有互相轉(zhuǎn)這種情況，那么我要同時轉(zhuǎn)幾個表，在不同的異構(gòu)數(shù)據(jù)庫里面，我要如何保證它的查詢速率？比如說各個表，我同事要加一個索引，我有沒有統(tǒng)一配置的情況，還是集群里的每個庫都要重新再各配一次？

答：說實話，沒聽太清楚你說什么，就說一個實際的例子吧，你的意思就是說JED里面有一個庫，實際上就叫KeySpace，下面有四個分庫或者四個分表你現(xiàn)在要統(tǒng)一對KeySpace中的所有分庫或者分表加索引，它怎么去做，是嗎？

追問：是每個分庫都要加嗎？這樣的話是不是每個分表都要加一條索引，有沒有可以統(tǒng)一一次性配置的功能？

答：在JED里面實際上是有一個控制臺的，目前不支持直接通過Gate執(zhí)行DDL，就是說DDL在Client或是通過JBDC Driver是不允許執(zhí)行的，直接就會報錯，你如果要執(zhí)行DDL，是通過DBS自動化上線流程通過JED Ctld服務(wù)去執(zhí)行的，Ctld服務(wù)會找到你KeySpace下的所有Shard，然后在每個Shard里面去執(zhí)行這些DDL。

【問題3】有兩個問題想請教一下，一是剛才演講中聽您說這個彈性數(shù)據(jù)庫有好和壞的東西，那我能不能單獨用一個組件一樣的東西直接移植到JED上，其它東西不用行不行？我這邊的這個數(shù)據(jù)庫是主要是可以擴容的，但我們業(yè)務(wù)簡單一點，可能沒那么多。

答：京東彈性數(shù)據(jù)庫現(xiàn)在包括三大模塊，你可以單獨地去用JED或者BinLake，但你不能夠單獨去用DBS，因為你如果單獨用JED或者BinLake，你是可以脫離京東的自動化運維管理系統(tǒng)的控制，后續(xù)的審批當(dāng)然是沒有了的，可你對于BinLake這個集群以及JED的管理，是完全依賴于它的API是做控制的，就是說，后續(xù)假如說你公司有自己的一套運維管理系統(tǒng)，你可以基于BinLake或者JED的API，跟你的自動化運維管理系統(tǒng)集成，這個沒問題，但你如果只用DBS就不行了，因為DBS是完全地跟京東的JDOS耦合的，這就是為什么我們可以實現(xiàn)數(shù)據(jù)庫服務(wù)資源的一個自動化交付和自動化運維，實際上是建立在這個JDOS之上的，因為京東所有的數(shù)據(jù)庫都已經(jīng)上Docker了，所有的數(shù)據(jù)庫服務(wù)均運行在Docker里，不管是JED還是傳統(tǒng)的MySQL服務(wù)，都是運行在Docker之上的，所以說你只能夠單獨地用其中兩個組件，一個是BinLake，一個是JED。

追問：另外一個問題就是說，因為你說的三個模板塊，那么現(xiàn)在這個彈性數(shù)據(jù)庫有沒有可能做成一個像包一樣的形式或一個統(tǒng)一的安裝軟件之類的東西，有沒有這樣的計劃呢？

答：先回答第一個問題，三個模塊是不會合到一塊的，因為我們之所以把它分開就是為了實現(xiàn)解耦，我們現(xiàn)在正在啟動內(nèi)部的一些私有云的數(shù)據(jù)庫服務(wù)，就是說后續(xù)對于我們京東內(nèi)部的用戶來說，你只需要申請就行了，有點像你用阿里的RDS一樣，但我們不會對外提供服務(wù)，同時我們的JED和BinLake馬上就會開源了，你馬上就可以使用到了。

來自：http://database.51cto.com/art/201801/563260.htm