分庫分表-中間件對比
客戶端架構
- good：
1、客戶端直連數據庫，降低依賴風險
2、集成成本低，無需額外運維的組件
3、沒有proxy的lvs的單點問題 - bad
1、擴展性一般
2、分片邏輯的壓力在客戶端
代理架構
- good：
1、統一管理所有到數據庫的連接，連接復用
2、基礎查詢功能抽象，減少代碼耦合
3、易於實現監控、數據遷移、連接管理等功能 - bad
1、獨立部署和運維獨立的代理中間件
2、代理連接數據庫、性能有損失或額外風險
| 類型 | 作者 | 分庫 | 分表 | 讀寫分離 | 依賴 | 是否開源 | 語言 | 源碼庫 | |
|---|---|---|---|---|---|---|---|---|---|
| shardingsphere | lib | 當當 | 是 | 是 | 是 | 無 | 是 | java | https://github.com/apache/incubator-shardingsphere |
| kingshard | proxy | 個人 | 是 | 是 | 是 | 無 | 是 | Go | https://github.com/flike/kingshard |
| heisenberg | proxy | 百度-熊照 | 是 | 是 | 是 | 無 | 是 | java | https://github.com/brucexx/heisenberg |
| DRDS | proxy | 阿里雲 | 是 | 是 | 是 | 無 | 否 | java | ------ |
shardingsphere：目前加入apache孵化器，個人感覺lib類是最優選擇（支持度較高、代碼優美、集成簡單）
kingshard：proxy類綜合度較高，目前開發社區較活躍
DRDS：阿里雲提共的解決方案，雲上服務優先選擇（運維、集成、支持度較高）
heisenberg：百度-熊照開源，改編自cobar, 結合了cobar和TDDL的優勢，讓其分片策略變為分庫表策略。連接nio優化。
這里只整理了個人覺得較合適的中間件對比，僅代表個人觀點。
_______________________________________________________________________________________________________________________________________________
常見的分庫分表中間件
比較常見的包括：
cobar
TDDL
atlas
sharding-jdbc
mycat
cobar
阿里 b2b 團隊開發和開源的，屬於 proxy 層方案，就是介於應用服務器和數據庫服務器之間。應用程序通過 JDBC 驅動訪問 cobar 集群，cobar 根據 SQL 和分庫規則對 SQL 做分解，然后分發到 MySQL 集群不同的數據庫實例上執行。早些年還可以用，但是最近幾年都沒更新了，基本沒啥人用，差不多算是被拋棄的狀態吧。而且不支持讀寫分離、存儲過程、跨庫 join 和分頁等操作。
TDDL
淘寶團隊開發的，屬於 client 層方案。支持基本的 crud 語法和讀寫分離，但不支持 join、多表查詢等語法。目前使用的也不多，因為還依賴淘寶的 diamond 配置管理系統。
atlas
360 開源的，屬於 proxy 層方案，以前是有一些公司在用的，但是確實有一個很大的問題就是社區最新的維護都在 5 年前了。所以，現在用的公司基本也很少了。
sharding-jdbc
當當開源的，屬於 client 層方案。確實之前用的還比較多一些，因為 SQL 語法支持也比較多，沒有太多限制，而且目前推出到了 2.0 版本，支持分庫分表、讀寫分離、分布式 id 生成、柔性事務（最大努力送達型事務、TCC 事務）。而且確實之前使用的公司會比較多一些（這個在官網有登記使用的公司，可以看到從 2017 年一直到現在，是有不少公司在用的），目前社區也還一直在開發和維護，還算是比較活躍，個人認為算是一個現在也可以選擇的方案。
mycat
基於 cobar 改造的，屬於 proxy 層方案，支持的功能非常完善，而且目前應該是非常火的而且不斷流行的數據庫中間件，社區很活躍，也有一些公司開始在用了。但是確實相比於 sharding jdbc 來說，年輕一些，經歷的錘煉少一些。