113.了解和使用过哪些分库分表中间件？

在将数据库进行分库分表之后，我们一般会引入分库分表的中间件，使之能够达到如下目标。

尽量透明化分库分表所带来的影响，让使用方尽量像使用一个数据库一样使用水平分片之后的数据库集群，这是分库分表的主要设计目标。

? 分库分表的实现方式？

目前，市面上提供的分库分表的中间件，主要有两种实现方式：

? 分库分表中间件？

比较常见的包括：

1）Cobar

阿里 b2b 团队开发和开源的，属于 Proxy 层方案。

早些年还可以用，但是最近几年都没更新了，基本没啥人用，差不多算是被抛弃的状态吧。而且不支持读写分离、存储过程、跨库 join 和分页等操作。

2）MyCAT

基于 Cobar 改造的，属于 Proxy 层方案，支持的功能非常完善，而且目前应该是非常火的而且不断流行的数据库中间件，社区很活跃，也有一些公司开始在用了。但是确实相比于 Sharding Sphere 来说，年轻一些，经历的锤炼少一些。

3）Atlas

360 开源的，属于 Proxy 层方案，以前是有一些公司在用的，但是确实有一个很大的问题就是社区最新的维护都在 5 年前了。所以，现在用的公司基本也很少了。

4）TDDL

淘宝团队开发的，属于 client 层方案。支持基本的 crud 语法和读写分离，但不支持 join、多表查询等语法。目前使用的也不多，因为还依赖淘宝的 diamond 配置管理系统。

5）Sharding Sphere

Sharding Sphere ，可能是目前最好的开源的分库分表解决方案，目前已经进入 Apache 孵化。

Sharding Sphere 提供三种模式：

关于每一种模式的介绍，可以看看《ShardingSphere > 概览》

其中，Sharding-JDBC 属于 client 层方案，被大量互联网公司所采用。例如，当当、京东金融、中国移动等等。

? 如何选择？

综上，现在其实建议考量的，就是 Sharding Sphere ，这个可以满足我们的诉求。

Sharding Sphere 的 Sharding-JDBC 方案，这种 Client 层方案的优点在于不用部署，运维成本低，不需要代理层的二次转发请求，性能很高，但是如果遇到升级啥的需要各个系统都重新升级版本再发布，各个系统都需要耦合 sharding-jdbc 的依赖。

例如阿里、美团内部，更多使用的是 Client 模式。

Sharding Sphere 的 Sharding-Proxy 方案，这种 Proxy 层方案，可以解决我们平时查询数据库的需求。我们只需要连接一个 Sharding-Proxy ，就可以查询分库分表中的数据。另外，如果我们有跨语言的需求，例如 PHP、GO 等，也可以使用它。