mysql数据库中间件研究

随着互联网的发展，数据量的不断增大。 单台实例已经远远无法满足业务的需要。 对数据库分库分表的需求不断的增加随之而来的就是数据库中间件的开发。

一、 单台实例主要面临下面几个问题：

1.  数据量太大单台机器无法承载

2.  数据查询效率太低，单表数据达到一定的量业务性能就无法满足

3.  数据库优化上的瓶颈

4. 数据安全的问题，大量数据放置在一台机器如果数据出问题回复周期会特别长，对业务影响太大。

随之而来的就是需要分库分表

但是分库分表就四个字做起来可真没有这么简单。

二、 分库分表面临的问题

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

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

3.  join，这个更难

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

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

6.  ....等等很多问题

碰到这么多问题总得解决， 这些问题可以慢慢的一个一个解决，数据库中间件不需要对所有的功能都支持， 对于一个公司而来完全可以业务导向；

我业务需要哪些功能我提供那些功能就可以。

三、 数据库中间件开源实现

下面简单说说当前市面上的数据库中间件， 具体能不能用到自己的项目上需要自己去调研。 能不能落地也是需要走业务导向，目前我们使用cobar二次开发的（现在已经完全不同了）数据库中间件已经在公司（jd）内部落地，而且可以很好的支撑海量数据的分库分表需求。

目前知道的开源实现有以下几种：

Atlas，cobar，TDDL，mycat，heisenberg, Oceanus, vitess

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

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

Vitess 
　　Vitess是 Youtube开源的数据库扩展及高可用方案，已经用于生产环境，功能强大，但是构架复杂，部署及运维成本较高
　　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之间两次数据转发都要走网络，如果网络不够稳定可以预见性能损失较大