大规模MySQL运维陷阱：使用MyCat踩坑篇
|
还有哪些?一个都没有，这是一条不归路啊。因为说白了，他是一种伪分布式方案，基础是不好的，上层就做不好，所以永远是在补各种坑，走得很累，累人累己。现在可以回过头来想一想，为什么一些很强大知名的公司做的中间件产品，并没有做这些事情，比如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的理解与认识，如果有纰漏或者不足的地方，欢迎私信指正或者给予补充，感谢。 【编辑推荐】
点赞 0 （编辑：三明站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |