MySQL八大集群架构的优点和缺点总结

本篇内容介绍了“MySQL八大集群架构的优点和缺点总结”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

很多开发者可能都没有接触过 MySQL 的架构部署，但是大多数应该都听过集群架构吧。其实 MySQL 集群架构，总结来说一共有好多种，今天我主要总结一下其中常用的 8 种集群架构。

主从架构一般说的是，读写分离这种。他的好处是，数据可以有备份。并且，在一定程度上缓解了读和写的效率。从而提高数据库系统的可用性。

主从架构有一个特点就是，如果有一个故障，那么高可用就无法谈起。所以，有的公司便采用这种主主互备的架构来解决突发的单点故障带来的影响。这种架构的特点是，MySQL 双主复制，即互为 Master-Slave (只有一个 Master 提供写操作)，可以实现数据库服务器的热备，但是一个 Master 宕机后不能实现动态切换。使用 Keepalived，可以通过虚拟 IP，实现双主对外的统一接口以及自动检查、失败切换机制，从而实现 MySQL 数据库的高可用方案。

这种架构比上面的主主互备 + keepalived 模式，性能更好一些。读写分离等都是可以实现的。

对比上面的一种架构，每个主库上都加一个从库，太浪费了，包括 IO 等都有不小的影响。如果把从库都挂到一个主库上，那么效率就会更高一些。

MMM（Master-Master replication manager for MySQL）是一套支持双主故障切换和双主日常管理的脚本程序。MMM 使用 Perl 语言开发，基于 mysql 主从复制，成熟高可用集群方案，由一个管理端(monitor)和多个代理端（aget）构成。

这种架构优点：监控所有 Master 节点及 Slave 节点状态，当 master 节点出现故障，会把 vip 自动转移到健康节点上；更重要的是当 Master 节点发生故障，会自动将后端 Slave 节点转向备用的 Master 节点继续同步复制，切换过程不需要人工干预；

缺点：对 ip，服务器数量有要求(至少两台服务器，2个真实 ip，3 个 vip)；业务繁忙，数据量大的时候不是很稳定，会出现复制延时，切换失效等问题；所以 MMM 方案不适合应用于对数据安全性要求很高，并读写频繁的环境中。数据量大的时候，会有主从数据不同步的问题。

MHA（Master High Availability）目前在 MySQL 高可用方面是一个相对成熟的解决方案，它由日本 DeNA 公司 youshimaton（现就职于 Facebook 公司）开发，是一套优秀的作为 MySQL 高可用性环境下故障切换和主从提升的高可用软件。在 MySQL 故障切换过程中，MHA 能做到在 0~30 秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA 能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

这种架构搭建起来比较麻烦，至少三台机器，淘宝进行过二次开发，可以用两台机器。

MySQL Proxy 有一项强大功能是实现“读写分离”，基本原理是让主数据库处理写方面事务，让从库处理 SELECT 查询。

通过 lua 脚本实现的读写分离，官网不建议用。由于加入了一层 proxy 会导致网络请求的增加消耗，所以性能造成一定的影响。

Amoeba for MySQL是一款优秀的中间件软件，同样可以实现读写分离，负载均衡等功能，并且稳定性也高于 MySQL Proxy。

Amoeba(变形虫)项目，专注 分布式数据库 proxy 开发。座落与 Client、DB Server(s) 之间。对客户端透明。具有负载均衡、高可用性、sql 过滤、读写分离、可路由相关的 query 到目标数据库、可并发请求多台数据库合并结果。

它的特点：降低数据切分带来的复杂多数据库结构；提供切分规则并降低，数据切分规则，给应用带来的影响；降低 db 与客户端的连接数；读写分离。

Amoeba 致力于 mysql 分布式数据库前端代理层，它主要在应用层，访问 mysql 的时候充当 SQL 路由器的功能，依据用户事先设置的规则，将 SQL 请求发送到特定的数据库上执行。基于此可以实现负载均衡、读写分离、高可用性等需求。Amoeba 相当于一个 SQL 请求的路由器，目的是为负载均衡、读写分离、高可用性提供机制，而不是完全实现它们。

“MySQL八大集群架构的优点和缺点总结”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！