你好，我是EverDB！

初次見面，先自我介紹一下，我的正式名稱是“安沃分布式數(shù)據(jù)庫系統(tǒng)”，不過，朋友們更喜歡稱呼我“EverDB”。我是G行分布式家族中的一員，承擔(dān)著分布式架構(gòu)下實現(xiàn)數(shù)據(jù)庫高可用、可擴展的重任。

我的誕生

我的誕生正逢其時。在這個金融科技創(chuàng)新的時代，對數(shù)據(jù)庫大并發(fā)、高頻次的訪問和可擴展性需求與日俱增，集中式數(shù)據(jù)庫架構(gòu)的限制和制約逐漸顯現(xiàn)。為滿足業(yè)務(wù)發(fā)展需求，G行科技人根據(jù)金融業(yè)務(wù)特點和分布式數(shù)據(jù)庫產(chǎn)品特性采取了雙軌并行的策略，在引入了分布式數(shù)據(jù)庫產(chǎn)品的同時，和合作伙伴一起,共同打造自主知識產(chǎn)權(quán)的分布式數(shù)據(jù)庫方案，于是我誕生了。

技術(shù)架構(gòu)

當前，主流的分布式數(shù)據(jù)庫技術(shù)方案有兩種：

一種以中間層為核心，基于開源數(shù)據(jù)庫自動化分庫分表的架構(gòu)。開源數(shù)據(jù)庫比如MySQL,PostgreSQL,都經(jīng)過了長時間的生產(chǎn)上的磨礪，產(chǎn)品功能相對穩(wěn)定。而中間層則是需要自主打磨的部分，實現(xiàn)分庫分表對應(yīng)用透明化。國內(nèi)在這個領(lǐng)域也有比較著名的產(chǎn)品，比如阿里的Cobar、TDDL，后來社區(qū)基于Cobar改進的MyCAT，360開源的Atlas，還有我的兄弟—萬里開源的GreatDB。

另一種是關(guān)系模型和NoSQL設(shè)計相融合的NewSQL技術(shù)方案，采用sql above nosql的設(shè)計思想，保留了關(guān)系型數(shù)據(jù)庫的SQL特性、事務(wù)特性，同時借鑒了NoSQL數(shù)據(jù)庫強擴展性的設(shè)計理念，但這種技術(shù)方案發(fā)展時間相對較短，處在不斷演進過程中。國內(nèi)也有相應(yīng)的數(shù)據(jù)庫產(chǎn)品，比如PingCAP開源的TiDB，螞蟻金服的商業(yè)數(shù)據(jù)庫OceanBase。

兩種架構(gòu)各有優(yōu)勢，在G行都有廣泛的應(yīng)用空間。從架構(gòu)上說，我屬于第一種技術(shù)方案。但是，我不重復(fù)別人，也不想重復(fù)自己！

上面是我的完整技術(shù)架構(gòu)，由多個技術(shù)組件構(gòu)成的分布式陣容，可謂進可攻退可守。

EDB-Grid：是我最核心的組件，具有全局調(diào)度能力，負責(zé)全局事務(wù)管理、分布式執(zhí)行計劃的生成與調(diào)度、集群擴縮容、數(shù)據(jù)節(jié)點的故障自動切換等。

數(shù)據(jù)節(jié)點：是我的數(shù)據(jù)存儲層，基于MySQL社區(qū)版本，支持MySQL主從架構(gòu)和MGR架構(gòu)，主要負責(zé)數(shù)據(jù)的存儲、本地事務(wù)管理、本地結(jié)果集計算等。

配置節(jié)點：基于Zookeeper實現(xiàn)，負責(zé)我在運行態(tài)的元數(shù)據(jù)存儲、同步、與配置管理。

EDB-Control：是儀表盤，也是運維管理控制臺，負責(zé)我的全生命周期管理。

EDB-Bridge：數(shù)據(jù)同步工具，負責(zé)將我的數(shù)據(jù)增量同步給其他異構(gòu)數(shù)據(jù)庫。

逃離庫：基于傳統(tǒng)集中式數(shù)據(jù)庫（目前是MySQL）的異構(gòu)熱備，通過EDB-Bridge組件從我這里實時同步增量數(shù)據(jù)，用于增強新技術(shù)引入過程中的風(fēng)險抵御能力。當我在運行時不幸遭遇“黑天鵝事件”時，可通過逃離庫提供核心業(yè)務(wù)能力，這是運行的安全帶。

沒錯，我是通過多組件共同協(xié)作來實現(xiàn)整個分布式數(shù)據(jù)庫調(diào)度、存儲、計算、管理、數(shù)據(jù)遷移等能力！

技術(shù)特性

為了滿足業(yè)務(wù)需求和集群的安全可靠性要求，我練就了一身武藝，是時候展示一下了。

1.數(shù)據(jù)分片

Sharding（分片）是我練就的核心武功，這里的Sharding主要指表的橫向拆分。根據(jù)業(yè)務(wù)表的特點不同，可分為全局表、普通表、分片表。

全局表像是“數(shù)據(jù)字典”，就是系統(tǒng)中所有的表都可能依賴的表，特點是數(shù)據(jù)量較小、變更頻率低、且可能跟其他表產(chǎn)生關(guān)聯(lián)查詢的表；

普通表是數(shù)據(jù)量相對不大、變更頻率不高、且不會和分片表產(chǎn)生關(guān)聯(lián)查詢的表；

分片表是數(shù)據(jù)量較大或交易訪問頻率較高的表，需要通過數(shù)據(jù)Sharding來分散數(shù)據(jù)部署或交易訪問量的表。

全局表會在集群內(nèi)進行廣播，使聯(lián)表查詢盡量在單個節(jié)點完成，通過避免跨節(jié)點join來提升SQL執(zhí)行效率和數(shù)據(jù)庫性能。

分片表主要支持hash、mod、list、range四種分片算法，為有效的打散數(shù)據(jù)分布，hash和mod是較為常用的分片算法，當然你也可以自定義分片算法。EDB-Grid通過對分片鍵應(yīng)用分片算法，將數(shù)據(jù)分散部署到集群中不同的節(jié)點上，而對于應(yīng)用來說這種分布式部署是透明的，就像使用單機數(shù)據(jù)庫一樣。

在分布式數(shù)據(jù)庫應(yīng)用中，分片鍵的選擇至關(guān)重要。那么怎么選擇分片鍵呢？當然是應(yīng)該選擇離散型較好的字段作為分片鍵，且不同的分片表盡量選擇相同的分片鍵，是不是有些熟悉的味道？同樣的優(yōu)化原則，通過避免分片表跨節(jié)點join來提升SQL執(zhí)行效率和數(shù)據(jù)庫性能。

2.SQL執(zhí)行優(yōu)化

那么，你可能會問：“當接收到應(yīng)用發(fā)來的一條SQL語句后，EverDB要怎樣處理呢？”O(jiān)K，接下來我簡單介紹一下SQL語句的處理流程和遵循的優(yōu)化原則。

當接收到應(yīng)用的SQL后，我會先進行SQL語法解析，然后生成分布式執(zhí)行計劃，在這個過程中我會遵循一些優(yōu)化原則，比如查詢計算下推、跨節(jié)點并行計算、通過必要的SQL改寫提升執(zhí)行效率等，最后根據(jù)執(zhí)行計劃對并行計算的結(jié)果進行歸并，并將歸并結(jié)果返回給應(yīng)用端。

舉個例子，如下圖所示，這是個排序分頁SQL，通過優(yōu)化原則將SQL進行必要的改寫，然后將改寫后的SQL并行下發(fā)到相關(guān)的數(shù)據(jù)節(jié)點執(zhí)行，最后將數(shù)據(jù)節(jié)點返回的結(jié)果集歸并再limit，得到最終結(jié)果集返回給應(yīng)用。

3.通信協(xié)議

用什么客戶端與我通信?忘記告訴你了，我能夠完美兼容MySQL通信協(xié)議，并能兼容絕大部分常用的MySQL語法和功能，所以你只需要使用MySQL客戶端，像使用單機MySQL一樣和我對話就OK啦！

4.分布式事務(wù)

如你所知，事務(wù)是關(guān)系型數(shù)據(jù)庫一個非常重要的特性，也是金融大部分業(yè)務(wù)場景必要的功能需求，支持事務(wù)需要實現(xiàn)事務(wù)的ACID四個特性，即原子性、一致性、隔離性、持久性。

在分布式數(shù)據(jù)庫中，當一個事務(wù)中的SQL出現(xiàn)跨節(jié)點操作，又需要保證ACID特性時，就被稱為分布式事務(wù)。由于涉及多節(jié)點操作，分布式事務(wù)的實現(xiàn)難度遠大于單機事務(wù)。當然我是支持分布式事務(wù)的，簡單來說是基于XA事務(wù)協(xié)議，采用兩階段提交（2PC）的方法實現(xiàn)的，具體實現(xiàn)細節(jié)這里就不詳細闡述了。

分布式事務(wù)可以最大程度的保證數(shù)據(jù)庫操作的原子性，但由于事務(wù)提交時需要協(xié)調(diào)多個數(shù)據(jù)節(jié)點，這里會存在一個“木桶效應(yīng)”，事務(wù)執(zhí)行的時間會取決于執(zhí)行效率最低的數(shù)據(jù)節(jié)點，當事務(wù)執(zhí)行時間較長時，會增加事務(wù)間鎖沖突或者死鎖的概率。因此對于事務(wù)的使用，建議遵循“能不用事務(wù)就不用事務(wù)，能用小事務(wù)的不用大事務(wù)”原則。

5.數(shù)據(jù)庫安全

亦如你所知，數(shù)據(jù)是銀行業(yè)務(wù)經(jīng)營的核心資產(chǎn)，也是企業(yè)的核心競爭力。敏感數(shù)據(jù)信息泄露會直接影響客戶的利益，損害銀行的信譽，降低銀行的行業(yè)競爭力。因此企業(yè)級數(shù)據(jù)安全建設(shè)是重要且必要的。

而我在數(shù)據(jù)庫安全方面也是有一定修煉的，主要體現(xiàn)在訪問安全、安全審計、數(shù)據(jù)安全三個方面：通過支持賬戶密碼訪問，設(shè)置黑白名單，數(shù)據(jù)庫表授權(quán)，訪問時段、流控、危險操作防御，登陸失敗防護增強，通信ssl加密來實現(xiàn)訪問的安全性；可以針對操作類型、操作對象、操作用戶來進行安全審計；通過支持數(shù)據(jù)加密，數(shù)據(jù)多副本多機房部署來增強數(shù)據(jù)安全性。

6.全組件高可用

對于高可用性問題，如果設(shè)計不好，那么DBA可能就要受累了，想必會傷痕累累吧，當然對客戶體驗和銀行的聲譽也是有損的。所以我也充分考慮了這一點，通過雙機房部署、全組件冗余設(shè)計，故障自動感知、自動切換來實現(xiàn)整個集群的高可用性。

配置組件的高可用采用了Zookeeper原生高可用方案；EDB-Grid調(diào)度組件基本屬于無狀態(tài)組件，通過F5或LVS等實現(xiàn)負載均衡、故障感知、和故障轉(zhuǎn)移；數(shù)據(jù)節(jié)點通過MySQL增強半同步復(fù)制技術(shù)實現(xiàn)數(shù)據(jù)多副本，使用類raft協(xié)議實現(xiàn)主節(jié)點的故障檢測、leader選舉、和自動故障切換；而EDB-Control組件則通過keepalived保證其高可用性。

那么除此之外，我還支持讀寫分離，正在修煉數(shù)據(jù)的動態(tài)擴展，同時在安全可控方面，我和國產(chǎn)ARM平臺的適配也在緊鑼密鼓的進行中。

在EverDB領(lǐng)域內(nèi)，有幾個重要概念應(yīng)該了解一下，這樣我們才有共同語言，是不是？

DataServer

DataServer與數(shù)據(jù)節(jié)點上的MySQLServer一一對應(yīng)，無論是主庫（Master）還是從庫（Slave），都是一個EverDB的DataServer，在EverDB的Grid層中記錄了這些Server的地址、端口。DataServer是Grid調(diào)度、切換的物理對象。

DataSource

DataSource是EverDB中的一個邏輯概念，將一個MySQL主從復(fù)制（或MGR）集群在Grid層對應(yīng)為一個DataSource，對應(yīng)用來說，隱藏了數(shù)據(jù)節(jié)點的復(fù)雜的高可用配置。

PartitionScheme

PartitionScheme是EverDB實現(xiàn)分布式橫向擴展、負載均衡的核心。它定義了分片策略，由多個DataSource組成。EDB-Grid通過分片策略在分片鍵上的應(yīng)用，自動將分片表的數(shù)據(jù)分散部署到不同的DataSource。這樣，分片配置對應(yīng)用變得簡單、透明。

DataSpace

DataSpace定義EverDB中表與數(shù)據(jù)庫（Schema）、DataSource、PartitionScheme之間的映射規(guī)則，表示數(shù)據(jù)對象和數(shù)據(jù)存儲位置的對應(yīng)關(guān)系。不分片的表，可以通過名稱與一個DataSource匹配映射；而分片表，則通過名稱與PartitionScheme匹配映射。

總結(jié)一下一張表在EverDB中的奇妙旅程：首先，表通過DataSpace中定義的名稱匹配規(guī)則，映射到一個PartitionScheme或者一個DataSource。如果映射到了PartitionScheme,那么就根據(jù)PartitionScheme定義的分片規(guī)則，打散到不同的DataSource。然后，根據(jù)DataSource的定義，表存儲到特定的MySQL高可用集群。通過上面4個層次的組合關(guān)系，從邏輯概念一層層落到了物理節(jié)點上，怎么樣，是不是有點意思？

我的理想

志當存高遠，理想還是要有的，萬一實現(xiàn)了呢？

我還很年輕，需要修煉的能力還有很多，包括功能的豐富性、性能提升、安全加固、服務(wù)穩(wěn)定性等方面。所以我的理想是能夠成為一個簡單、健壯、靈活部署、智能化運維的分布式數(shù)據(jù)庫。

如果問我征途在哪里？我期待著在云端飛揚奔騰！

圖文作者：李超、李蕭蕭、王莉莉、陳碩、鄭皓廣（左起）?