不少朋友經(jīng)常會(huì)問(wèn)我以下問(wèn)題：

58到家有沒(méi)有使用數(shù)據(jù)庫(kù)中間件

使用了什么數(shù)據(jù)庫(kù)中間件，是自研，還是第三方

怎么實(shí)現(xiàn)的，是基于客戶端的中間件，還是基于服務(wù)端的中間件

使用中間件后，join/子查詢/集函數(shù)/事務(wù)等問(wèn)題是怎么解決的

…

你是不是也有類似的疑問(wèn)？

然而，“究竟為什么要引入數(shù)據(jù)庫(kù)中間件”卻很少有人問(wèn)及。“架構(gòu)師之路”文章思路，以解決“為什么”為優(yōu)先，借著近期撰寫互聯(lián)網(wǎng)分層架構(gòu)系列文章，講一講這個(gè)核心問(wèn)題：

究竟為什么要引入數(shù)據(jù)庫(kù)中間件

經(jīng)過(guò)連續(xù)分層架構(gòu)演進(jìn)，DAO層，基礎(chǔ)數(shù)據(jù)服務(wù)化，通用業(yè)務(wù)服務(wù)化，前后端分離之后，一個(gè)業(yè)務(wù)系統(tǒng)的后端結(jié)構(gòu)如上：

web-view層通過(guò)http接口，從web-data獲取json數(shù)據(jù)(前后端分離)

web-data層通過(guò)RPC接口，從biz-service獲取數(shù)據(jù)(通用業(yè)務(wù)服務(wù))

biz-service層通過(guò)RPC接口，從base-service獲取數(shù)據(jù)(基礎(chǔ)數(shù)據(jù)服務(wù))

base-service層通過(guò)DAO，從db獲取數(shù)據(jù)(DAO)

db存儲(chǔ)數(shù)據(jù)

隨著時(shí)間的推移，數(shù)據(jù)量會(huì)越來(lái)越大，base-service通過(guò)DAO來(lái)訪問(wèn)db的性能會(huì)越來(lái)越低，需要開始考慮對(duì)db進(jìn)行水平切分，一旦db進(jìn)行水平切分，原來(lái)很多SQL可以支持的功能，就需要base-service層來(lái)進(jìn)行特殊處理：

有些數(shù)據(jù)需要路由到特定的水平切分庫(kù)

有些數(shù)據(jù)不確定落在哪一個(gè)水平切分庫(kù)，就需要訪問(wèn)所有庫(kù)

有些數(shù)據(jù)需要訪問(wèn)全局的庫(kù)，拿到數(shù)據(jù)的全局視野，到service層進(jìn)行額外處理

…

更具體的，對(duì)于前臺(tái)高并發(fā)的業(yè)務(wù)，db水平切分后，有這么幾類典型的業(yè)務(wù)場(chǎng)景及應(yīng)對(duì)方案。特別強(qiáng)調(diào)一下，此處應(yīng)對(duì)的是“前臺(tái)”“高并發(fā)”“db水平切分”的場(chǎng)景，對(duì)于后臺(tái)的需求，將通過(guò)前臺(tái)與后臺(tái)分離的架構(gòu)處理，不在此處討論。

一：partition key上的單行查詢

典型場(chǎng)景：通過(guò)uid查詢user

場(chǎng)景特點(diǎn)：

通過(guò)patition key查詢

每次只返回一行記錄

解決方案：base-service層通過(guò)patition key來(lái)進(jìn)行庫(kù)路由

如上圖：

user-service底層user庫(kù)，分庫(kù)patition key是uid

uid上的查詢，user-service可以直接定位到庫(kù)

二、非patition key上的單行查詢

典型場(chǎng)景：通過(guò)login_name查詢user

場(chǎng)景特點(diǎn)：

通過(guò)非patition key查詢

每次只返回一行記錄

解決方案1：base-service層訪問(wèn)所有庫(kù)

如上圖：

user-service通過(guò)login_name先查全庫(kù)

結(jié)果集在user-service再合并，最終返回一條記錄

解決方案2：base-service先查mapping庫(kù)，再通過(guò)patition key路由

如上圖：

新建mapping庫(kù)，記錄login_name到uid的映射關(guān)系

當(dāng)有非 patition key的查詢時(shí)，先通過(guò)login_name查詢uid

再通過(guò)patition key進(jìn)行路由，最終返回一條記錄

解決方案3：基因法

關(guān)于“基因法”解決非patition key上的查詢需求詳見(jiàn)《分庫(kù)后，非patition key上訪問(wèn)的多種解決辦法》。

三、patition key上的批量查詢

典型場(chǎng)景：用戶列表uid上的IN查詢

場(chǎng)景特點(diǎn)：

通過(guò)patition key查詢

每次返回多行記錄

解決方案1：base-service層訪問(wèn)所有庫(kù)，結(jié)果集到base-service合并

解決方案2：base-service分析路由規(guī)則，按需訪問(wèn)

如上圖：

base-service根據(jù)路由規(guī)則分析，判斷出有些數(shù)據(jù)落在庫(kù)1，有些數(shù)據(jù)落在庫(kù)2

base-service按需訪問(wèn)相關(guān)庫(kù)，而不是訪問(wèn)全庫(kù)

base-service合并結(jié)果集，返回列表數(shù)據(jù)

四、非patition key上的夸庫(kù)分頁(yè)需求

關(guān)于分庫(kù)后，夸庫(kù)分頁(yè)的查詢需求，詳見(jiàn)《業(yè)界難題，夸庫(kù)分頁(yè)的四種方案》。

五、其他需求…

本文寫到這里，上述一、二、三、四、五其實(shí)都不是重點(diǎn)，base-service層通過(guò)各種各樣的奇技淫巧，能夠解決db水平切分后的數(shù)據(jù)訪問(wèn)問(wèn)題，只不過(guò)：

base-service層的復(fù)雜度提高了

數(shù)據(jù)的獲取效率降低了

當(dāng)需要進(jìn)行db水平切分的base-service越來(lái)越多以后，此時(shí)分層架構(gòu)會(huì)變成下面這個(gè)樣子：

底層的復(fù)雜性會(huì)擴(kuò)散到各個(gè)base-service，所有的base-service都要關(guān)注：

patition key路由

非patition key查詢，先mapping，再路由

先全庫(kù)，再合并

先分析，再按需路由

夸庫(kù)分頁(yè)處理

…

這個(gè)架構(gòu)圖是不是看上去很別扭？如何讓數(shù)據(jù)的獲取更加高效快捷呢？

數(shù)據(jù)庫(kù)中間件的引入，勢(shì)在必行。

這是“基于服務(wù)端”的數(shù)據(jù)庫(kù)中間件架構(gòu)圖：

base-service層，就像訪問(wèn)db一樣，訪問(wèn)db-proxy，高效獲取數(shù)據(jù)

所有底層的復(fù)雜性，都屏蔽在db-proxy這一層

這是“基于客戶端”的數(shù)據(jù)庫(kù)中間件架構(gòu)圖：

base-service層，通過(guò)db-proxy.jar，高效獲取數(shù)據(jù)

所有底層的復(fù)雜性，都屏蔽在db-proxy.jar這一層

結(jié)論：

當(dāng)數(shù)據(jù)庫(kù)水平切分，base-service層獲取db數(shù)據(jù)過(guò)于復(fù)雜，成為通用痛點(diǎn)的時(shí)候，就應(yīng)該抽象出數(shù)據(jù)庫(kù)中間件，簡(jiǎn)化數(shù)據(jù)獲取過(guò)程，提高數(shù)據(jù)獲取效率，向上游屏蔽底層的復(fù)雜性。

任何脫離業(yè)務(wù)的架構(gòu)設(shè)計(jì)，都是耍流氓。

“為什么”比“怎么樣”更重要。

閱讀前序文章，“分層架構(gòu)設(shè)計(jì)”的背景與來(lái)龍去脈更加清晰：

若有收獲，隨手幫轉(zhuǎn)喲。

總結(jié)

以上是生活随笔為你收集整理的mysql为什么需要中间件_究竟为什么要引入数据库中间件的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。