大規模Web應用系統, 幾乎都會遇到數據庫瓶頸問題. 在早期, 通過數據庫配置優化, 表優化, 索引優化等軟件方法, 可以解決一些問題. 馬上, 數據庫瓶頸迫使不得不把MySQL和Apache單獨部署到不同的機器, 形成Web服務器(Web Server)和數據庫服務器(DB Server)的物理分離, 這樣就能解決大部分的問題. 但是, 在繼續發展時, 一臺Web服務器和一臺數據庫服務器也不能滿足高併發的訪問量了.
這時, 問題首先是計算能力的問題, 也就是硬件不夠用的問題. 所以, 需要上多臺Web服務器和多臺數據庫服務器.
有時候, 網站可以縱向切分, 這樣, 任何兩臺服務器(一臺Web Server + 一臺DB Server)單獨配置, 便能運行一個應用. 比如某兩臺運行着論壇程序, 某兩臺運行着新聞程序.
很多情況下, 並不能縱向切分, 每一臺的Web Server的角色和功能都是一樣的, 沒有差別, DB Server也是一樣. 理想的情況下, 同種壓力的SQL語句平均分佈到每一臺DB Server, 那就能解決高併發數據庫請求問題了
dbproxy的作用便是如此: 合理地分配數據庫請求給所有的DB Server, 使得在請求的數量等於或者小於所有DB Server的計算能力總和時, 服務能夠正常運行.
第一種方式的dbproxy: Web Server上的數據庫客戶端(如PHP腳本)擁有選擇DB Server的智能.
這種方式實現簡單, 完全用Web腳本實現, 腳本自己判斷應該連接其中的一臺或者幾臺DB Server, 請決定把SQL請求發給誰. 這種方式因爲性能問題, 所以應用不是很廣.
第二種方式的dbproxy: SQL代理進程
類似HTTP代理服務器, 這種方式的dbproxy獨立運行, 所以客戶端請求將不再直接和DB Server連接, 而是通過它中轉. 這樣的dbproxy, 首先要擁有解析協議(也即SQL)的能力, 這也帶來一個特點, dbproxy可以與後端的MySQL連接, 但卻接收前端(如PHP腳本)發來的Oracle數據庫的SQL請求.
當然, dbproxy的主要功能還是在SQL分發方面. 另外, 還可以在dbproxy上面做與業務更接近的緩存, 相比數據庫的底層緩存很多時候更有效.