數(shù)據(jù)庫中間件的主要作用是向應(yīng)用程序開發(fā)人員屏蔽讀寫分離和分庫分表面臨的挑戰(zhàn)，并隱藏底層實現(xiàn)細(xì)節(jié)，使得開發(fā)人員可以像操作單庫單表那樣去操作數(shù)據(jù)。在介紹分庫分表的主流設(shè)計方案前，我們首先回顧一下在單個庫的情況下，應(yīng)用的架構(gòu)，可以用下圖進(jìn)行描述：

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

1 主流的數(shù)據(jù)庫中間件設(shè)計方案

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

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

在數(shù)據(jù)庫代理中：

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

在數(shù)據(jù)源代理中：

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

2 主流的數(shù)據(jù)庫中間件實現(xiàn)

無論是代理數(shù)據(jù)庫，還是代理數(shù)據(jù)源，二者的作用都是類似的。以下列出了這兩種方案目前已有的實現(xiàn)以及各自的優(yōu)缺點：

數(shù)據(jù)庫代理

目前的實現(xiàn)方案有：阿里巴巴開源的cobar，mycat團隊在cobar基礎(chǔ)上開發(fā)的mycat，mysql官方提供的mysql-proxy，奇虎360在mysql-proxy基礎(chǔ)開發(fā)的atlas。目前除了mycat，其他幾個項目基本已經(jīng)沒有維護(hù)。

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

缺點：實現(xiàn)復(fù)雜。因為代理服務(wù)器需要實現(xiàn)mysql服務(wù)端的通信協(xié)議，因此實現(xiàn)難度較大。

數(shù)據(jù)源代理

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

優(yōu)點：更加輕量，可以與任何orm框架整合。這種方案不需要實現(xiàn)mysql的通信協(xié)議，因為底層管理的普通數(shù)據(jù)源，可以直接通過mysql-connector-java驅(qū)動與mysql服務(wù)器進(jìn)行通信，因此實現(xiàn)相對簡單。

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

ORM框架代理：

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

Dragon項目采用的方案是代理客戶端數(shù)據(jù)源的方式。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。