一、總體目標

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

• db虛擬化：讓db對業(yè)務線透明(本文的db均指mysql)，業(yè)務線不再需要知道db的真實ip，port，主從關(guān)系，讀寫關(guān)系，高可用等
• 分庫的支持：讓db的分庫對業(yè)務線透明

二、實現(xiàn)的功能

上述目標相對比較寬泛，具體來說，數(shù)據(jù)庫中間層需要實現(xiàn)以下功能。

1. 統(tǒng)一接入入口

如果統(tǒng)一接入入口，從今以后，不再有

db1.58.com:3306 
db2.58.com:3306 
im.58.com:3306 
jiaoyou.58.com:3306 

而只有

db.58.com:3306 

所有的業(yè)務線，對db的訪問，都只有一個入口，由數(shù)據(jù)庫中間層來進行權(quán)限驗證，由中間件來路由請求，這是一種***的情況。

當然，統(tǒng)一一個總?cè)肟谀繕擞悬c宏大，可以循序漸進，先各業(yè)務線統(tǒng)一讀寫訪問入口，故折衷的目標可以是，從今以后，不再有

im.read.db1.58.com:3306 
im.read.db2.58.com:3306 
im.write.db.58.com:3306 

而只有

im.58.com:3306 

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

更簡化的，甚至可以初期同一個業(yè)務線的db讀寫都不對業(yè)務線透明，數(shù)據(jù)庫中間層只做簡單的請求轉(zhuǎn)發(fā)，先初步的把數(shù)據(jù)庫訪問入口收攏到數(shù)據(jù)庫中間層來，為后續(xù)的統(tǒng)一，再統(tǒng)一打下基礎(chǔ)。

ROAD-MAP規(guī)劃如下：

• 業(yè)務線入口統(tǒng)一(中轉(zhuǎn)請求)
• 業(yè)務線入口統(tǒng)一(智能路由)
• 全局入口統(tǒng)一

2.  保持訪問接口

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

• 手工用mysql客戶端連mysql，直連數(shù)據(jù)庫執(zhí)行命令
• java使用jdbc連接數(shù)據(jù)庫
• c/c++使用libmysqlclient.a來對mysql進行訪問

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

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

3.  屏蔽讀寫分離

業(yè)務層不需要在關(guān)注讀寫分離，由中間件來進行讀寫請求路由。

4.  支持的分庫

58的db的水平擴展，基本是用的分庫的方式(分庫比較好，很容易實現(xiàn)實例的擴容)，即：

db.table會水平拆分為：

db1.table 
db2.table 
db3.table 
db4.table 

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

根據(jù)前期與各業(yè)務線同學的溝通，58在分庫上的業(yè)務訪問需求為(這個調(diào)研的周期比較長，和很多業(yè)務線進行了溝通)：

• patition key普通查詢
• patition key上的IN查詢
• 非patition key上的查詢
• 有限功能的排序+分頁查詢

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

5.  高可用性的支持

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

***部分，故障自動發(fā)現(xiàn)：下游數(shù)據(jù)庫掛了，能夠自動發(fā)現(xiàn)問題，并報警周知相關(guān)人員。

第二部分，故障自動轉(zhuǎn)移：

• 主庫掛了，能夠自動切換，或者屏蔽寫請求
• 從庫掛了，能夠自動自動切換讀請求量流量
• 中間件掛了，自動切換中間件流量，高可用

(6 )可運維性的支持

• 支持一些統(tǒng)計數(shù)據(jù)的展現(xiàn)
• 支持一些管理命令
• 支持頁面話的運維

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

三、設(shè)計折衷

1. 協(xié)議與整體架構(gòu)

既然選擇了mysql client server protocol作為業(yè)務層與中間層之間的協(xié)議，那么中間層必然是作為mysql-server接收上游的請求，作為mysql-client向真正的mysql發(fā)送請求的，中間層的整體結(jié)構(gòu)如下：

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

• 連接的建立過程
• 權(quán)限認證的過程
• 壓縮解壓縮的過程
• 請求響應二進制協(xié)議各種細節(jié)
• …

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

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

2. 架構(gòu)細節(jié)

總體架構(gòu)細節(jié)圖如上。

(1) 上游

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

DBA也可以向中間件發(fā)送一些管理命令，或者查看一些統(tǒng)計信息，使用的是自己定義的內(nèi)部協(xié)議

(2) 下游

處于系統(tǒng)體系結(jié)構(gòu)中的***端，系統(tǒng)中間件的下游就是mysql集群了，中間件與mysql之間使用的也是Mysql Client Server協(xié)議。

(3) 中間層-ConfigMgr

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

<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配置類型有兩種：

a. type=1請求轉(zhuǎn)發(fā)

<db id=0 logic_db="im"type=1> 
       <item ip="10.58.1.100" port=3306 name="im" /> 
</db> 

 

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

b. type=2分庫支持

解釋分庫支持的配置之前，先說明一下數(shù)據(jù)庫的層次結(jié)構(gòu)LOGIC_DB、PARTITION、ITEM。

• LOGIC_DB：邏輯數(shù)據(jù)庫，面向上游，例如umc
• PARTITION：數(shù)據(jù)庫分區(qū)，可以理解為分庫，例如umc0和umc1，這個對上游是透明的
• ITEM：數(shù)據(jù)庫項，可以理解為一個分區(qū)上的一個讀庫或者寫庫，這個對上游也是透明的

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

<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：需要關(guān)注partition-key-column，也需要關(guān)注partition算法，它要實現(xiàn)對PARTITION的請求路由以及結(jié)果集的匯總
• PARTITION：需要關(guān)注ITEM的讀寫特性，它要實現(xiàn)對ITEM的讀寫分離
• ITEM：是最終的數(shù)據(jù)庫，和它相關(guān)的配置是數(shù)據(jù)庫ip/port/name/wr-type

(4) 中間層-MysqlServerPart

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

這一層次面臨這些細節(jié)：

• server網(wǎng)絡框架的選?。航ㄗh使用異步server
• 并發(fā)模型的選?。航ㄗh使用IO-thread + multi-work-thread的并發(fā)模型
• 內(nèi)存管理模型的選?。航ㄗh使用內(nèi)存池
• 連接上下文管理，最容易想到的上下文，一個數(shù)據(jù)庫連接是和一個邏輯庫LOGIC_DB綁定的
• Mysql如何建立數(shù)據(jù)庫連接：需要考察Mysql協(xié)議
• Mysql協(xié)議的細化解析：需要考察Mysql協(xié)議
• …

(5) 中間層-MysqlClientPart

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

這一層次面臨這些細節(jié)：

• 數(shù)據(jù)庫連接池的實現(xiàn)
• 數(shù)據(jù)庫連接模型的選型：建議前期使用同步模型
• 連接上下文管理，最容易想到的上下文，一個數(shù)據(jù)庫連接是和一個ITEM綁定的
• Mysql結(jié)果集的細化解析：需要考察Mysql協(xié)議
• …

(6) 中間層-SqlParser

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

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

分為兩種情況：

a. type=1請求轉(zhuǎn)發(fā)

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

b. type=2分庫支持

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

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

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

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

這一層次面臨這些細節(jié)：如何解析Sql語句：可以參考mysql源碼對SQL語句的解析，亦可參照cober對SQL語句的解析方法;

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

(7) 中間層-SqlModifier

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

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

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

例如：

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

假設(shè)PARTITION分了0和1奇偶兩個分區(qū)，則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; => 分別路由到兩個庫，收集完結(jié)果集共2020條記錄，再排序取其中1000-1010這10條。

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

結(jié)合我們需要實現(xiàn)的四類分布式Sql：

• patition key普通查詢
• patition key上的IN查詢
• 非patition key上的查詢
• 有限功能的排序+分頁查詢

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

(8) 中間層-SqlRouter

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

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

結(jié)合我們需要實現(xiàn)的四類分布式Sql：

• patition key普通查詢
• patition key上的IN查詢
• 非patition key上的查詢
• 有限功能的排序+分頁查詢

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

(9) 中間層-ResultSetMerger

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

哪些Sql需要合并結(jié)果集，篩選結(jié)果集?

結(jié)合我們需要實現(xiàn)的四類分布式Sql：

• patition key普通查詢
• patition key上的IN查詢
• 非patition key上的查詢
• 有限功能的排序+分頁查詢

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

(10) 其他組件

• AdminServer：監(jiān)聽一個新端口，接收數(shù)據(jù)庫管理員命令的server
• AdminMgr：實現(xiàn)管理員命令的組件
• MonitorMgr：實現(xiàn)監(jiān)控報警的組件
• StatisticsMgr：實現(xiàn)數(shù)據(jù)統(tǒng)計功能的組件

上述組件可循序漸進，逐步添加，故一期需要實現(xiàn)的組件及架構(gòu)圖為：

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文