纲举目张：打通MySQL架构和业务的任督二脉

目前，在很多OLTP场景中，MySQL数据库都有着广泛的应用，也有很多不同的使用方式。从数据库的业务需求、架构设计、运营维护、再到扩容迁移，不同的MySQL架构有不同的特点，适应一定的业务场景，或者解决一定的业务问题。

DBA作为数据库架构的设计、实施、维护人员，不仅要对各种MySQL架构非常熟悉，还要了解业务，对于不同的业务有一定的划分和认识，并根据业务特点和架构特点，合理选择和使用MySQL，满足业务需求。

一、MySQL数据库常见架构

（2）MySQL master-slave主从架构

MySQL master-slave主从环境，是在MySQL单实例环境的基础上，将MySQL进行全库备份，再恢复出一个或多个MySQL实例，通过change master命令，指定新恢复出的MySQL实例，从那个MySQL节点上读取变化日志，并在本地应用，使新恢复的实例与原来的MySQL实例数据一致保持一致。

所以，原来的数据一致变化的实例，叫master主节点；从master节点获取日志，并在本地应用，使数据与master阶段保持一致的节点，叫slave从节点；这样的架构环境，就叫 master-slave主从环境。

Master-slave主从环境，是MySQL数据库非常具有特色的功能，也是MySQL数据库应用在生产环境的常见架构。

通过master-slave架构，就可以使线上数据库的数据有了多份，起到了一定的数据备份功能。Slave从库数据变化只通过应用日志实现，一般不会主动产生写数据的情况，但可以提供对外数据读服务，这样通过增加几个slave从库，让只进行数据读取的业务到slave从库上查询，就都可以大大提高业务的读性能和吞吐量。在互联 行业中，非常多的数据读操作远高于数据写操作的业务场景，通过在master主节点写数据，在slave节点上读数据，进行这种读写分离的架构，可以很好地满足业务需求。

当然，MySQL的master-slave主从架构，具体实现也可以非常灵活，1个master主节点，可以有1个或多个slave从节点；而一个slave节点，也可以当做其它节点的slave节点，如果一个slave节点后面再有其它节点当做这个节点的slave从节点，就叫做级联复制。

MySQL的master-save架构，在MySQL单实例架构的基础上，提高了MySQL数据库的性能、可用性和可扩展性，同时也为MySQL数据库追求更高的可用性，提供了基础保障。

小结

这里就介绍完了MySQL单实例架构、MySQLmaster-slave主从架构、MySQL+MHA高可用架构，对于MySQL数据库的各种通用性需求，这三种基础架构都可以很好地满足，换句话说，这是MySQL数据库架构中必须要用到和掌握的三种基础架构。

2

五种特殊业务需求架构

通过MySQL中这三种常见基础架构，绝大多数MySQL数据库场景和问题，都可以很好得满足和解决。但一些特殊的场景，或一些特殊的问题，也可以使用除MySQL数据库以外的其它数据库、专门某一类或几类问题的解决方案。针对这些特殊的业务需求，接下来我会先从要解决的问题进行描述和说明，然后再提出对应的解决方案。

（1）MySQL + 分布式Proxy 水平扩展架构

问题：如果业务规模进一步扩大，读写量级尤其是写的量级达到非常大的地步，比如每秒数据写入几十万，甚至几百万，每天的数据量有几亿甚至几十亿的规模，这样的读写就远远不是一个master节点可以支撑的，这时就必须要进行扩展了。

一般来说，MySQL的扩展可分为：按照不同业务进行垂直拆分的垂直扩展，和通过一定的分库分表策略实现的库表水平扩展两种方式。这两种方式可以单独使用，也可以结合使用。但如果是解决大量数据和高并发读写，主要方式还是MySQL水平扩展。

MySQL水平扩展的思路

在一个服务器上的database库和table表，总会受到一台服务器的资源限制，即使服务器的硬件各方面都达到顶配，也还是会有瓶颈。对于业务访问来说，如果有一个Proxy代理层或者中间件层的一个database和一个table，通过代理层按照一定的规则映射和转换，转换成底层多台服务器上的多个database和多个table，这样就相当于多台服务器共同支撑一个业务，可支持的容量就与底层服务器的数量有关。在Proxy代理没有到瓶颈的情况下，底层服务器数量越多，整个水平扩展集群的性能和容量也会越多，几乎可以线性扩展。通过这样的思路，就可以解决大量数据存储和并发的问题。

具体实现来说，水平扩展集群除了MySQL数据库，需要一个分布式Proxy中间件，这种水平扩展中间件种类也比较多，MySQL官方和一些大的的公司都有开发。我们用的比较多的是MyCAT中间件。对于底层的分片，可以有几十个、几百个甚至几千个。

当然，水平扩展可以解决大数据量的问题，需要有分片策略，那相应地，也会有使用这种策略的限制，比如片键选择，跨节点访问，分布式事务等问题，需要与业务进行对应结合和考虑后，才可以很好地使用。

（3）MySQL + 缓存（Memcached、Redis等） 高并发读架构

问题：如果业务访问MySQL中的某一些少量热数据，访问的并发量非常高，访问的时效性，数据的一致性要求都非常高，这时候使用MySQL数据库本身支持这些数据读取，可能会在并发性、时效性上出现瓶颈。这时，就可以使用缓存系统结合MySQL来使用。

缓存系统是将MySQL数据库中的少量热数据存放到内存当中，由于内存的IO效率远高于硬盘的IO，相应的CPU消耗也会少很多，这样缓存系统中响应一次业务请求的时间，会远少于直接从MySQL数据库访问需要的时间。于是缓存系统就可以支撑热数据的高并发访问，数据写还是写入MySQL数据库中，数据读操作，优先读取缓存；如果缓存中有，则直接从缓存中返回结果；如果缓存中没有，则从MySQL数据库中读取数据返回应用，并把数据结果再放到缓存的内容中。