mysql中间件研究（ Atlas，cobar，TDDL，mycat，heisenberg,Oceanus,vitess ）

原文来自 http://www.gpfeng.com/?p=657&utm_source=tuicool

写在前面

14年中换了一份工作，出国游荡了一阵子，目前工作离数据库内核远了点，离业务近了些，业务层面碰到的‘高深’技术问题也少了，旅行后发现人也懒了不少，导致博客都长草了

2015开始了，先表态一下目标： 我2015年的目标就是搞定2014年那些原定于2013年完成的安排，不为别的，只为兑现我2012年时要完成的2011年年度计划的诺言

2015-goal
问题背景

工作中遇到数据库数据增长过快，单表一年之后预计到达35M行数据，可以预见MySQL性能将下降厉害，并且随着业务的规模化，担心单表将很难抗住并发压力，出现故障后恢复时间变长对业务影响也会变大，因此需要考虑数据水平扩展，目前项目采用Golang开发，一个Google开发的以简洁的语法，内建高并发模型，支持垃圾回收为主要特点的编译型语言，性能比Java好，开发效率比C/C++高，其目标是替代C/C++
分库分表

这四个字在阿里听得最多，其实这也是被问题和压力推动的，毕竟要支撑起那么大的业务，等着Oracle这样的公司提供解决方案是不靠谱的，还不如卷起袖子自己干，接着就陆续搞出并开源了Cobar，TDDL（不给出链接了，太容易搜到）这些数据库中间件，Cobar应该在TDDL之前，这个东西采用proxy方式，性能肯定不如以后续jdbc层面实现的TDDL，毕竟少了一次网络转发，现在TDDL在阿里核心系统上大量使用，不过外部用户想用起来这个没有那么容易，首先语言限制在了Java，另外还需要阿里配置管理服务Diamond的支持

要想水平扩展，就需要分库分表的支持，分库分表这四个字说起来很容易，按照id取模将数据打散分摊压力，但是干完这些之后需要解决由此带来的问题，这些很难：

1. 事务支持，扩库/扩表后事务就成分布式的了，问题难度显然上升了一个级别

2. 查询结果合并，这个看起来不难，但是把order by/limit/查询中不带分表字段等加上，要解决的问题还也不少

3. join，这个更难

4. 分库？分表？还是分库分表？这个需要考虑并做一个决定

5. 分完后能否合并？分容易，和很难

6.。。。
开源解决方案

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

db-scale

这些解决方案中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-frame

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

cobar-mysql

Atlas

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

atlas-frame

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

atlas-cmd

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

Vitess

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

vitess

Vitess在app与database之间存在vtgate及vttablet两个server，vttablet实现了MySQL连接池及row cache，与MySQL实例是一对一关系，可以当成是MySQL前端，一般与MySQL部署在一起，所有落到MySQL的query都需要经过vttablet，vtgate是一个proxy，负责路由计算以及app及vttablet之间的数据转发，分表规则及配置数据存放在topology中（zookeeper实现），因此每个query执行需要走的路径较长，虽然vttablet实现的连接池和row cache可以加速query执行速度，但是zookeeper访问，app与vtgage、vtgate与vttablet之间两次数据转发都要走网络，如果网络不够稳定可以预见性能损失较大

通过与vitess开发者确认，vtgate会缓存topology的分表规则数据，因此相对于其他proxy方案，只是多了一层vttablet的转发代价，但是考虑到row cache的加速，最后性能应该相差不大

另外，这个项目是采用Golang语言的，这对于Golang项目优势非常明显，采用本文中Vitess之外的方案， go-sql-driver 无法支持事务，详见 google-group vitess 讨论
总结

本文源于项目实际需求，对国内外开源的MySQL水平扩展方案做了一个简单总结，可以看到国内互联网公司这这方面做得很不错，再次为他们的开源精神点赞