日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

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

新聞中心

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

13年底負(fù)責(zé)數(shù)據(jù)庫(kù)中間件設(shè)計(jì)時(shí)的設(shè)計(jì)文檔,拿出來(lái)和大家分享:

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

一、總體目標(biāo)

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

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

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

上述目標(biāo)相對(duì)比較寬泛,具體來(lái)說(shuō),數(shù)據(jù)庫(kù)中間層需要實(shí)現(xiàn)以下功能。

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

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

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

而只有

 
 
 
 
  1. db.58.com:3306 

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

當(dāng)然,統(tǒng)一一個(gè)總?cè)肟谀繕?biāo)有點(diǎn)宏大,可以循序漸進(jìn),先各業(yè)務(wù)線統(tǒng)一讀寫訪問(wèn)入口,故折衷的目標(biāo)可以是,從今以后,不再有

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

而只有

 
 
 
 
  1. im.58.com:3306 

im業(yè)務(wù)對(duì)db的訪問(wèn),統(tǒng)一到一個(gè)入口上來(lái)了,由中間層來(lái)對(duì)請(qǐng)求進(jìn)行智能路由。

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

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

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

(2)保持訪問(wèn)接口

原來(lái)db的訪問(wèn)方式主要有以上三種:

  • 手工用mysql客戶端連mysql,直連數(shù)據(jù)庫(kù)執(zhí)行命令
  •  java使用jdbc連接數(shù)據(jù)庫(kù)
  • c/c++使用libmysqlclient.a來(lái)對(duì)mysql進(jìn)行訪問(wèn)

所謂保持訪問(wèn)接口,是指上游對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)接口完全不用變,中間件服務(wù)對(duì)上游來(lái)說(shuō),就是數(shù)據(jù)庫(kù)。

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

(3)屏蔽讀寫分離

業(yè)務(wù)層不需要在關(guān)注讀寫分離,由中間件來(lái)進(jìn)行讀寫請(qǐng)求路由。

(4)支持的分庫(kù)

58的db的水平擴(kuò)展,基本是用的分庫(kù)的方式(分庫(kù)比較好,很容易實(shí)現(xiàn)實(shí)例的擴(kuò)容),即:

db.table會(huì)水平拆分為:

db1.table

db2.table

db3.table

db4.table

這樣的話,dao層對(duì)于table就只有一個(gè)table實(shí)例了,比較方便。

根據(jù)前期與各業(yè)務(wù)線同學(xué)的溝通,58在分庫(kù)上的業(yè)務(wù)訪問(wèn)需求為(這個(gè)調(diào)研的周期比較長(zhǎng),和很多業(yè)務(wù)線進(jìn)行了溝通):

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

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

(5)高可用性的支持

高可用的支持又分為兩個(gè)部分:

***部分,故障自動(dòng)發(fā)現(xiàn):下游數(shù)據(jù)庫(kù)掛了,能夠自動(dòng)發(fā)現(xiàn)問(wèn)題,并報(bào)警周知相關(guān)人員。

第二部分,故障自動(dòng)轉(zhuǎn)移:

  • 主庫(kù)掛了,能夠自動(dòng)切換,或者屏蔽寫請(qǐng)求
  • 從庫(kù)掛了,能夠自動(dòng)自動(dòng)切換讀請(qǐng)求量流量
  • 中間件掛了,自動(dòng)切換中間件流量,高可用

(6)可運(yùn)維性的支持

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

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

三、設(shè)計(jì)折衷

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

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

這樣的話,需要對(duì)mysql client server protocol做詳盡的研究,了解:

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

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

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

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

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

(2.1)上游

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

(2.2)下游

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

(2.3)中間層-ConfigMgr

中間層配置文件管理組件ConfigMgr是中間層中非常重要的一個(gè)部分,請(qǐng)求的轉(zhuǎn)發(fā),讀寫分離,分庫(kù)功能的支持,都需要通過(guò)配置來(lái)完成。

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

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

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

 
 
 
 
  1.  
  2.  
  3.         
  4.  
  5.  

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

type=2分庫(kù)支持

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

LOGIC_DB:邏輯數(shù)據(jù)庫(kù),面向上游,例如umc

PARTITION:數(shù)據(jù)庫(kù)分區(qū),可以理解為分庫(kù),例如umc0和umc1,這個(gè)對(duì)上游是透明的

ITEM:數(shù)據(jù)庫(kù)項(xiàng),可以理解為一個(gè)分區(qū)上的一個(gè)讀庫(kù)或者寫庫(kù),這個(gè)對(duì)上游也是透明的

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

 
 
 
 
  1.  
  2.  
  3.     
  4.  
  5.         
  6.  
  7.         
  8.  
  9.         
  10.  
  11.     
  12.  
  13.     
  14.  
  15.         
  16.  
  17.         
  18.  
  19.         
  20.  
  21.     
  22.  
  23.   
  •     LOGIC_DB:需要關(guān)注partition-key-column,也需要關(guān)注partition算法,它要實(shí)現(xiàn)對(duì)PARTITION的請(qǐng)求路由以及結(jié)果集的匯總 
  •     PARTITION:需要關(guān)注ITEM的讀寫特性,它要實(shí)現(xiàn)對(duì)ITEM的讀寫分離 
  •     ITEM:是最終的數(shù)據(jù)庫(kù),和它相關(guān)的配置是數(shù)據(jù)庫(kù)ip/port/name/wr-type 

(2.4)中間層-MysqlServerPart

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

這一層次面臨這些細(xì)節(jié):

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

(2.5)中間層-MysqlClientPart

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

這一層次面臨這些細(xì)節(jié):

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

(2.6)中間層-SqlParser

中間層Sql分析組件SqlParser是中間層中非常重要的一個(gè)部分,它負(fù)責(zé)對(duì)sql語(yǔ)句的語(yǔ)法分析與語(yǔ)義分析。

為什么要進(jìn)行Sql語(yǔ)法語(yǔ)義分析?需要解析出什么東東?

分為兩種情況:

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

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

type=2分庫(kù)支持

對(duì)于分庫(kù)的支持,解析Sql語(yǔ)句可能需要得到這些問(wèn)題的答案:Sql是否帶了partition-key-column?partition-key-column的值是多少?

例如一條Sql語(yǔ)句:select * from user where uid=123456;

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

注意:更細(xì)的情況是,針對(duì)每個(gè)表,分庫(kù)partition-key-column都是不一樣的,上例中還需要將表名user也解析出來(lái)。

這一層次面臨這些細(xì)節(jié):

  • 如何解析Sql語(yǔ)句:可以參考mysql源碼對(duì)SQL語(yǔ)句的解析,亦可參照cober對(duì)SQL語(yǔ)句的解析方法; 

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

(2.7)中間層-SqlModifier

中間層Sql修改組件SqlModifier是中間層中非常重要的一個(gè)部分,它負(fù)責(zé)對(duì)sql語(yǔ)句改寫。

為什么要對(duì)Sql語(yǔ)句進(jìn)行改寫? 

type=1的請(qǐng)求轉(zhuǎn)發(fā),無(wú)需修改Sql,但對(duì)于type=2的分庫(kù)支持,有些Sql語(yǔ)句就必須進(jìn)行改寫。

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

假設(shè)PARTITION分了0和1奇偶兩個(gè)分區(qū),則sql應(yīng)該分別被改寫為:

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

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

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

則sql可能會(huì)被改寫為:

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

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

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

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

只有(2)和(4)兩項(xiàng)需要改寫,改寫方法上文已述,其中(4)的改寫效率較低,使用起來(lái)要謹(jǐn)慎。

(2.8)中間層-SqlRouter

中間層Sql路由組件SqlRouter是中間層中非常重要的一個(gè)部分,它負(fù)責(zé)對(duì)sql語(yǔ)句進(jìn)行路由。

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

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

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

只有(1)和(2)兩項(xiàng)需要路由,(3)和(4)需要將請(qǐng)求分發(fā)至所有的PARTITION。

(2.9)中間層-ResultSetMerger

中間層結(jié)果集合并組件ResultSetMerger是中間層中非常重要的一個(gè)部分,它負(fù)責(zé)對(duì)結(jié)果集進(jìn)行合并,篩選。

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

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

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

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

(2.10)其他組件

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

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

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


網(wǎng)站題目:假如讓你來(lái)設(shè)計(jì)數(shù)據(jù)庫(kù)中間件
鏈接地址:http://www.5511xx.com/article/cccdoec.html