大规模MySQL运维陷阱之基于MyCat的伪分布式架构
引子
分布式数据库，已经进入了全面快速发展阶段，这种发展，是与时俱进的，与人的需求是分不开的，因为现在信息时代的高速发展，导致数据量和交易量越来越大。这种现象首先导致的就是存储瓶颈，因为MySQL数据库，实质上，还是一个单机版本的数据库，而只要是单机，就必然会遇到的一个问题就是存储问题，因为存储是硬需求，而CPU和内存如果不够的话，只是性能不好，并不会直接否定方案或者架构。
成都创新互联是一家专业提供耒阳企业网站建设,专注与做网站、网站设计、H5开发、小程序制作等业务。10年已为耒阳众多企业、政府机构等服务。创新互联专业的建站公司优惠进行中。
存储问题的解决，其实我们每一家公司或者个人，都一直在努力着。解决方案大概有 三个方面 ：
增大磁盘
这种方式，应该是最直接，最简单的方案了，因为磁盘空间不足了，当然加磁盘是手到病除，比如现在是800G，可以增加到2T，这是没问题的，如果现在已经达到了2T，当然，还是可以增加到5T的盘，但实际上，这个时候可能DBA就要捏把汗了，这么大数据量的MySQL实例，如何运维？如果数据坏了，如何恢复呢？时间成本呢？5T的数据量，已经非常吓人了，估计在业内各大公司，没有DBA想要自己运维的MySQL实例达到这个量级吧？其实我个人认为，这个已经是不能接受的量了，最合适的最好保持在1T以下即可。超过这个就要想办法了。当然这个数据量不宜达到这个大小的原因，可能会有人考虑到这是性能的问题，其实不然，或者性能问题很小，因为InnoDB采用的是B+树的存储方案，小表最坏情况下没有查到数据是要找3层，也就是3个页面的IO，而大表需要的是4个页面的IO，影响不大。数据压缩
为了减少数据对磁盘空间的占用，我们通常也会将数据做压缩处理，通过一个语句即可搞定，是InnoDB原生支持的一种方式，一般情况下，会将数据占用减少到原来的三分之一到一半不等，效果还是足够明显的，不过这样处理之后的数据，在性能上会有所下降，对于响应要求比较高的业务，可能需要谨慎考虑一下，但这种方式，可能还是治标不治本，在数据量继续增长的情况下，过段时间之后，依然面临相同的问题，这种情况下，就不能继续使用这种方式来实现了。数据分片
数据分片的解决方案，现在业内也用得很多，这种方案已经超出了MySQL本身，包括HBase、redis等也都在使用这种方案，应该说这种方案是最具扩展性的，并且可以称得上是无限扩展，而上面两种方案，根本谈不上扩展性。所以这种方案在业内成为主流，并且这种方案才能称得上是分布式存储，具体的实现也层出不穷，当然也存在优秀的分布式解决方案，也存在一些“伪”分布式方案了。
分布式解决方案需求
扩展性
使用分布式，其实最主要的就是扩展性，如果空间不足了，可以很方便容易的扩展节点个数，并且将数据做新的平衡处理。这个过程要不影响业务使用，对业务透明。支持事务
分布式数据库，对于业务本身，使用方面与单机区别不大，也就是对业务透明，因为使用MySQL是支持事务的，那么MySQL变身为分布式之后，事务特性还是不能少的，所以整体上看来，还是要支持分布式事务。SQL语句无限制
业务需求的多样性，导致在SQL需求上面，都是比较广泛的，针对业务的透明性，如果某些SQL语句不支持，那这样导致的问题是，一方面，限制了业务程序的功能和性能，另一方面，导致业务程序与“分布式数据库”的捆绑问题。性能足够好
使用分布式数据库，其实基本上是对性能的要求比较低的业务才会这样选择，即使是这样，还是性能越高，越多人才会选择这样的分布式数据库。元数据变更透明性
元数据变更，在任何数据库中都是存在的，在单点情况下，改表操作我们有多种友好的方法来实现，但到了分布式环境下，可能这种操作就成为了问题，因为数据的分片导致了元数据的变更需要多点修改，进而很多问题就来了，比如原子性、数据可见性、正确性等等，所以这是最基本的问题。底层数据库的高可用性
话说经济基础决定上层建筑，在分布式数据库中也是一样的，如果底层数据库的不稳定，或者数据复制延迟，亦或出现数据不一致的问题，则上层应用的访问正确性就没法保证，所以底层数据库最基本的就是保证数据一致性（高可用）。
流行分布式数据库解决方案
中间件分库分表（伪分布式）
在MySQL界，一个存在很久的话题，就是：哪个中间件实现的分库分表方案比较好啊？
当然对于同一个问题，不同人有不同的理解，也都具有两面性的特征，有人说好，也有人说不好，我们首先看一下这种方案是如何实现的。
竟然是一个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://shouzuofang.com/article/jgedhi.html