MySQL分库分表方案：Fabric、Cobar、Atlas、Vitess

数据库分库分表开源产品有很多，下图中列出了6个，它们已经在线上承载了较大压力，主要分为2类：代理及非代理，非代理方式是以library方式提供，library负责SQL解析，路由计算等，位于driver层，实现难度较大，一般仅支持少数几种语言；代理方式相当于一个多了一次转发，应用程序连接的是代理服务器，由代理服务器负责路由计算并发送SQL到目的DB，多一次网络，因此在性能上代理方式比非代理方式性能稍低

这些解决方案中MySQL Fabric/TDDL两个为非代理方式，直接提供语言层面的支持，优点是性能会很好，劣势是支持的语言很受限制，TDDL支持支Java，MySQL Faric支持Java/PHP/Python，想实现其他语言支持，相当于再次实现一次，不过目前Java/PHP/Python非常流行，能够覆盖的用户很多了，TDDL对于外部用户来说，先用起来没有那么容易，和阿里平台紧密绑定，如果有时间配置Diamond的话，可以好好研究，这里不进行深入探讨

另外四个全部都是Proxy方式，以部分性能换来灵活性，这个就是仁者见仁智者见智的决定了，值得一提的是BAT中B也实现了一个Heisenberg的中间件，从部分代码、配置以及文件结构来看，这个是从Cobar来的，应该优化了部分特性，不进行赘述，有兴趣可以自己研究

MySQL Fabric

这个是MySQL官方水平扩展方案，号称管理目标为：farm of mysqld，其实我比较看好这个东西，原因是个人喜欢简洁的东西，总感觉Proxy方式多了一层转发带来了麻烦，除了性能外还有复杂性，运维起来也多了不少事情，毕竟这个进程down掉后可用性会受到影响，简单才是美，希望MySQL Fabric能够提供更多语言支持

Cobar

Cobar是阿里的中间件，以Proxy方式提供服务，在阿里内部大量使用，目前已经开源在github了，赞开源精神，据说在很多外部公司有一些成功使用的案例，配置比较容易，不需要依赖其他东西，有Java环境就OK，小试了一把，事务支持比较麻烦，需要通过set autocommit=0来实现，如果想要完美支持的话，还是需要修改JDBC或对应语言的MySQL library，分库示意图（Cobar中d.t分到两个库中：d1.t，d2.t）：

Cobar支持分布式分表，但是不支持单库分多表，前段（对接APP）和后端（对接MySQL）都实现了MySQL客户端协议，比较友好，对于扩表结果集的合并也支持，写其内部的SQL parse工程师功底应该比较深，显示起事务会报错，应该是“BEGIN”或者“Start transaction”不包含分表信息的缘故，但是这个可以通过defer到后面一个包含分表信息的SQL过来一起发到目标库中执行或者通过分布式事务，比如2PC来支持，执行效果：

Atlas

虽然个人对数字公司没啥好感，但是这个Atlas还是非常有特点的，它是基于MySQL-Proxy上二次开发的，主要支持两个特性：分表和读写分离，但是分表的话只支持单库多表，即事实上是不支持分布式分表的，所有分表都在同一个库中，小试了一把，下面是分库示意图（四个分表t_0，t_1，t_2，t_3在同一个库中）：

Atlas扩展性限制在单实例最大性能，但是好处是：事务支持的很好，因为不存在跨库事务，有些事情反而变得简单，读写分离这个东西其实没有水平扩展那么难，毕竟MySQL的备库很好搭，不得不吐槽一下，通过atlas看到的不是一张完整的表，而是各个分表，只能通过分表的字段定位和操作数据，否则会报错，与Cobar对比后，Atlas这个产品其实简洁也粗糙很多，但是的确有它特有的应用场景：

另外，Atlas配置稍微简单一些，但是分表算法支持上相对于Cobar显得并不完善

Vitess

Vitess是Youtube开源的数据库扩展及高可用方案，已经用于生产环境，功能强大，但是构架复杂，部署及运维成本较高，构架图：