為什么要引入數(shù)據(jù)庫(kù)中間件，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

富蘊(yùn)網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、APP開(kāi)發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開(kāi)發(fā)，運(yùn)營(yíng)維護(hù)。創(chuàng)新互聯(lián)建站自2013年起到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專(zhuān)注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。

不少朋友經(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)題是怎么解決的

你是不是也有類(lèi)似的疑問(wèn)?

然而，“究竟為什么要引入數(shù)據(jù)庫(kù)中間件”卻很少有人問(wèn)及。  “架構(gòu)師之路”文章思路，以解決“為什么”為優(yōu)先，借著近期撰寫(xiě)互聯(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)越低，需要開(kā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水平切分后，有這么幾類(lèi)典型的業(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è)的四種方案》。

五、其他需求…

本文寫(xiě)到這里，上述一、二、三、四、五其實(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這一層

當(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ù)雜性。

關(guān)于為什么要引入數(shù)據(jù)庫(kù)中間件問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。

分享題目：為什么要引入數(shù)據(jù)庫(kù)中間件
網(wǎng)頁(yè)路徑：http://aaarwkj.com/article14/igihge.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供關(guān)鍵詞優(yōu)化、定制開(kāi)發(fā)、品牌網(wǎng)站制作、企業(yè)網(wǎng)站制作、營(yíng)銷(xiāo)型網(wǎng)站建設(shè)、外貿(mào)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)