分库分表-中间件对比
客户端架构
- 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 来说，年轻一些，经历的锤炼少一些。