13年底，負(fù)責(zé)數(shù)據(jù)庫中間件的設(shè)計(jì)，當(dāng)時(shí)的設(shè)計(jì)文檔，拿出來和大家分享：（1）可以了解下數(shù)據(jù)庫中間件技術(shù)；（2）可以了解下架構(gòu)師系統(tǒng)設(shè)計(jì)的思路；數(shù)據(jù)庫中間層項(xiàng)目背景不再展開，根據(jù)前期的調(diào)研以及和公司同事的討論，中間層的核心目標(biāo)主要有兩個(gè)：（1）db虛擬化：讓db對(duì)業(yè)務(wù)線透明（本文的db均指mysql），業(yè)務(wù)線不再需要知道db的真實(shí)ip，port，主從關(guān)系，讀寫關(guān)系，高可用等；（2）無限容量（分庫）的支持：讓db的分庫對(duì)業(yè)務(wù)線透明；上述目標(biāo)相對(duì)比較寬泛，具體來說，數(shù)據(jù)庫中間層需要實(shí)現(xiàn)以下功能。db1.58.com:3306
db2.58.com:3306
im.58.com:3306
jiaoyou.58.com:3306
db.58.com:3306
所有的業(yè)務(wù)線，對(duì)db的訪問，都只有一個(gè)入口，由數(shù)據(jù)庫中間層來進(jìn)行權(quán)限驗(yàn)證，由中間件來路由請(qǐng)求，這是一種完美的情況。當(dāng)然，統(tǒng)一一個(gè)總?cè)肟谀繕?biāo)有點(diǎn)宏大，可以循序漸進(jìn)，先各業(yè)務(wù)線統(tǒng)一讀寫訪問入口，故折衷的目標(biāo)可以是，從今以后，不再有im.read.db1.58.com:3306
im.read.db2.58.com:3306
im.write.db.58.com:3306
im.58.com:3306
im業(yè)務(wù)對(duì)db的訪問，統(tǒng)一到一個(gè)入口上來了，由中間層來對(duì)請(qǐng)求進(jìn)行智能路由。更簡(jiǎn)化的，甚至可以初期同一個(gè)業(yè)務(wù)線的db讀寫都不對(duì)業(yè)務(wù)線透明，數(shù)據(jù)庫中間層只做簡(jiǎn)單的請(qǐng)求轉(zhuǎn)發(fā)，先初步的把數(shù)據(jù)庫訪問入口收攏到數(shù)據(jù)庫中間層來，為后續(xù)的統(tǒng)一，再統(tǒng)一打下基礎(chǔ)。（1.1）業(yè)務(wù)線入口統(tǒng)一（中轉(zhuǎn)請(qǐng)求）；（1.2）業(yè)務(wù)線入口統(tǒng)一（智能路由）；（2.1）手工用mysql客戶端連mysql，直連數(shù)據(jù)庫執(zhí)行命令；（2.2）java使用jdbc連接數(shù)據(jù)庫；（2.3）c/c++使用libmysqlclient.a來對(duì)mysql進(jìn)行訪問；所謂保持訪問接口，是指上游對(duì)數(shù)據(jù)庫的訪問接口完全不用變，中間件服務(wù)對(duì)上游來說，就是數(shù)據(jù)庫。由于SQL協(xié)議是非常復(fù)雜的，在db的客戶端與服務(wù)器插入了一個(gè)中間層之后，不一定能對(duì)所有的SQL功能都進(jìn)行支持，支持哪些SQL是需要慎重考慮的。業(yè)務(wù)層不需要在關(guān)注讀寫分離，由中間件來進(jìn)行讀寫請(qǐng)求路由。58的db的水平擴(kuò)展，基本是用的分庫的方式（分庫比較好，很容易實(shí)現(xiàn)實(shí)例的擴(kuò)容），即：db1.table
db2.table
db3.table
db4.table
這樣的話，dao層對(duì)于table就只有一個(gè)table實(shí)例了，比較方便。根據(jù)前期與各業(yè)務(wù)線同學(xué)的溝通，58在分庫上的業(yè)務(wù)訪問需求為（這個(gè)調(diào)研的周期比較長(zhǎng)，和很多業(yè)務(wù)線進(jìn)行了溝通）：故對(duì)分庫上的分布式SQL功能，數(shù)據(jù)庫中間層只需要支持上上述四項(xiàng)即可。第一部分，故障自動(dòng)發(fā)現(xiàn)：下游數(shù)據(jù)庫掛了，能夠自動(dòng)發(fā)現(xiàn)問題，并報(bào)警周知相關(guān)人員。
第二部分，故障自動(dòng)轉(zhuǎn)移：
（5.1）主庫掛了，能夠自動(dòng)切換，或者屏蔽寫請(qǐng)求；（5.2）從庫掛了，能夠自動(dòng)自動(dòng)切換讀請(qǐng)求量流量；（5.3）中間件掛了，自動(dòng)切換中間件流量，高可用；
（6.1）支持一些統(tǒng)計(jì)數(shù)據(jù)的展現(xiàn)；however，只要總的框架設(shè)計(jì)具備可擴(kuò)展性，這些功能可以循序漸進(jìn)，逐步添加。既然選擇了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做詳盡的研究，了解： - 請(qǐng)求響應(yīng)二進(jìn)制協(xié)議各種細(xì)節(jié)協(xié)議這一塊的掌握必須詳盡，好在官方文檔相對(duì)比較全面：http://dev.mysql.com/doc/internals/en/client-server-protocol.html - mysql客戶端，java使用jdbc作為上游連接，c/c++使用libmysql.a作為上游連接，使用的是Mysql Client Server協(xié)議 - DBA亦可以向中間件發(fā)送一些管理命令，或者查看一些統(tǒng)計(jì)信息，使用的是自己定義的內(nèi)部協(xié)議處于系統(tǒng)體系結(jié)構(gòu)中的最后端，系統(tǒng)中間件的下游就是mysql集群了，中間件與mysql之間使用的也是Mysql Client Server協(xié)議。中間層配置文件管理組件ConfigMgr是中間層中非常重要的一個(gè)部分，請(qǐng)求的轉(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配置類型有兩種：type=1請(qǐng)求轉(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”，中間件則將請(qǐng)求轉(zhuǎn)發(fā)到實(shí)際的后端數(shù)據(jù)庫item，item中配置了后端數(shù)據(jù)庫的ip/port/name。解釋分庫支持的配置之前，先說明一下數(shù)據(jù)庫的層次結(jié)構(gòu)LOGIC_DB、PARTITION、ITEM。LOGIC_DB：邏輯數(shù)據(jù)庫，面向上游，例如umcPARTITION：數(shù)據(jù)庫分區(qū)，可以理解為分庫，例如umc0和umc1，這個(gè)對(duì)上游是透明的ITEM：數(shù)據(jù)庫項(xiàng)，可以理解為一個(gè)分區(qū)上的一個(gè)讀庫或者寫庫，這個(gè)對(duì)上游也是透明的<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算法，它要實(shí)現(xiàn)對(duì)PARTITION的請(qǐng)求路由以及結(jié)果集的匯總 - PARTITION：需要關(guān)注ITEM的讀寫特性，它要實(shí)現(xiàn)對(duì)ITEM的讀寫分離 - ITEM：是最終的數(shù)據(jù)庫，和它相關(guān)的配置是數(shù)據(jù)庫ip/port/name/wr-type中間層服務(wù)端組件MysqlServerPart是中間層中非常重要的一個(gè)部分，它負(fù)責(zé)端口的監(jiān)聽+請(qǐng)求接收與返回（服務(wù)端網(wǎng)絡(luò)IO），MysqlProtocol的解析。根據(jù)其功能，MysqlServerPart組件又主要分為兩個(gè)組件ServerIOMgr組件（服務(wù)端IO管理），MysqlProtocolAnalyzer組件（Mysql協(xié)議分析）。 - server網(wǎng)絡(luò)框架的選?。航ㄗh使用異步server - 并發(fā)模型的選取：建議使用IO-thread + multi-work-thread的并發(fā)模型 - 內(nèi)存管理模型的選?。航ㄗh使用內(nèi)存池 - 連接上下文管理，最容易想到的上下文，一個(gè)數(shù)據(jù)庫連接是和一個(gè)邏輯庫LOGIC_DB綁定的 - Mysql如何建立數(shù)據(jù)庫連接：需要考察Mysql協(xié)議 - Mysql協(xié)議的細(xì)化解析：需要考察Mysql協(xié)議中間層客戶端組件MysqlClientPart是中間層中非常重要的一個(gè)部分，它負(fù)責(zé)中間件對(duì)mysql的連接池管理，以及返回結(jié)果集的解析。根據(jù)其功能，MysqlClientPart組件又主要分為兩個(gè)組件ClientConnPoolMgr組件（客戶端連接池管理），ResultSetAnalyzer組件（返回結(jié)果集分析）。 - 數(shù)據(jù)庫連接池的實(shí)現(xiàn) - 數(shù)據(jù)庫連接模型的選型：建議前期使用同步模型 - 連接上下文管理，最容易想到的上下文，一個(gè)數(shù)據(jù)庫連接是和一個(gè)ITEM綁定的 - Mysql結(jié)果集的細(xì)化解析：需要考察Mysql協(xié)議中間層Sql分析組件SqlParser是中間層中非常重要的一個(gè)部分，它負(fù)責(zé)對(duì)sql語句的語法分析與語義分析。為什么要進(jìn)行Sql語法語義分析？需要解析出什么東東？type=1請(qǐng)求轉(zhuǎn)發(fā)對(duì)于請(qǐng)求的中轉(zhuǎn)，上游一個(gè)數(shù)據(jù)庫連接對(duì)應(yīng)一個(gè)邏輯庫LOGIC_DB，由ConfigMgr可以知道對(duì)應(yīng)下游一個(gè)真實(shí)的ITEM（ip/port/db），此時(shí)直接轉(zhuǎn)發(fā)請(qǐng)求即可，無需解析Sql語句。對(duì)于分庫的支持，解析Sql語句可能需要得到這些問題的答案：Sql是否帶了partition-key-column？partition-key-column的值是多少？例如一條Sql語句：select * from user where uid=123456;就必須將“uid”列屬性，以及uid的列屬性值“123456”解析出來，以用作后續(xù)請(qǐng)求路由。注意：更細(xì)的情況是，針對(duì)每個(gè)表，分庫partition-key-column都是不一樣的，上例中還需要將表名user也解析出來。 - 如何解析Sql語句：可以參考mysql源碼對(duì)SQL語句的解析，亦可參照cober對(duì)SQL語句的解析方法；注：由于我們只需要支持多庫，數(shù)據(jù)庫庫名信息是在“連接”這一層獲取的，又我們支持的分布式Sql的種類有限，故只需解析partition-key-column，offset/limit等少數(shù)信息即可。
中間層Sql修改組件SqlModifier是中間層中非常重要的一個(gè)部分，它負(fù)責(zé)對(duì)sql語句改寫。為什么要對(duì)Sql語句進(jìn)行改寫？type=1的請(qǐng)求轉(zhuǎn)發(fā)，無需修改Sql，但對(duì)于type=2的分庫支持，有些Sql語句就必須進(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庫；select * from user where uid in(1,3,5); => 路由給1庫；又例如：select * from user limit 1000,10;select * from user limit 0,1010; => 分別路由到兩個(gè)庫，收集完結(jié)果集共2020條記錄，再排序取其中1000-1010這10條。結(jié)合我們需要實(shí)現(xiàn)的四類分布式Sql：只有（2）和（4）兩項(xiàng)需要改寫，改寫方法上文已述，其中（4）的改寫效率較低，使用起來要謹(jǐn)慎。中間層Sql路由組件SqlRouter是中間層中非常重要的一個(gè)部分，它負(fù)責(zé)對(duì)sql語句進(jìn)行路由。結(jié)合我們需要實(shí)現(xiàn)的四類分布式Sql：只有（1）和（2）兩項(xiàng)需要路由，（3）和（4）需要將請(qǐng)求分發(fā)至所有的PARTITION。中間層結(jié)果集合并組件ResultSetMerger是中間層中非常重要的一個(gè)部分，它負(fù)責(zé)對(duì)結(jié)果集進(jìn)行合并，篩選。哪些Sql需要合并結(jié)果集，篩選結(jié)果集？結(jié)合我們需要實(shí)現(xiàn)的四類分布式Sql：其中（2）和（3）類查詢需要將結(jié)果集進(jìn)行合并，（4）不但要合并結(jié)果集，還需要將結(jié)果集在本地進(jìn)行排序，然后再篩選出真正的結(jié)果集。 - AdminServer：監(jiān)聽一個(gè)新端口，接收數(shù)據(jù)庫管理員命令的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)圖為：感謝看完，說明你對(duì)數(shù)據(jù)庫中間件感興趣，希望大家有，謝轉(zhuǎn)。
