MySQL 高可用架构在业务层面的分析研究_MySQL

前言：

相对于传统行业的相对服务时间9x9x6或者9x12x5，因为互联网电子商务以及互联网游戏的实时性，所以服务要求7*24小时，业务架构不管是应用还是数据库，都需要容灾互备，在mysql的体系中，最好通过在最开始阶段的数据库架构阶段来实现容灾系统。所以这里从业务宏观角度阐述下mysql架构的方方面面。

一，MySQL架构设计—业务分析

(1)读多写少

虚线表示跨机房部署，比如电子商务系统，一个Master既有读也有些写，对读数据一致性需要比较重要的，读要放在Master上面。

M(R)仅仅是一个备库，只有M(WR)挂了之后，才会切换到M(R)上，这个时候M(R)就变成了读写库。比如游戏系统，有很多Salve会挂载后面一个M(R)上面。

(2)读多写少MMS-电商

如果是电子商务类型的，这种读多写少的，一般是1个master拖上4到6个slave，所有slave挂载在一个master也足够了。

切换的时候，把M1的读写业务切换到M2上面，然后把所有M1上的slave挂到M2上面去，如下所示：

(3)读多写少MMSS-游戏

如果是游戏行业的话，读非常多蛮明显的，会出现一般1个Master都会挂上10个以上的Slave的情况，所以这个时候，可以把一部分Slave挂载新的M(R)上面。至少会减少一些压力，这样至少服务器挂掉的时候，不会对所有的slave有影响，还有一部分在M(R)上的slave在继续，不会对所有的slave 受到影响，见图3，

(4)读少写多

意味着读并不会影响写的效率，所以读写都可以放在一个M1(WR)，而另外一个不提供读也不提供写，只提供standby冗余异地容灾。

这个异地容灾是非常重要的，否则如果是单机的，单边的业务，万一idc机房故障了，一般就会影响在线业务的，这种 造成业务2小时无法应用，对于在线电子商务交易来说，影响是蛮大的，所以为了最大限度的保证7*24小时，必须要做到异地容灾，MM要跨idc机房。虽然对资源有一些要求，但是对HA来说是不可缺少的，一定要有这个MM机制。

做切换的时候，把所有的读写从M1直接切换到M2上就可以了。

(5)读写平分秋色

读和写差不多，但是读不能影响写的能力，把读写放在M1(WR)上，然后把一部分读也放在M2(R)上面，当然M1和M2也是跨机房部署的。

切换的时候，把一部分读和全部写从M1切换到M2上就可以了。