你好，我是EverDB！

初次見面，先自我介紹一下，我的正式名稱是“安沃分布式數據庫系統”，不過，朋友們更喜歡稱呼我“EverDB”。我是G行分布式家族中的一員，承擔著分布式架構下實現數據庫高可用、可擴展的重任。

我的誕生

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

技術架構

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

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

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

兩種架構各有優勢，在G行都有廣泛的應用空間。從架構上說，我屬于第一種技術方案。但是，我不重復別人，也不想重復自己！

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

EDB-Grid：是我最核心的組件，具有全局調度能力，負責全局事務管理、分布式執行計劃的生成與調度、集群擴縮容、數據節點的故障自動切換等。

數據節點：是我的數據存儲層，基于MySQL社區版本，支持MySQL主從架構和MGR架構，主要負責數據的存儲、本地事務管理、本地結果集計算等。

配置節點：基于Zookeeper實現，負責我在運行態的元數據存儲、同步、與配置管理。

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

EDB-Bridge：數據同步工具，負責將我的數據增量同步給其他異構數據庫。

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

沒錯，我是通過多組件共同協作來實現整個分布式數據庫調度、存儲、計算、管理、數據遷移等能力！

技術特性

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

1.數據分片

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

全局表像是“數據字典”，就是系統中所有的表都可能依賴的表，特點是數據量較小、變更頻率低、且可能跟其他表產生關聯查詢的表；

普通表是數據量相對不大、變更頻率不高、且不會和分片表產生關聯查詢的表；

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

全局表會在集群內進行廣播，使聯表查詢盡量在單個節點完成，通過避免跨節點join來提升SQL執行效率和數據庫性能。

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

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

2.SQL執行優化

那么，你可能會問：“當接收到應用發來的一條SQL語句后，EverDB要怎樣處理呢？”OK，接下來我簡單介紹一下SQL語句的處理流程和遵循的優化原則。

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

舉個例子，如下圖所示，這是個排序分頁SQL，通過優化原則將SQL進行必要的改寫，然后將改寫后的SQL并行下發到相關的數據節點執行，最后將數據節點返回的結果集歸并再limit，得到最終結果集返回給應用。

3.通信協議

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

4.分布式事務

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

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

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

5.數據庫安全

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

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

6.全組件高可用

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

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

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

在EverDB領域內，有幾個重要概念應該了解一下，這樣我們才有共同語言，是不是？

DataServer

DataServer與數據節點上的MySQLServer一一對應，無論是主庫（Master）還是從庫（Slave），都是一個EverDB的DataServer，在EverDB的Grid層中記錄了這些Server的地址、端口。DataServer是Grid調度、切換的物理對象。

DataSource

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

PartitionScheme

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

DataSpace

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

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

我的理想

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

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

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

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