TDDL、Amoeba、Cobar、MyCAT 架构比较

一、文档说明

本文聚焦业界流行的 MySQL 分布式数据库中间件（TDDL、Amoeba、Cobar、MyCAT），重点对比其架构差异，展现中间件的发展与演进路线。网上关于各产品的基础介绍资料较多，本文仅围绕架构核心展开分析。

二、各产品架构及核心特点

1. TDDL

• 定位：非独立中间件，仅为中间层，以 Jar 包形式提供给应用调用，属于 JDBC Shard 思想范畴。
• 架构位置：夹在业务层和 JDBC 中间（纠正网上部分资料将其画在 JDBC 下层的错误定位）。
• 社区状态：处于停滞状态。

2. Amoeba

• 定位：真正的独立中间件，应用连接 Amoeba 操作 MySQL 集群时，体验与操作单个 MySQL 一致。
• 架构特点：属于中间件早期产品，后端依赖 JDBC Driver。
• 社区状态：处于停滞状态。

3. Cobar

• 架构特点：后端去掉 JDBC Driver，不再支持 JDBC 规范，无法适配 Oracle、PostgreSQL 等数据库；采用原生通信协议，支持主备切换、读写分离、异步操作等扩展功能。
• 聚合功能支持：可支持 Order By、Group By、limit 语法，但仅简单返回结果，不做聚合处理，需业务系统自行完成聚合逻辑。
• 社区状态：处于停滞状态。

4. MyCAT

• 发展基础：基于 Cobar 演进而来。

• 核心改进：

  1. 后端由 BIO 改为 NIO，并发量大幅提升；
  2. 完善聚合功能支持，可直接处理 Order By、Group By、limit 等操作（无需业务系统额外处理）。

• 社区状态：非常活跃。

三、关键总结

1. 产品渊源：Amoeba、Cobar、MyCAT 三者渊源较深，均因前序产品停更或核心团队变动而逐步迭代：Amoeba 停更后 Cobar 出现，Cobar 核心团队解散后 MyCAT 另起炉灶。
2. 开源现状：国内开源项目众多，但能持续维护的较少，MyCAT 活跃的社区状态较为难得。
3. 架构演进核心：从依赖 JDBC Driver（Amoeba）→ 原生通信协议（Cobar）→ NIO 优化 + 完善聚合功能（MyCAT），逐步提升扩展性、并发能力和功能完整性。