189 8069 5689

大规模MySQL运维陷阱之基于MyCat的伪分布式架构

引子

分布式数据库,已经进入了全面快速发展阶段,这种发展,是与时俱进的,与人的需求是分不开的,因为现在信息时代的高速发展,导致数据量和交易量越来越大。这种现象首先导致的就是存储瓶颈,因为MySQL数据库,实质上,还是一个单机版本的数据库,而只要是单机,就必然会遇到的一个问题就是存储问题,因为存储是硬需求,而CPU和内存如果不够的话,只是性能不好,并不会直接否定方案或者架构。

成都创新互联是一家专业提供耒阳企业网站建设,专注与做网站、网站设计H5开发、小程序制作等业务。10年已为耒阳众多企业、政府机构等服务。创新互联专业的建站公司优惠进行中。

存储问题的解决,其实我们每一家公司或者个人,都一直在努力着。解决方案大概有 三个方面

  1. 增大磁盘
    这种方式,应该是最直接,最简单的方案了,因为磁盘空间不足了,当然加磁盘是手到病除,比如现在是800G,可以增加到2T,这是没问题的,如果现在已经达到了2T,当然,还是可以增加到5T的盘,但实际上,这个时候可能DBA就要捏把汗了,这么大数据量的MySQL实例,如何运维?如果数据坏了,如何恢复呢?时间成本呢?5T的数据量,已经非常吓人了,估计在业内各大公司,没有DBA想要自己运维的MySQL实例达到这个量级吧?其实我个人认为,这个已经是不能接受的量了,最合适的最好保持在1T以下即可。超过这个就要想办法了。当然这个数据量不宜达到这个大小的原因,可能会有人考虑到这是性能的问题,其实不然,或者性能问题很小,因为InnoDB采用的是B+树的存储方案,小表最坏情况下没有查到数据是要找3层,也就是3个页面的IO,而大表需要的是4个页面的IO,影响不大。

  2. 数据压缩
    为了减少数据对磁盘空间的占用,我们通常也会将数据做压缩处理,通过一个语句即可搞定,是InnoDB原生支持的一种方式,一般情况下,会将数据占用减少到原来的三分之一到一半不等,效果还是足够明显的,不过这样处理之后的数据,在性能上会有所下降,对于响应要求比较高的业务,可能需要谨慎考虑一下,但这种方式,可能还是治标不治本,在数据量继续增长的情况下,过段时间之后,依然面临相同的问题,这种情况下,就不能继续使用这种方式来实现了。

  3. 数据分片
    数据分片的解决方案,现在业内也用得很多,这种方案已经超出了MySQL本身,包括HBase、redis等也都在使用这种方案,应该说这种方案是最具扩展性的,并且可以称得上是无限扩展,而上面两种方案,根本谈不上扩展性。所以这种方案在业内成为主流,并且这种方案才能称得上是分布式存储,具体的实现也层出不穷,当然也存在优秀的分布式解决方案,也存在一些“伪”分布式方案了。

分布式解决方案需求

  • 扩展性
    使用分布式,其实最主要的就是扩展性,如果空间不足了,可以很方便容易的扩展节点个数,并且将数据做新的平衡处理。这个过程要不影响业务使用,对业务透明。

  • 支持事务
    分布式数据库,对于业务本身,使用方面与单机区别不大,也就是对业务透明,因为使用MySQL是支持事务的,那么MySQL变身为分布式之后,事务特性还是不能少的,所以整体上看来,还是要支持分布式事务。

  • SQL语句无限制
    业务需求的多样性,导致在SQL需求上面,都是比较广泛的,针对业务的透明性,如果某些SQL语句不支持,那这样导致的问题是,一方面,限制了业务程序的功能和性能,另一方面,导致业务程序与“分布式数据库”的捆绑问题。

  • 性能足够好
    使用分布式数据库,其实基本上是对性能的要求比较低的业务才会这样选择,即使是这样,还是性能越高,越多人才会选择这样的分布式数据库。

  • 元数据变更透明性
    元数据变更,在任何数据库中都是存在的,在单点情况下,改表操作我们有多种友好的方法来实现,但到了分布式环境下,可能这种操作就成为了问题,因为数据的分片导致了元数据的变更需要多点修改,进而很多问题就来了,比如原子性、数据可见性、正确性等等,所以这是最基本的问题。

  • 底层数据库的高可用性
    话说经济基础决定上层建筑,在分布式数据库中也是一样的,如果底层数据库的不稳定,或者数据复制延迟,亦或出现数据不一致的问题,则上层应用的访问正确性就没法保证,所以底层数据库最基本的就是保证数据一致性(高可用)。

流行分布式数据库解决方案

  • 中间件分库分表(伪分布式)

在MySQL界,一个存在很久的话题,就是:哪个中间件实现的分库分表方案比较好啊?
当然对于同一个问题,不同人有不同的理解,也都具有两面性的特征,有人说好,也有人说不好,我们首先看一下这种方案是如何实现的。

大规模MySQL运维陷阱之基于MyCat的伪分布式架构

竟然是一个XML文件,这个产品经理当时是如何想的?后面也没有想着做个优化?

最后一个问题,现在做分库分表做得好的有哪些?

还有哪些?一个都没有,这是一条不归路啊。因为说白了,他是一种伪分布式方案,基础是不好的,上层就做不好,所以永远是在补各种坑,走得很累,累人累己。现在可以回过头来想一想,为什么一些很强大知名的公司做的中间件产品,并没有做这些事情,比如ProxySQL、Maxscale、MySQL Router等,为什么呢?难道他们的技术不好?或者是没有这样的需求?我还是觉得,需求是有的,人与人、业务与业务的需求,是一样的,但解决方法可能就不一样了,他们可能早就认为,这是一条错误的道路,所以就不会去选择走,而MyCat这种方案,可能就要回过头来想想未来的路了。

  • 互联网处理大规模在线访问数据的做法

解耦思想充斥着互联网技术栈的方方面面,为什么这样做?我想应该是大家都不想拖泥带水,也不想牵一发而动全身罢了。而在MySQL数据库层面,使用了重量级的中间层之后,你会发现,大一统看起来是很不错,但这样牵一发很可能动全身,这其实并不是好事情。

MySQL这种数据库是在互联网领域兴起并被大规模使用的,在比如账务、订单、计费等等关键业务上使用的也不在少数。在大型互联网公司,MySQL的使用一定是分库分表的,通过各种垂直切分和水平切分,把一个数据库变成一堆数据库,也就是所说的数据库集群。但是很少看到在使用的MySQL的时候会在上面架设一层重量级的所谓分布式的中间层,这样导致的就是紧耦合了,与互联网的高效联运相违背,互联网的数据库集群都应该是物理上离散的,每一个实例可以自由的控制和迁移,也就是所谓的解耦。

解耦的好处可以让你自由处理每一个独立的实例或者集群,方便根据实际情况应对业务带来的变数,该升级的升级,该缩容的缩容,为每一个业务或者每一个业务的数据库定义不同的维护等级,灵活掌握,随机而变。

解耦的好处可以提升数据库的绝对性能,数据从业务到磁盘,或者从磁盘到业务,经历的路径越短,其效率也就越高。很多使用MySQL的做法就是用一个简单的中间层分发SQL,这样的中间层功能清晰、结构简单、灵活高效,一般不会损失太多性能,这就像MySQL出品的MySQL Router,MariaDB出品的Maxscale,Percona的ProxySQL,还有国内的正火的极数云舟的Arkproxy,他们的行为,都为选择使用中间层去实现数据架构指明了一个方向。

解耦的好处可以让你的数据库只干数据库最擅长的事情,它能保证你的数据安全存储,它能保证你的数据高效存取,它能保证你数据并发处理,它能保证你的数据灵活接入,这还不够吗?

综上所述,我们再次确信一个真理,MySQL因简单而高效,因高效而流行,不要舍本逐末,听信忽悠,误入歧途。

当然如果不想在业务层做分库分表来适配MySQL数据库的架构,而想通过对业务透明的分布式数据库来提供业务服务的话,我推荐真正意义的分布式数据库解决方案,他能解决的是强大的存储扩展能力、分布式运算、对业务读写透明以及友好的故障转移等问题,这是他们的优势,也是他们的初衷。

  • 真正意义的分布式解决方案

真分布式方案,其实已经不用太多说了,达到上面所述的需求即可。并且目前也有比较成熟的方案,比较有代表性的产品有Google的Spanner&F1、以及国产数据库SequoiaDB、TiDB等等。关于巨杉数据库,之前写了一篇文章,有兴趣的同学可以看看《【原创首发】兼容MySQL的开源分布式数据库SequoiaDB在去哪儿网的实践》

对比之下,这种分布式数据库对业务无侵入,MySQL数据实现了云存储特征,100%兼容MySQL,扩展性非常好,天然支持分布式事务、数据节点及路由节点延迟非常小,通过一致性算法来保证了数据的强一致性,如此种种,都是立足于一个正确的基点之上,来建立起高楼大厦,势必将基于MyCat的伪分布式数据库解决方案推入无人问津的深渊,直至淘汰与消亡。

总结

使用MyCat的用户其实还是挺多的,现在在了解业界市场的情况下,我也是比较能理解他们,因为需求有,但真的是没有解决方案,选择使用,实则无奈之举,毕竟他是开源的,骂归骂,也无怨言,因为免费嘛,有的用还有什么可言语的呢?我也推荐大家去试用一下,只有知道痛了,才会感觉现在有新的方案出现的美好。

本文所述的关于MyCat的一系列问题,主要目的是考虑到为了让业内同学不要继续采坑,所以做了一些总结,所述内容限于本人目前对MyCat的理解与认识,如果有纰漏或者不足的地方,欢迎私信指正或者给予补充,感谢。

【作者介绍】

王竹峰:去哪儿网数据库总监,中国计算机行业协会开源数据库专业委员会常务理事。擅长数据库开发、数据库管理及维护,一直致力于MySQL数据库源码的研究与探索,对数据库原理及实现有深刻的理解。曾就职于达梦数据库,从事多年数据库内核开发工作,后转战人人网,任职高级数据库工程师,目前在去哪儿网负责MySQL源码研究与运维、数据库管理和自动化运维平台设计开发及实践工作,是Inception开源项目及《MySQL运维内参》的作者,也是国内少数几个MySQL方向的Oracle ACE之一。


分享名称:大规模MySQL运维陷阱之基于MyCat的伪分布式架构
文章地址:http://cdxtjz.com/article/jgedhi.html

其他资讯