原文来自 /?p=657&utm_source=tuicool
写在前面
中换了一份工作,出国游荡了一阵子,目前工作离数据库内核远了点,离业务近了些,业务层面碰到的‘高深’技术问题也少了,旅行后发现人也懒了不少,导致博客都长草了
开始了,先表态一下目标: 我的目标就是搞定那些原定于完成的安排,不为别的,只为兑现我时要完成的年度计划的诺言
-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水平扩展方案做了一个简单总结,可以看到国内互联网公司这这方面做得很不错,再次为他们的开源精神点赞