MySQL水平扩展

http://www.gpfeng.com/?p=657

问题背景

工作中遇到数据库数据增长过快,单表一年之后预计到达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,多一次网络,因此在性能上代理方式比非代理方式性能稍低

这些解决方案中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开源的数据库扩展及高可用方案,已经用于生产环境,功能强大,但是构架复杂,部署及运维成本较高,构架图:

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讨论

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,098评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,213评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,960评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,519评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,512评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,533评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,914评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,574评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,804评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,563评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,644评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,350评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,933评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,908评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,146评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,847评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,361评论 2 342

推荐阅读更多精彩内容