【轉帖】關於數據庫中間件的思考

做者：kimmking
連接：https://www.zhihu.com/question/352256403/answer/878523206
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

題主，恭喜你，你深刻思考了一系列重要問題，做爲一個開源技術人員+數據中間件的愛好者，試着回答一下題主的幾個問題：

1. 何時須要數據中間件，中間件能幹什麼
2. 數據中間件的實現原理，有哪些開源數據中間件
3. 爲何都是國內開源的，而且大都中止了更新
4. 推薦使用什麼數據中間件，有什麼優點

---

1、何時須要數據中間件，中間件能幹什麼

就像題主說的那樣，隨着業務的發展，MySQL、Oracle數據庫裏的表愈來愈大，一兩年之後，2千萬、甚至上億記錄的表就會出現了（通常能夠簡單認爲表比較複雜的時候，MySQL幾百萬上千萬的時候，Oracle幾千萬的時候，就會出現複雜查詢或變動有性能問題），這時候可能會致使複雜的查詢慢，插入和修改數據慢，修改表的DDL執行太慢致使沒法修改列類型或者加索引或者加字段等等。怎麼辦呢？這時候咱們能夠由幾個處理辦法：

• 歷史表：按時間拆分歷史表出去，下降數據量，這個之前比較常見，其實也是一種特殊的水平拆分，對業務有侵入性
• 垂直拆分：按列，將上百列的寬表拆分紅多個列少（也就是每條記錄數據量小）的表，不下降記錄數，可是下降整個表的數據量和索引量大小
• 水平拆分：按某個或某些個列的值哈希後，均勻的將數據拆分到多個一樣的庫or表裏，這樣就直接下降了單庫單表的數據量，好比說拆分紅1024個子表，就能夠將單表的數據量下降3個數量級，原來一億的表，如今單表10萬數據，在單表上作複雜操做均可以很快速了。這樣的缺點就是，原來只須要操做一個表，如今操做以前須要先知道要操做那張表，好比一個用戶表，按uid分表：原來的SQL1: select * from users where uid=1025，如今得先知道uid是1025，而後知道1025%1024==1，SQL就變成了SQL2: select * from users_0001 where uid=1025，看起來對業務也是於侵入型的。怎麼能對業務變得透明，這就須要一箇中間件，幫咱們自動的把SQL1變成SQL2，從而使得咱們分不分庫、分不分表，分多少個，代碼都差很少，不用太多修改。
• 讀寫分離：好比MySQL的TPS/QPS都已經很高了，幾千上萬，並且已經作了1主3從的時候，咱們但願這4個實例都能分擔一些壓力，特別是讀多寫少的狀況，若是把讀的壓力你們平分，就能夠下降主庫的讀壓力，讓主庫關注與寫。這時候也須要一箇中間件來把數據請求路由到不一樣的庫上。

若是咱們的業務發展到了須要下降單庫單表的壓力、或者讀寫分離，而研發團隊又不大，本身對這一塊的技術積累不足以本身開發一些中間層代碼去搞定問題，就像題主同樣，須要考慮引入數據中間件了。爲何都是國內大場開源的數據中間件，小公司數據量不夠，或技術不夠，不須要本身開發中間件，量上來之後，若是使用場景簡單，採用開源技術是最經濟的解決辦法。大公司有能力本身搞定數據中間件，咱們如今知道的都是這部分裏面開源出來的，特別是近幾年，就像有個答主說的同樣，你們都在搞分佈式數據庫了，分佈式數據庫的容量上限，遠大於傳統的關係數據庫MySQL/Oracle，能夠考慮是把中間件的部分功能固化到數據庫裏了，這些公司不太關注這些問題了。另外一方面，有些數據中間件，融入雲的體系，變成閉源的RDS裏的一部分了。

2、數據中間件的實現原理，有哪些開源數據中間件

簡單的說，有兩種原理：

• 客戶端JDBC模式：中間件做爲一個jar包之類的庫，例以下圖中的示意，只須要直接在項目裏引用，配置好分庫分表規則，用中間件包裝一層JDBC數據源，便可每次在調用的時候，JDBC包裝類裏自動替換好SQL，再調用實際的JDBC和SQL，便可完成操做。可是因爲須要直接操做單個庫和表，因此對於SQL會有一些限制，必須帶上肯定的分庫分表條件，不能有太複雜的聚合操做等。

• 代理Proxy模式：

早期主流的開源中間件以下圖：

引自：https://blog.csdn.net/w892824196/article/details/82660415

1. Cobar:阿里巴巴B2B開發的關係型分佈式系統，管理將近3000個MySQL實例。 在阿里經受住了考驗，後面因爲做者的走開的緣由cobar沒有人維護 了，阿里也開發了tddl替代cobar。
2. MyCAT:社區愛好者在阿里cobar基礎上進行二次開發，解決了cobar當時存 在的一些問題，而且加入了許多新的功能在其中。目前MyCAT社區活 躍度很高，目前已經有一些公司在使用MyCAT。整體來講支持度比 較高，也會一直維護下去，
3. OneProxy:數據庫界大牛，前支付寶數據庫團隊領導樓總開發，基於mysql官方 的proxy思想利用c進行開發的，OneProxy是一款商業收費的中間件， 樓總捨去了一些功能點，專一在性能和穩定性上。有朋友測試過說在 高併發下很穩定。
4. Vitess:這個中間件是Youtube生產在使用的，可是架構很複雜。 與以往中間件不一樣，使用Vitess應用改動比較大要 使用他提供語言的API接口，咱們能夠借鑑他其中的一些設計思想。
5. Kingshard:Kingshard是前360Atlas中間件開發團隊的陳菲利用業務時間 用go語言開發的，目前參與開發的人員有3個左右， 目前來看還不是成熟可使用的產品，須要在不斷完善。
6. Atlas:360團隊基於mysql proxy 把lua用C改寫。原有版本是支持分表， 目前已經放出了分庫分表版本。在網上看到一些朋友常常說在高並 發下會常常掛掉，若是你們要使用須要提早作好測試。
7. MaxScale與MySQL Route:這兩個中間件都算是官方的吧，MaxScale是mariadb (MySQL原做者維護的一個版本)研發的，目前版本不支持分庫分表。MySQL Route是如今MySQL 官方Oracle公司發佈出來的一箇中間件。
8. ShardingSphere，後起之秀，源於噹噹網架構部的ShardingJDBC框架。

上面都是提到了分佈分表和讀寫分離的中間件，其實還有一些專一於分佈式事務的、數據複製傳輸的等等，好比fescar，canal、outter等等。

其實淘寶早期開源了TDDL，淘寶分佈式數據中間層，可是隻開源了客戶端jdbc模式，沒有開源proxy代理模式。

3、爲何都是國內開源的，而且大都中止了更新

國內的開源，部分是大公司主導的技術影響力輸出，部分是我的的興趣之做貢獻給社區，總而言之是沒有直接的顯著回報的。也就是說，這一塊一直沒有一個穩定可行的商業模式來支持，因此一直以來，大公司實際上也看不上，由於賺不了錢，而沒有回報的事情就沒法長久，因此天然就中止了更新。對於個別有云服務的公司，這一塊技術發展好了，其實能夠併到雲裏提供數據服務，或者進一步的發展成爲分佈式數據庫，這樣能夠變現了，那就閉源，因此，如今活躍的開源數據中間件，已經很少了，下面就推薦一個活躍的項目。

4、推薦使用什麼數據中間件--ShardingSphere

推薦使用近期加入Apache基金會的第一款數據中間件，也是國人開發的，ShardingSphere項目。能夠直接在這個項目的github commits記錄看到，很是活躍，天天都有提交記錄，issue也一直在持續維護。爲何還活得這麼好呢？由於有張亮團隊的專職在開發、維護和推廣。

詳細文檔和代碼參見：

ShardingSphere​shardingsphere.apache.org apache/incubator-shardingsphere​github.com

ShardingSphere是一套開源的分佈式數據庫中間件解決方案組成的生態圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar（計劃中）這3款相互獨立的產品組成。 他們均提供標準化的數據分片、分佈式事務和數據庫治理功能，可適用於如Java同構、異構語言、雲原生等各類多樣化的應用場景。

ShardingSphere定位爲關係型數據庫中間件，旨在充分合理地在分佈式的場景下利用關係型數據庫的計算和存儲能力，而並不是實現一個全新的關係型數據庫。 它與NoSQL和NewSQL是並存而非互斥的關係。NoSQL和NewSQL做爲新技術探索的前沿，放眼將來，擁抱變化，是很是值得推薦的。反之，也能夠用另外一種思路看待問題，放眼將來，關注不變的東西，進而抓住事物本質。 關係型數據庫當今依然佔有巨大市場，是各個公司核心業務的基石，將來也難於撼動，咱們目前階段更加關注在原有基礎上的增量，而非顛覆。

稍後我推薦ShardingSphere項目的兩個主要PMC，@張亮 和 @曹昊，來關注一下這個問題。