前言：
相对于传统行业的相对服务时间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，
图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的方式实现统计，在互联网行业，尤其是电商和游戏这块，差不多可以解决90%以上的统计业务。有时候如果用户或者客户提出要实时read-time了，大家可以沟通一下为什么需要实时，了解具体的业务场景，有些可能真的不需要实时统计，需要有所权衡，需要跟用户和客户多次有效沟通，做出比较适合业务的统计架构模型。
B，还有一种offline统计业务，比如月份报表年报表统计等，这种完全可以把数据放到数据仓库里面或者第三方Nosql里面进行统计。
（5）历史数据迁移
历史数据迁移，需要尽量不影响现在线上的业务，尽量不影响现在线上的查询写入操作，为什么要做历史数据迁移？因为有些业务的数据是有时效性的，比如电商中的已经完成的历史订单等，不会再有更新操作了，只有很简单的查询操作，而且查询也不会很频繁，甚至可能一天都不会查询一次。
如果这时候历史数据还在online库里面或者online表里面，那么就会影响online的性能，所以对于这种，可以把数据迁移到新的历史数据库上，这个历史数据库可以是mysql也可以是nosql，也可以是数据仓库甚至hbase大数据等。
实现途径是通过slave库查询出所有的数据，然后根据业务规则比如时间、某一个纬度等过滤筛选出数据，放入历史数据库(History Databases)里面。迁移完了，再回到主库M1上，删除掉这些历史数据。这样在业务层面，查询就要兼顾现在实时数据和历史数据，可以在filter上面根据迁移规则把online查询和history查询对接起来。比如说一个月之内的在online库查询一个月之前的在history库查询，可以把这个规则放在DB的迁移filter层和应用查询业务模块层。如果可以的话，还可以配置更细化，通过应用查询业务模块层来影响DB的迁移filter层，比如以前查询分为一个月为基准，现在查询业务变化了，以15天为基准，那么应用查询业务模块层变化会自动让DB的filter层也变化，实现半个自动化，更加智能一些。
（6）MySQL Sharding
像oracle这种基于rac基于共享存储的方式，不需要sharding只需要扩从rac存储就能实现了。但是这种代价相对会比较高一些，共享存储一般都比较贵，随着业务的扩展数据的爆炸式增长，你会不停累计你的成本，甚至达到一个天文数字。
目前这种share disk的方式，除了oracle的业务逻辑层做的非常完善之外其他的解决方案都还不是很完美。
Mysql的sharding也有其局限性，sharding之后的数据查询访问以及统计都会有很大的问题，mysql的sharding是解决share nothing的存储的一种分布式的方法，大体上分为垂直拆分和水平拆分。
（6.1）垂直拆分
可以横向拆分，可以纵向拆分，可以横向纵向拆分，还可