日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
假如讓你來設(shè)計數(shù)據(jù)庫中間件

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

  • 可以了解下數(shù)據(jù)庫中間件技術(shù)
  • 可以了解下架構(gòu)師系統(tǒng)設(shè)計的思路

一、總體目標

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

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

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

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

（1）統(tǒng)一接入入口

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

 
 
 
 
    
  
  
  
  
  1. db1.58.com:3306 
    2.   
  
  
  
  2.  
    3.   
  
  
  
  3. db2.58.com:3306 
    4.   
  
  
  
  4.  
    5.   
  
  
  
  5. im.58.com:3306 
    6.   
  
  
  
  6.  
    7.   
  
  
  
  7. jiaoyou.58.com:3306 
    8.

而只有

 
 
 
 
    
  
  
  
  
  1. db.58.com:3306 
    2.

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

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

 
 
 
 
    
  
  
  
  
  1. im.read.db1.58.com:3306 
    2.   
  
  
  
  2.  
    3.   
  
  
  
  3. im.read.db2.58.com:3306 
    4.   
  
  
  
  4.  
    5.   
  
  
  
  5. im.write.db.58.com:3306 
    6.

而只有

 
 
 
 
    
  
  
  
  
  1. im.58.com:3306 
    2.

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

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

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

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

（2）保持訪問接口

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

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

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

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

（3）屏蔽讀寫分離

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

（4）支持的分庫

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

db.table會水平拆分為：

db1.table

db2.table

db3.table

db4.table

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

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

  • 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è)務(wù)層與中間層之間的協(xié)議，那么中間層必然是作為mysql-server接收上游的請求，作為mysql-client向真正的mysql發(fā)送請求的，中間層的整體結(jié)構(gòu)如下：

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

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

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

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

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

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

（2.1）上游

  • mysql客戶端，java使用jdbc作為上游連接，c/c++使用libmysql.a作為上游連接，使用的是Mysql Client Server協(xié)議
  • DBA亦可以向中間件發(fā)送一些管理命令，或者查看一些統(tǒng)計信息，使用的是自己定義的內(nèi)部協(xié)議

（2.2）下游

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

（2.3）中間層-ConfigMgr

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

 
 
 
 
    
  
  
  
  
  1.  
    2.   
  
  
  
  2.  
    3.   
  
  
  
  3.  
    4.   
  
  
  
  4.  
    5.   
  
  
  
  5.         
    6.   
  
  
  
  6.  
    7.   
  
  
  
  7.  
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9.   
    10.   
  
  
  
  10.  
    11.   
  
  
  
  11.  
    12.   
  
  
  
  12.  
    13.   
  
  
  
  13.     
    14.   
  
  
  
  14.  
    15.   
  
  
  
  15.         
    16.   
  
  
  
  16.  
    17.   
  
  
  
  17.         
    18.   
  
  
  
  18.  
    19.   
  
  
  
  19.         
    20.   
  
  
  
  20.  
    21.   
  
  
  
  21.     
    22.   
  
  
  
  22.  
    23.   
  
  
  
  23.     
    24.   
  
  
  
  24.  
    25.   
  
  
  
  25.         
    26.   
  
  
  
  26.  
    27.   
  
  
  
  27.         
    28.   
  
  
  
  28.  
    29.   
  
  
  
  29.         
    30.   
  
  
  
  30.  
    31.   
  
  
  
  31.     
    32.   
  
  
  
  32.  
    33.   
  
  
  
  33.  
    34.   
  
  
  
  34.  
    35.   
  
  
  
  35.  
    36.

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

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

 
 
 
 
    
  
  
  
  
  1.  
    2.   
  
  
  
  2.  
    3.   
  
  
  
  3.         
    4.   
  
  
  
  4.  
    5.   
  
  
  
  5.  
    6.

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

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ū)上的一個讀庫或者寫庫，這個對上游也是透明的

上例中對應(yīng)的配置文件為：

 
 
 
 
    
  
  
  
  
  1.  
    2.   
  
  
  
  2.  
    3.   
  
  
  
  3.     
    4.   
  
  
  
  4.  
    5.   
  
  
  
  5.         
    6.   
  
  
  
  6.  
    7.   
  
  
  
  7.         
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9.         
    10.   
  
  
  
  10.  
    11.   
  
  
  
  11.     
    12.   
  
  
  
  12.  
    13.   
  
  
  
  13.     
    14.   
  
  
  
  14.  
    15.   
  
  
  
  15.         
    16.   
  
  
  
  16.  
    17.   
  
  
  
  17.         
    18.   
  
  
  
  18.  
    19.   
  
  
  
  19.         
    20.   
  
  
  
  20.  
    21.   
  
  
  
  21.     
    22.   
  
  
  
  22.  
    23.   
  
  
  
  23.   
    24.
  •     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 

（2.4）中間層-MysqlServerPart

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

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

  • server網(wǎng)絡(luò)框架的選?。航ㄗ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é)議 
  •  … 

（2.5）中間層-MysqlClientPart

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

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

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

（2.6）中間層-SqlParser

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

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

分為兩種情況：

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

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

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ù)信息即可。

（2.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應(yīng)該分別被改寫為：

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）的改寫效率較低，使用起來要謹慎。

（2.8）中間層-SqlRouter

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

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

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

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

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

（2.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é)果集。

（2.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)圖為：

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


當前文章：假如讓你來設(shè)計數(shù)據(jù)庫中間件
文章轉(zhuǎn)載：http://www.dlmjj.cn/article/cccdoec.html