MySQL集解决⽅案
**
1：mysql数据分库分表，读写分离，主从切换使⽤mycat
2：集⽅案(分布式+集)
**
分布式：不同的服务器部署不同的模块/⼯程，他们之间通过RPC/Rmi通信和调⽤，对外提供服务和组内协作
集：不同的服务器部署相同的模块/⼯程，他们之间通过分布式调动软件进⾏统⼀调度，对外提供服务和访问
多图⽂，详细介绍mysql各个集⽅案
⼀，mysql原⼚出品
1，MySQL Replication
2，MySQL Fabirc
3，MySQL Cluster
⼆，mysql第三⽅优化
4，MMM
5，MHA
6，Galera Cluster
三，依托硬件配合
7，heartbeat+SAN
8，heartbeat+DRDB
四，其它
9，Zookeeper + proxy
10，Paxos
mysql第三⽅优化
2.1，MMM
MMM是在MySQL Replication的基础上，对其进⾏优化。
MMM（Master Replication Manager for MySQL）是双主多从结构，这是Google的开源项⽬，使⽤Perl语⾔来对MySQL Replication做扩展，提供⼀套⽀持双主故障切换和双主⽇常管理的脚本程序，主要⽤来监控mysql主主复制并做失败转移。
MMM_lgx211
注意：这⾥的双主节点，虽然叫做双主复制，但是业务上同⼀时刻只允许对⼀个主进⾏写⼊，另⼀台备选主上提供部分读服务，以加速在主主切换时刻备选主的预热。
就各个集⽅案来说，其优势为：
⾃动的主主Failover切换，⼀般3s以内切换备机。
多个从节点读的负载均衡。
其劣势为：
⽆法完全保证数据的⼀致性。如主1挂了，MMM monitor已经切换到主2上来了，⽽若此时双主复制中，主2数据落后于主1（即还未完全复制完毕），那么此时的主2已经成为主节点，对外提供写服务，从⽽导致数据不⼀。
由于是使⽤虚拟IP浮动技术，类似Keepalived，故RIP（真实IP）要和VIP（虚拟IP）在同⼀⽹段。如果是在不同⽹段也可以，需要⽤到虚拟路由技术。但是绝对要在同⼀个IDC机房，不可跨IDC机房组建集。
2.2，MHA
MHA是在MySQL Replication的基础上，对其进⾏优化。
MHA（Master High Availability）是多主多从结构，这是⽇本DeNA公司的youshimaton开发，主要提供更多的主节点，但是缺少
VIP（虚拟IP），需要配合keepalived等⼀起使⽤。
要搭建MHA，要求⼀个复制集中必须最少有三台数据库服务器，⼀主⼆从，即⼀台充当master，⼀台充当备⽤master，另外⼀台充当从库。
MHA_lgx211
就各个集⽅案来说，其优势为：
可以进⾏故障的⾃动检测和转移
具备⾃动数据补偿能⼒，在主库异常崩溃时能够最⼤程度的保证数据的⼀致性。
其劣势为：
MHA架构实现读写分离，最佳实践是在应⽤开发设计时提前规划读写分离事宜，在使⽤时设置两个连接池，即读连接池与写连接池，也可以选择折中⽅案即引⼊SQL Proxy。但⽆论如何都需要改动代码；
关于读负载均衡可以使⽤F5、LVS、HAPROXY或者SQL Proxy等⼯具，只要能实现负载均衡、故障检查及备升级为主后的读写剥离功能即可，建议使⽤LVS
2.3，Galera Cluster
Galera Cluster是由Codership开发的MySQL多主结构集，这些主节点互为其它节点的从节点。不同于MySQL原⽣的主从异步复
制，Galera采⽤的是多主同步复制，并针对同步复制过程中，会⼤概率出现的事务冲突和死锁进⾏优化，就是复制不基于官⽅binlog⽽是Galera复制插件，重写了wsrep api。
异步复制中，主库将数据更新传播给从库后⽴即提交事务，⽽不论从库是否成功读取或重放数据变化。这种情况下，在主库事务提交后的短时间内，主从库数据并不⼀致。
同步复制时，主库的单个更新事务需要在所有从库上同步 更新。换句话说，当主库提交事务时，集中所有节点的数据保持⼀致。
对于读操作，从每个节点读取到的数据都是相同的。对于写操作，当数据写⼊某⼀节点后，集会将其同步到其它节点。
MHA_lgx211
就各个集⽅案来说，其优势为：
多主多活下，可对任⼀节点进⾏读写操作，就算某个节点挂了，也不影响其它的节点的读写，都不需要做故障切换操作，也不会中断整个集对外提供的服务。
拓展性优秀，新增节点会⾃动拉取在线节点的数据（当有新节点加⼊时，集会选择出⼀个Donor Node为新节点提供数据），最终集所有节点数据⼀致，⽽不需要⼿动备份恢复。
其劣势为：
能做到数据的强⼀致性，毫⽆疑问，也是以牺牲性能为代价。
3：mysq5.7已经⽀持分布式事务
4：分布式id⽣成
2.2 Mycat ⾼可⽤⽅案
Mycat 作为⼀个代理层中间件，Mycat 系统的⾼可⽤涉及到 Mycat 本⾝的⾼可⽤以及后端 MySQL 的⾼可⽤，
mongodb和mysql结合前⾯章节所讲的 MySQL ⾼可⽤⽅案都可以在此⽤来确保 Mycat 所连接的后端 MySQL 服务的⾼可⽤性。在⼤多
数情况下，建议采⽤标准的 MySQL 主从复制⾼可⽤性配置并交付给 Mycat 来完成后端 MySQL 节点的主从⾃动
切换。
mycat的三⼤功能：分库分表、读写分离、主从切换
Mycat关键特性
关键特性
⽀持SQL92标准
⽀持MySQL、Oracle、DB2、SQL Server、PostgreSQL等DB的常见SQL语法
遵守Mysql原⽣协议，跨语⾔，跨平台，跨数据库的通⽤中间件代理。
基于⼼跳的⾃动故障切换，⽀持读写分离，⽀持MySQL主从，以及galera cluster集。
⽀持Galera for MySQL集，Percona Cluster或者MariaDB cluster
基于Nio实现，有效管理线程，解决⾼并发问题。
⽀持数据的多⽚⾃动路由与聚合，⽀持sum,count,max等常⽤的聚合函数,⽀持跨库分页。
⽀持单库内部任意join，⽀持跨库2表join，甚⾄基于caltlet的多表join。
⽀持通过全局表，ER关系的分⽚策略，实现了⾼效的多表join查询。
⽀持多租户⽅案。
⽀持分布式事务（弱xa）。
⽀持XA分布式事务（1.6.5）。
⽀持全局序列号，解决分布式下的主键⽣成问题。
分⽚规则丰富，插件化开发，易于扩展。
强⼤的web，命令⾏监控。
⽀持前端作为MySQL通⽤代理，后端JDBC⽅式⽀持Oracle、DB2、SQL Server 、 mongodb 、巨杉。
⽀持密码加密
⽀持服务降级
⽀持IP⽩名单
⽀持SQL⿊名单、sql注⼊攻击拦截
⽀持prepare预编译指令（1.6）
⽀持⾮堆内存(Direct Memory)聚合计算（1.6）
⽀持PostgreSQL的native协议（1.6）
⽀持mysql和oracle存储过程，out参数、多结果集返回（1.6）
⽀持zookeeper协调主从切换、zk序列、配置zk化（1.6）
⽀持库内分表（1.6）
集基于ZooKeeper管理，在线升级，扩容，智能优化，⼤数据处理（2.0开发版）。
什么是MYCAT
⼀个彻底开源的，⾯向企业应⽤开发的⼤数据库集
⽀持事务、ACID、可以替代MySQL的加强版数据库
⼀个可以视为MySQL集的企业级数据库，⽤来替代昂贵的Oracle集
⼀个融合内存缓存技术、NoSQL技术、HDFS⼤数据的新型SQL Server
结合传统数据库和新型分布式数据仓库的新⼀代企业级数据库产品
⼀个新颖的数据库中间件产品
MYCAT监控
⽀持对Mycat、Mysql性能监控
⽀持对Mycat的JVM内存提供监控服务
⽀持对线程的监控
⽀持对操作系统的CPU、内存、磁盘、⽹络的监控
⽬标
低成本的将现有的单机数据库和应⽤平滑迁移到“云”端，解决数据存储和业务规模迅速增长情况下的数据瓶颈问题。
1.6版本架构
长期规划2.0
完全实现分布式事务，完全的⽀持分布式。
通过Mycat web（eye）完成可视化配置，及智能监控，⾃动运维。
通过mysql 本地节点，完整的解决数据扩容难度，实现⾃动扩容机制，解决扩容难点。
⽀持基于zookeeper的主从切换及Mycat集化管理。
通过Mycat Balance 替代第三⽅的Haproxy，LVS等第三⽅⾼可⽤，完整的兼容Mycat集节点的动态上下线。
接⼊Spark等第三⽅⼯具，解决数据分析及⼤数据聚合的业务场景。
通过Mycat智能优化，分析分⽚热点，提供合理的分⽚建议，索引建议，及数据切分实时业务建议。
优势
基于阿⾥开源的Cobar产品⽽研发，Cobar的稳定性、可靠性、优秀的架构和性能以及众多成熟的使⽤案例使得MYCAT⼀开始就拥有⼀个很好的起点，站在巨⼈的肩膀上，我们能看到更远。业界优秀的开源项⽬和创新思路被⼴泛融⼊到MYCAT的基因中，使得MYCAT在很多⽅⾯都领先于⽬前其他⼀些同类的开源项⽬，甚⾄超越某些商业产品。
MYCAT背后有⼀⽀强⼤的技术团队，其参与者都是5年以上软件⼯程师、架构师、DBA等，优秀的技术团队保证了MYCAT的产品质量。
MYCAT并不依托于任何⼀个商业公司，因此不像某些开源项⽬，将⼀些重要的特性封闭在其商业产品中，使得开源项⽬成了⼀个摆设。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。