MySql高可用架构在业务层面资料.doc

前言： 相对于传统行业的相对服务时间9x9x6或者9x12x5，因为互联网电子商务以及互联网游戏的实时性，所以服务要求7*24小时，业务架构不管是应用还是 HYPERLINK /database/ \t /database/201410/_blank 数据库，都需要容灾互备，在 HYPERLINK /database/MySQL/ \t /database/201410/_blank mysql的体系中，最好通过在最开始阶段的数据库架构阶段来实现容灾 HYPERLINK /os/ \t /database/201410/_blank 系统。所以这里从业务宏观角度阐述下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， 图3 （4）读少写多 意味着读并不会影响写的效率，所以读写都可以放在一个M1(WR)，而另外一个不提供读也不提供写，只提供standby冗余异地容灾。 这个异地容灾是非常重要的，否则如果是单机的，单边的业务，万一idc机房故障了，一般就会影响在线业务的，这种 造成业务2小时无法应用，对于在线电子商务交易来说，影响是蛮大的，所以为了最大限度的保证7*24小时，必须要做到异地容灾，MM要跨idc机房。虽然对资源有一些要求，但是对HA来说是不可缺少的，一定要有这个MM机制。 做切换的时候，把所有的读写从M1直接切换到M2上就可以了。 （5）读写平分秋色 读和写差不多，但是读不能影响写的能力，把读写放在M1(WR)上，然后把一部分读也放在M2(R)上面，当然M1和M2也是跨机房部署的。 切换的时候，把一部分读和全部写从M1切换到M2上就可以了。? 二：MySQL架构设计—常见架构 （1）强一致性 对读一致性的权衡，如果是对读写实时性要求非常高的话，就将读写都放在M1上面，M2只是作为standby，就是采取和上面的一（4）的读少写多的一样的架构模式。 比如，订单处理流程，那么对读需要强一致性，实时写实时读，类似这种涉及交易的或者动态实时报表统计的都要采用这种架构模式 ? （2）弱一致性 如果是弱一致性的话，可以通过在M2上面分担一些读压力和流量，比如一些报表的读取以及静态配置数据的读取模块都可以放到M2上面。比如月统计报表，比如首页推荐商品业务实时性要求不是很高，完全可以采用这种弱一致性的设计架构模式。 （3）中间一致性 如果既不是很强的一致性又不是很弱的一致性，那么我们就采取中间的策略，就是在同机房再部署一个S1(R)，作为备库，提供读取服务，减少M1(WR)的压力，而另外一个idc机房的M2只做standby容灾方式的用途。 当然这里会用到3台数据库服务器，也许会增加采购压力，但是我们可以提供更好的对外数据服务的能力和途径，实际中尽可能两者兼顾。 ? （4）统计业务 比如PV、UV操作、页数的统计、流量的统计、数据的汇总等等，都可以划归为统计类型的业务。 数据库上做大查询的统计是非常消耗资源的。统计分为实时的统计和非实时的统计，由于mysql主从是逻辑sql的模式，所以不能达到100%的实时，如果是online要严格的非常实时的统计比如像火车票以及金融异地结算等的统计，mysql这块不是它的强项，就只有查询M1主库来实现了。 ? A，但是对于不是严格的实时性的统计，mysql有个很好的机制是binlog，我们可以通过binlog进行解析Parser，解析出来写入统计表进行统计或者发消息给应用端程序来进行统计。这种是准实时的统计操作，有一定的短暂的可接受的统计延迟现象，如果要100%实时性统计只有查询M1主库了。 通过binlog的方式实现统计，在互联网行业，尤其是电商和游戏这块，差不多可以