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

2022-08-03 16:44:58

字体：大中小

来源：转载

供稿：网友

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

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

增大磁盘
这种方式，应该是最直接，最简单的方案了，因为磁盘空间不足了，当然加磁盘是手到病除，比如现在是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界，一个存在很久的话题，就是：哪个中间件实现的分库分表方案比较好啊？
当然对于同一个问题，不同人有不同的理解，也都具有两面性的特征，有人说好，也有人说不好，我们首先看一下这种方案是如何实现的。
大规模MySQL运维陷阱之基于MyCat的伪分布式架构

MyCat究竟做了什么事情？

作为一个中间层，本职工作应该是接收客户端的SQL请求，然后通过语法分析，根据读写原则，然后确定一个集群中一个读写节点即可，然后就等着结果集的返回，对于结果集本身，中间层并不需要去关心，他只需要将结果集（或者异常）原原本本发回给客户端即可。而MyCat做的事情，远比这个多，在语法分析之后，再做语义分析，拿到对应数据库表结构，同时判断这个表的分发路由规则，再找到语句中的数据及涉及到的列，再决定路由到哪个分片中，如果在分发时路由规则配置错误，或者程序计算错误，会导致整个语句的结果出现不可预知的问题。请问这前半部分，是一个中间层应该做的事情么？竟然还要关心语句中涉及到的表结构，主键，数据等信息，这其实都是数据库要做的事情啊，实则是越俎代庖，再请问，所做的这些事情，能比一个专业数据库做得更好么？咱再看后半部分，等收到结果集之后，MyCat为了处理一些结果集的聚合计算，需要把各个节点本来已经封装好的结果集（二进制MySQL协议流数据），解析出来，然后通过需要计算出来（这个计算有可能非常慢，并且不是所有的都可以搞定），计算完成之后，再打包成MySQL协议流数据，传给客户端，请问这样的中间层，做了这么多事情，性能如何保证？而本身这些聚合计算Order By、Group By的处理，本身是数据库的事情，实则还是越俎代庖。

通过SQL语句的变换，实现分布式是不是有点困难？

MyCat这种中间层，代表了宣称分布式数据库的一类使用方式，但这种实现方法实际上都是通过在SQL语句上做文章，从客户端拿到的是SQL语句，给后端数据库的也是SQL语句，但这两个SQL语句是经过变换的，当然这种方法也只能这样，因为后端数据库只接收SQL语句，试问，一个复杂的SQL语句查询操作，通过SQL变换或重写，就能实现对不同分片数据库的分布式查询？想想就清楚了，虽然SQL语句通用灵活，但可扩展性或者重写的逻辑还是有点复杂的吧？当然了，有人可能会说，我们有兜底的啊，大不了把这个语句就改一下库名表名然后其它保持不变分给每一个节点去执行，这样总没问题吧，是的，你说的没错。

（编辑：错新网）

上一篇：mysql主从配置做到一主一从读写分离

下一篇：Haproxy+Keepalived+MySQL达成读均衡负载