數據庫中間件的主要作用是向應用程序開發人員屏蔽讀寫分離和分庫分表面臨的挑戰，并隱藏底層實現細節，使得開發人員可以像操作單庫單表那樣去操作數據。在介紹分庫分表的主流設計方案前，我們首先回顧一下在單個庫的情況下，應用的架構，可以用下圖進行描述：

可以看到在操作單庫單表的情況下，我們是直接在應用中通過數據源(c3p0、druid、dbcp等)與數據庫建立連接，進行讀寫操作。而對于讀寫分離和分庫分表，應用都要操作多個數據庫實例，在這種情況下，我們就需要使用到數據庫中間件。

1 主流的數據庫中間件設計方案

典型的數據庫中間件設計方案有2種：服務端代理(代理數據庫)、客戶端代理(代理數據源)。下圖演示了這兩種方案的架構：

可以看到不論是代理數據庫還是代理數據源，底層都操作了多個數據庫實例。不同的是：

在數據庫代理中：

我們獨立部署一個代理服務，這個代理服務背后管理多個數據庫實例。而在應用中，我們通過一個普通的數據源(c3p0、druid、dbcp等)與代理服務器建立連接，所有的sql操作語句都是發送給這個代理，由這個代理去操作底層數據庫，得到結果并返回給應用。在這種方案下，分庫分表和讀寫分離的邏輯對開發人員是完全透明的。

在數據源代理中：

應用程序需要使用一個特定的數據源，其作用是代理，內部管理了多個普通的數據源(c3p0、druid、dbcp等)，每個普通數據源各自與不同的庫建立連接。應用程序產生的sql交給數據源代理進行處理，數據源內部對sql進行必要的操作，如sql改寫等，然后交給各個普通的數據源去執行，將得到的結果進行合并，返回給應用。數據源代理通常也實現了JDBC規范定義的API，因此能夠直接與orm框架整合。

2 主流的數據庫中間件實現

無論是代理數據庫，還是代理數據源，二者的作用都是類似的。以下列出了這兩種方案目前已有的實現以及各自的優缺點：

數據庫代理

目前的實現方案有：阿里巴巴開源的cobar，mycat團隊在cobar基礎上開發的mycat，mysql官方提供的mysql-proxy，奇虎360在mysql-proxy基礎開發的atlas。目前除了mycat，其他幾個項目基本已經沒有維護。

優點：多語言支持。也就是說，不論你用的php、java或是其他語言，都可以支持。原因在于數據庫代理本身就實現了mysql的通信協議，你可以就將其看成一個mysql 服務器。mysql官方團隊為不同語言提供了不同的客戶端卻動，如java語言的mysql-connector-java，python語言的mysql-connector-python等等。因此不同語言的開發者都可以使用mysql官方提供的對應的驅動來與這個代理服務器建通信。

缺點：實現復雜。因為代理服務器需要實現mysql服務端的通信協議，因此實現難度較大。

數據源代理

目前的實現方案有：阿里巴巴開源的tddl，大眾點評開源的zebra，當當網開源的sharding-jdbc。需要注意的是tddl的開源版本只有讀寫分離功能，沒有分庫分表，且開源版本已經不再維護。大眾點評的zebra開源版本代碼已經很久更新，基本上處于停滯的狀態。當當網的sharding-jdbc目前算是做的比較好的，代碼時有更新，文檔資料比較全。

優點：更加輕量，可以與任何orm框架整合。這種方案不需要實現mysql的通信協議，因為底層管理的普通數據源，可以直接通過mysql-connector-java驅動與mysql服務器進行通信，因此實現相對簡單。

缺點：僅支持某一種語言。例如tddl、zebra、sharding-jdbc都是使用java語言開發，因此對于使用其他語言的用戶，就無法使用這些中間件。版本升級困難，因為應用使用數據源代理就是引入一個jar包的依賴，在有多個應用都對某個版本的jar包產生依賴時，一旦這個版本有bug，所有的應用都需要升級。而數據庫代理升級則相對容易，因為服務是單獨部署的，只要升級這個代理服務器，所有連接到這個代理的應用自然也就相當于都升級了。

ORM框架代理：

目前有hibernate提供的hibernate-shards，也可以通過mybatis插件的方式編寫。相對于前面兩種方案，這種方案可以說是只有缺點，沒有優點。

Dragon項目采用的方案是代理客戶端數據源的方式。

總結

以上是生活随笔為你收集整理的python的数据库中间件_数据库中间件设计方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。