一般對於業務記錄類隨時間會不斷增加的數據，當數據量增加到一定量（一般認為整型值為主的表達到千萬級，字符串為主的表達到五百萬）的時候，性能將遇到瓶頸，同時調整表結構也會變得非常困難。為了避免生產遇到這樣的問題，在做系統設計時需要預估可能產生的數據量：預估記錄主體個數*預估記錄主體產生的記錄數（e.g.用戶訂單表預估數據量=預估用戶數*單用戶產生訂單數），預估達到一定量時，就不得不考慮分庫分表了，目前國內比較成熟的開源數據庫中間件有sharding-jdbc、mycat；而drds是阿里雲最近推出的商業產品，考慮到大部分公司都在使用阿里雲，做一個全家桶，也是一個不錯的選擇。接下來將對這三款產品的優缺點及適用場景做以介紹。
可以看出sharding-jdbc作為一個組件集成在應用內，而mycat則作為一個獨立的應用需要單獨部署，drds則是阿里雲的一個獨立產品，不過需要結合rds一起使用。從架構上看sharding-jdbc更符合分布式架構的設計，直連數據庫，沒有中間應用，理論性能是最高的（實際性能需要結合具體的代碼實現，理論性能可以理解為上限，通過不斷優化代碼實現，逐漸接近理論性能）。同時缺點也很明顯，由於作為組件存在，需要集成在應用內，意味着作為使用方，必須要集成到代碼里，使得開發成本相對較高；另一方面，由於需要集成在應用內，使得需要針對不同語言（java、C、PHP……）有不同的實現（事實上sharding-jdbc目前只支持java），這樣組件本身的維護成本也會很高。最終將應用場景限定在由java開發的應用這一種場景下。
sharding-jdbc后續發展為Sharding-Sphere，包含sharding-jdbc、Sharding-Proxy、Sharding-Sidecar
來源：https://github.com/sharding-sphere/sharding-sphere
mycat是支持SQL92標准，遵守Mysql原生協議，跨語言，跨平台，跨數據庫的通用中間件代理。作為對比可以參考上表中的Sharding-Proxy，需要單獨部署，由於遵守Mysql原生協議，應用時不需要特殊處理，和使用MySQL是一樣的，所以應用場景不受限制；但是mycat不支持二維路由，僅支持單庫多表或多庫單表，同時由於自定義連接池，這樣就會存在mycat自身維護一個連接池，MySQL也有一個連接池，任何一個連接池上限都會成為性能的瓶頸，而mycat的連接池設計也略顯粗暴，當請求鏈接數大於設置連接池上限時直接拋出異常，因此在配置mycat連接池的大小是，需要結合場景做合理設置。總的來說，mycat以邏輯表的形式屏蔽掉應用處理分庫分表的復雜邏輯，遵守Mysql原生協議，跨語言，跨平台，有着更為通用的應用場景。
DRDS 兼容 MySQL 協議和語法，支持分庫分表、平滑擴容、服務升降配、透明讀寫分離和分布式事務等特性，具備分布式數據庫全生命周期的運維管控能力。可以看成mycat的商業化產品，也就是mycat所有的優點它都有，而且作為一個商業化產品使用上更為簡單透明，功能也更為豐富；如果不差錢而且正准備對數據做重構，那么drds是一個不錯的選擇，之所以說准備做數據重構時考慮用drds，是因為drds不是一個簡單的做sharding路由，即使原來使用的是rds，也無法通過drds做路由，唯一的辦法新建drds實例，定義路由規則（drds支持二維路由），導入歷史數據，然后就可以開心的使用drds了。
然后做個簡單總結
————————————————
版權聲明：本文為CSDN博主「jornada_」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/jornada_/article/details/82947677