假如讓你來設計數據庫中間件

13年底負責數據庫中間件設計時的設計文檔，拿出來和大家分享：

• 可以了解下 數據庫中間件技術

• 可以了解下架構師 系統 設計 的思路

一、總體目標

數據庫中間層項目背景不再展開，根據前期的調研以及和公司同事的討論，中間層的核心目標主要有兩個：

• db虛擬化 ：讓db對業務線透明（本文的db均指mysql），業務線不再需要知道db的真實ip，port，主從關系，讀寫關系，高可用等

• 分庫的支持 ：讓db的分庫對業務線透明

二、實現的功能

上述目標相對比較寬泛，具體來說，數據庫中間層需要實現以下功能。

（1）統一接入入口

如果統一接入入口，從今以后， 不再有

db1.58.com:3306

db2.58.com:3306

im.58.com:3306

jiaoyou.58.com:3306

而 只有

db.58.com:3306

所有的業務線，對db的訪問，都只有一個入口 ，由數據庫中間層來進行權限驗證，由中間件來路由請求，這是一種完美的情況。

當然，統一一個總入口目標有點宏大，可以循序漸進， 先各業務線統一讀寫訪問入口 ，故折衷的目標可以是，從今以后，不再有

im.read.db1.58.com:3306

im.read.db2.58.com:3306

im.write.db.58.com:3306

而只有

im.58.com:3306

im業務對db的訪問，統一到一個入口上來了 ，由中間層來對請求進行智能路由。

更簡化的，甚至可以初期同一個業務線的db讀寫都不對業務線透明，數據庫中間層只做簡單的請求轉發，先初步的把數據庫訪問入口收攏到數據庫中間層來，為后續的統一，再統一打下基礎。

ROAD-MAP規劃如下：

• 業務線入口統一（中轉請求）

• 業務線入口統一（智能路由）

• 全局入口統一

（2）保持訪問接口

原來db的訪問方式主要有以上三種：

• 手工用 mysql客戶端 連mysql，直連數據庫執行命令

• java使用 jdbc 連接數據庫

• c/c++使用 libmysqlclient.a 來對mysql進行訪問

所謂保持訪問接口 ，是指上游對數據庫的訪問接口完全不用變， 中間件服務對上游來說，就是數據庫 。

由于SQL協議是非常復雜的，在db的客戶端與服務器插入了一個中間層之后，不一定能對所有的SQL功能都進行支持，支持哪些SQL是需要慎重考慮的。

（3）屏蔽讀寫分離

業務層不需要在關注讀寫分離 ，由中間件來進行讀寫請求路由。

（4） 支持的 分庫

58的db的水平擴展，基本是用的分庫的方式（分庫比較好，很容易實現實例的擴容），即：

db.table會水平拆分為：

db1.table

db2.table

db3.table

db4.table

這樣的話，dao層對于table就只有一個table實例了，比較方便。

根據前期與各業務線同學的溝通，58在分庫上的業務訪問需求為（這個調研的周期比較長，和很多業務線進行了溝通）：

• patition key普通查詢

• patition key上的IN查詢

• 非patition key上的查詢

• 有限功能的排序+分頁查詢

故對分庫上的分布式SQL功能，數據庫中間層只需要支持上上述四項即可。

（5）高可用性的支持

高可用的支持又分為兩個部分：

第一部分， 故障自動發現 ：下游數據庫掛了，能夠自動發現問題，并報警周知相關人員。

第二部分， 故障自動轉移 ：

• 主庫掛了，能夠自動切換，或者屏蔽寫請求

• 從庫掛了，能夠自動自動切換讀請求量流量

• 中間件掛了，自動切換中間件流量，高可用

（6）可運維性的支持

• 支持一些統計數據的展現

• 支持一些管理命令

• 支持頁面話的運維

however，只要總的框架設計具備可擴展性，這些功能可以循序漸進，逐步添加。

三、設計折衷

（1）協議與整體架構

既然選擇了mysql client server protocol作為業務層與中間層之間的協議，那么 中間層必然是作為mysql-server接收上游的請求 ， 作為mysql-client向真正的mysql發送請求 的，中間層的整體結構如下：

這樣的話， 需要對mysql client server protocol做詳盡的研究 ，了解：

• 連接的建立過程

• 權限認證的過程

• 壓縮解壓縮的過程

• 請求響應二進制協議各種細節

• …

協議這一塊的掌握必須詳盡，好在官方文檔相對比較全面：

http://dev.mysql.com/doc/internals/en/client-server-protocol.html

（2）架構細節

總體架構細節圖如上。

（2.1）上游

• mysql客戶端，java使用jdbc作為上游連接，c/c++使用libmysql.a作為上游連接，使用的是Mysql Client Server協議

• DBA亦可以向中間件發送一些管理命令，或者查看一些統計信息，使用的是自己定義的內部協議

（2.2）下游

處于系統體系結構中的最后端，系統中間件的下游就是mysql集群了，中間件與mysql之間使用的也是Mysql Client Server協議。

（2.3）中間層-ConfigMgr

中間層配置文件管理組件 ConfigMgr是中間層中非常重要的一個部分，請求的轉發，讀寫分離，分庫功能的支持，都需要通過配置來完成。

<mysql>

<db id=0 logic_db="im"type=1>

<item ip="10.58.1.100" port=3306 name="im" />

</db>

<db id=1 logic_db="umc"type=2 patition_count=2 key="uid" hash="mod" >

<patition id=0>

<item ip="10.58.1.100" port=3306 role="w" />

<item ip="10.58.1.101" port=3306 role="r" />

<item ip="10.58.1.102" port=3306 role="r" />

</patition>

<patition id=1>

<item ip="10.58.1.100" port=3316 role="w" />

<item ip="10.58.1.101" port=3316 role="r" />

<item ip="10.58.1.102" port=3316 role="r" />

</patition>

</db>

</mysql>

從配置文件可以看出，ConfigMgr需要管理的mysql配置類型有兩種：

type=1請求轉發

<db id=0 logic_db="im"type=1>

<item ip="10.58.1.100" port=3306 name="im" />

</db>

配置的含義是，上游如果訪問邏輯數據庫logic_db=”im”，中間件則將請求轉發到實際的后端數據庫item，item中配置了后端數據庫的ip/port/name。

type=2分庫支持

解釋分庫支持的配置之前，先說明一下數據庫的層次結構LOGIC_DB、PARTITION、ITEM。

LOGIC_DB ：邏輯數據庫，面向上游，例如umc

PARTITION ：數據庫分區，可以理解為分庫，例如umc0和umc1，這個對上游是透明的

ITEM ：數據庫項，可以理解為一個分區上的一個讀庫或者寫庫，這個對上游也是透明的

上例中對應的配置文件為：

<db id=1 logic_db="umc"type=2 patition_count=2 key="uid" hash="mod" >

<patition id=0>

<item ip="10.58.1.100" port=3306 role="w" />

<item ip="10.58.1.101" port=3306 role="r" />

<item ip="10.58.1.102" port=3306 role="r" />

</patition>

<patition id=1>

<item ip="10.58.1.100" port=3316 role="w" />

<item ip="10.58.1.101" port=3316 role="r" />

<item ip="10.58.1.102" port=3316 role="r" />

</patition>

</db>

• LOGIC_DB ：需要關注partition-key-column，也需要關注partition算法，它要實現對PARTITION的請求路由以及結果集的匯總

• PARTITION ：需要關注ITEM的讀寫特性，它要實現對ITEM的讀寫分離

• ITEM ：是最終的數據庫，和它相關的配置是數據庫ip/port/name/wr-type

（2.4）中間層-MysqlServerPart

中間層服務端組件 MysqlServerPart是中間層中非常重要的一個部分，它負責端口的監聽+請求接收與返回（服務端網絡IO），MysqlProtocol的解析。根據其功能，MysqlServerPart組件又主要分為兩個組件ServerIOMgr組件（服務端IO管理），MysqlProtocolAnalyzer組件（Mysql協議分析）。

這一層次面臨這些細節：

• server 網絡框架 的選取：建議使用異步server

• 并發模型 的選取：建議使用IO-thread + multi-work-thread的并發模型

• 內存管理 模型的選取：建議使用內存池

• 連接 上下文管理 ，最容易想到的上下文，一個數據庫連接是和一個邏輯庫LOGIC_DB綁定的

• Mysql如何建立 數據庫連接 ：需要考察Mysql協議

• Mysql 協議的細化解析 ：需要考察Mysql協議

• …

（2.5）中間層-MysqlClientPart

中間層客戶端組件 MysqlClientPart是中間層中非常重要的一個部分，它負責中間件對mysql的連接池管理，以及返回結果集的解析。根據其功能，MysqlClientPart組件又主要分為兩個組件ClientConnPoolMgr組件（客戶端連接池管理），ResultSetAnalyzer組件（返回結果集分析）。

這一層次面臨這些細節：

• 數據庫 連接池 的實現

• 數據庫 連接模型 的選型：建議前期使用同步模型

• 連接 上下文管理 ，最容易想到的上下文，一個數據庫連接是和一個ITEM綁定的

• Mysql 結果集的細化解析 ：需要考察Mysql協議

• …

（2.6）中間層-SqlParser

中間層Sql分析組件 SqlParser是中間層中非常重要的一個部分，它負責對sql語句的語法分析與語義分析。

為什么要進行Sql語法語義分析？需要解析出什么東東？

分為兩種情況：

type=1請求轉發

對于請求的中轉，上游一個數據庫連接對應一個邏輯庫LOGIC_DB，由ConfigMgr可以知道對應下游一個真實的ITEM（ip/port/db），此時直接轉發請求即可，無需解析Sql語句。

type=2分庫支持

對于分庫的支持，解析Sql語句可能需要得到這些問題的答案：Sql是否帶了partition-key-column？partition-key-column的值是多少？

例如一條Sql語句： select * from user where uid=123456;

就必須將“uid”列屬性，以及uid的列屬性值“123456”解析出來，以用作后續請求路由。

注意：更細的情況是，針對每個表，分庫partition-key-column都是不一樣的，上例中還需要將表名user也解析出來。

這一層次面臨這些細節：

• 如何解析Sql語句：可以參考mysql源碼對SQL語句的解析，亦可參照cober對SQL語句的解析方法；

注：由于我們只需要支持多庫，數據庫庫名信息是在“連接”這一層獲取的，又我們支持的分布式Sql的種類有限，故只需解析partition-key-column，offset/limit等少數信息即可。

（2.7）中間層-SqlModifier

中間層Sql修改組件 SqlModifier是中間層中非常重要的一個部分，它負責對sql語句改寫。

為什么要對Sql語句進行改寫？

type=1的請求轉發，無需修改Sql，但對于type=2的分庫支持，有些Sql語句就必須進行改寫。

例如： select * from user where uid in(1,2,3,4,5,6);

假設PARTITION分了0和1奇偶兩個分區，則sql應該分別被改寫為：

select * from user where uid in(2,4,6); => 路由給0庫；

select * from user where uid in(1,3,5); => 路由給1庫；

又例如： select * from user limit 1000,10;

則sql可能會被改寫為：

select * from user limit 0,1010; => 分別路由到兩個庫，收集完結果集共2020條記錄，再排序取其中1000-1010這10條。

哪些Sql需要改寫，如何改寫？

結合我們需要實現的四類分布式Sql：

• patition key普通查詢

• patition key上的IN查詢

• 非patition key上的查詢

• 有限功能的排序+分頁查詢

只有（2）和（4）兩項需要改寫，改寫方法上文已述，其中（4）的改寫效率較低，使用起來要謹慎。

（2.8）中間層-SqlRouter

中間層Sql路由組件 SqlRouter是中間層中非常重要的一個部分，它負責對sql語句進行路由。

哪些Sql需要路由，如何路由？

結合我們需要實現的四類分布式Sql：

• patition key普通查詢

• patition key上的IN查詢

• 非patition key上的查詢

• 有限功能的排序+分頁查詢

只有（1）和（2）兩項需要路由，（3）和（4）需要將請求分發至所有的PARTITION。

（2.9）中間層-ResultSetMerger

中間層結果集合并組件 ResultSetMerger是中間層中非常重要的一個部分，它負責對結果集進行合并，篩選。

哪些Sql需要合并結果集，篩選結果集？

結合我們需要實現的四類分布式Sql：

• patition key普通查詢

• patition key上的IN查詢

• 非patition key上的查詢

• 有限功能的排序+分頁查詢

其中（2）和（3）類查詢需要將結果集進行合并，（4）不但要合并結果集，還需要將結果集在本地進行排序，然后再篩選出真正的結果集。

（2.10）其他組件

• AdminServer ：監聽一個新端口，接收數據庫管理員命令的server

• AdminMgr ：實現管理員命令的組件

• MonitorMgr ：實現監控報警的組件

• StatisticsMgr ：實現數據統計功能的組件

上述組件可循序漸進，逐步添加，故一期需要實現的組件及架構圖為：

感謝看完，說明你對數據庫中間件感興趣，建議在PC上細看3遍，一定更有收獲。

 

來自：http://mp.weixin.qq.com/s/6kuVgdO7RBs9gs229wG3wA