談起為什麼需要資料庫中介軟體，我們首先談談乙個典型的**架構演進。系統架構隨著業務的變化演進，從而推動各種技術的發展，而資料庫中介軟體技術就是在架構演進**現的。
（1）初始架構方案
初始架構如上圖所示。我們初始在單機上同時部署tomcat和db。客戶端訪問的時候，首先通過dns解析獲得我們服務端的機器ip，然後通過網路連線，連線到tomcat，然後後端應用再與db互動，進行狀態的讀取和更新。但是隨著業務的發展，單機部署多個應用會出現應用之間的資源爭搶問題，影響一些功能的響應，降低服務質量。所以，自然而然我們要對架構進行變更，最基本的能想到的就是將不同引用分別部署，就形成了如下的架構。
（2）第一次架構變更
如上圖所示，我們在這裡將tomcat和db分別部署，這樣就不存在資源爭搶問題。客戶端請求來到以後，不同業務伺服器只提供其特有的功能，db伺服器只提供db的讀取和變更。然而，隨著業務持續變更，客戶請求併發增加，單機tomcat並不能再滿足高併發的請求，同時，很多的請求並不需要一直跟db互動，所以我們可以在架構中加入快取，提高併發量，同時減小非必要的db請求，這樣就有了架構的第二次演進。
（3）第二次架構演進
當然，我們這裡可以使用redis集群，進一步提公升快取效率，如上面右圖所示。隨著業務持續增加，單機tomca的併發壓力變得非常大，因此我們進入第三次演進，通過引入反向**和負載均衡，進一步提公升系統併發。
（4）第三次演進
到這裡，反向**將使用者的請求均勻分發到每個tomcat上。但是，隨著併發請求的繼續增加，更多的請求會擊穿快取，單機資料庫將會成為瓶頸，那麼就有了接下來的演進，將資料庫讀寫分離。
（5）第四次演進
當業務量持續增長的時候，各種業務交織在一起，不同業務之間會存在資料庫競爭，互相影響效能。那麼，我們能做的就是讓db按照業務進行分庫。
（6）第五次演進
這次變更我們讓不同的業務方連上不同的db，這樣就可以避免不同業務對db資源（鏈結，查詢等）的競爭。但是，隨著業務量的持續上公升，單機寫庫將會逐漸達到瓶頸，因此我們就想到將資料的大表拆成小表，大庫拆成小庫。架構演進到這裡遇到了我們將要講的問題。
這裡總結一下，從上面的架構演進過程我們可以看到，當業務量持續上公升，db的讀寫分離，業務db分離等措施採取以後，單機的db效能瓶頸將會成為整理db系統的瓶頸。我們當然可以通過購買高效能db來滿足需求，但是，這樣做是很不划算的。作為企業，在執行和發展過程中需要注意資源的合理利用，需要考量成本。通用的做法是通過購買商用機器去構建集群，在不能無限提高單機db效能的情況下我們自然而然的想到就是對db進行分庫分表，當然，前提是單機效能不能再滿足業務需求。我們在考量是否需要做分庫分表的時候，通常需要做一下思考：
（1）資料庫表中資料數量級是否達到一定量級，大資料量表對索引和查詢是否帶來了較大壓力；
（2）資料庫的吞吐量是否達到瓶頸，是否需要多個資料庫例項來分解大量請求帶來的壓力；
（3）最重要一定，有沒有必要自己做分庫分表方案，是否直接使用雲解決方案能夠直接解決問題呢。
我任務第三個問題是需要深入考量的。企業在發展過程中要注意成本考量，如果作為中小企業，我們要考量是否需要自研相關軟體，投入相應的人力物力能否得到相匹配的價值，這是很重要的。尤其是，現在雲技術的成熟，讓很多企業可以減小對底層基礎軟體和裝置的維護依賴，減少成本。當然我這裡分享文章，只是想讓自己曾經做的事情能留下來，做個總結。如果有一天想拿來作為參考，也歡迎分享。
面試 資料庫 中介軟體
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...
mysql proxy資料庫中介軟體架構
一 mysql proxy簡介 mysql proxy是mysql官方提供的mysql中介軟體服務，上游可接入若干個mysql client，後端可連線若干個mysql server。它使用mysql協議，任何使用mysql client的上游無需修改任何 即可遷移至mysql proxy上。mys...