不少朋友經常會問我以下問題：
你是不是也有類似的疑問？
然而，「究竟為什麼要引入資料庫中介軟體」卻很少有人問及。 「架構師之路」文章思路，以解決「為什麼」為優先，藉著近期撰寫網際網路分層架構系列文章，講一講這個核心問題：
經過連續分層架構演進，dao層，基礎資料服務化，通用業務服務化，前後端分離之後，乙個業務系統的後端結構如上：
隨著時間的推移，資料量會越來越大，base-service通過dao來訪問db的效能會越來越低，需要開始考慮對db進行水平切分，一旦db進行水平切分，原來很多sql可以支援的功能，就需要base-service層來進行特殊處理：
更具體的，對於前台高併發的業務，db水平切分後，有這麼幾類典型的業務場景及應對方案。特別強調一下，此處應對的是「前台」「高併發」「db水平切分」的場景，對於後台的需求，將通過前台與後台分離的架構處理，不在此處討論。
一：partition key上的單行查詢
典型場景：通過uid查詢user
場景特點：
解決方案：base-service層通過patition key來進行庫路由
如上圖：
二、非patition key上的單行查詢
典型場景：通過login_name查詢user
場景特點：
解決方案1：base-service層訪問所有庫
如上圖：
如上圖：
當有非 patition key的查詢時，先通過login_name查詢uid
再通過patition key進行路由，最終返回一條記錄
解決方案3：基因法
關於「基因法」解決非patition key上的查詢需求詳見《分庫後，非patition key上訪問的多種解決辦法》。
三、patition key上的批量查詢
典型場景：使用者列表uid上的in查詢
場景特點：
解決方案1：base-service層訪問所有庫，結果集到base-service合併
解決方案2：base-service分析路由規則，按需訪問
如上圖：
四、非patition key上的誇庫分頁需求
關於分庫後，誇庫分頁的查詢需求，詳見《業界難題，誇庫分頁的四種方案》。
五、其他需求…
當需要進行db水平切分的base-service越來越多以後，此時分層架構會變成下面這個樣子：
底層的複雜性會擴散到各個base-service，所有的base-service都要關注：
這個架構圖是不是看上去很彆扭？如何讓資料的獲取更加高效快捷呢？
資料庫中介軟體的引入，勢在必行。
這是「基於服務端」的資料庫中介軟體架構圖：
這是「基於客戶端」的資料庫中介軟體架構圖：
結論：
當資料庫水平切分，base-service層獲取db資料過於複雜，成為通用痛點的時候，就應該抽象出資料庫中介軟體，簡化資料獲取過程，提高資料獲取效率，向上游遮蔽底層的複雜性。
任何脫離業務的架構設計，都是耍流氓。
「為什麼」比「怎麼樣」更重要。
系統架構中為什麼要引入訊息中介軟體？
感謝博主的分享，系統架構中為什麼要引入訊息中介軟體？在本文的開頭，我們將討論訊息中介軟體的高頻訪問問題，它也將涵蓋mq中介軟體的一些常見技術問題。如果面試官看了你的簡歷中使用mq中介軟體的經歷，可能會有以下問題 在你的公司的生產環境中使用了什麼訊息中介軟體？為什麼要將訊息中介軟體引入系統？引入訊息中...
面試 資料庫 中介軟體
lru是redis唯一支援的 演算法 no eviction 不刪除策略 對於所有的key allkeys lru 刪除最近訪問頻率低的key allkeys random 隨機刪除一部分key 對於設定expire volatile lru 刪除最近訪問頻率低的key volatile rando...
mysql proxy資料庫中介軟體架構
一 mysql proxy簡介 mysql proxy是mysql官方提供的mysql中介軟體服務，上游可接入若干個mysql client，後端可連線若干個mysql server。它使用mysql協議，任何使用mysql client的上游無需修改任何 即可遷移至mysql proxy上。mys...