持久化存储-MySql拓展-Master-Slave

先说一下可靠数据库的特性

ACID，是指在可靠数据库管理系统（DBMS）中，事务(transaction)所应该具有的四个特性：

原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）.

这是可靠数据库所应具备的几个特性.

MySql拓展

1、业务拆分

随着网站业务的不断发展，单个库的访问量越来越大，因此不得不对系统的业务进行拆分，每一块业务都使用不同的数据库来进行存储，前端不同业务访问不同的数据库，这样原本依赖单库的服务，拆分成了几个库同时承受压力，吞吐能力自然就提高了。

业务拆分不仅提高了系统的可拓展性，而且还提高了开发工作的效率。原来一次修改，工程的启动和部署都需要花费较大的时间成本。随着系统的拆分，单个系统的复杂度降低，减轻了应用多个分支合并冲突解决的麻烦，不仅大大提高了研发测试效率，同时也提高了系统的稳定性。

2、复制策略-Master-Slave（主从策略）

架构变化的同时，业务也在不断的发展， 可能很快就会发现，随着访问量的不断增加，拆分后的某个库的压力就会越来越大，很快就会达到性能瓶颈，数据库架构不得不进行优化。这时可以使用MySQL的复制（replication）策略来对系统进行拓展。

通过数据库的复制策略，可以将一台数据库服务器中的数据复制到另一台数据库服务器中。当各台数据库服务器上都包含相同的数据时，前端应用通过访问MySQL集群中的任一一台数据库服务器，都可以读取到想要的数据，这样单独一台数据库服务器所承担的压力就会大大降低，从而提高系统的承载能力，达到系统拓展的目的。

如图所示，要实现MySQL的主从复制策略，需要开启Master服务器端的Binary Log，数据的复制过程实际上就是Slave从Master获取Binary log，然后在本地镜像中执行Binary log中记录的操作的一个过程。

由于复制的过程是异步的，因此Master和Slave之间的数据可能出现延迟现象，此时只能保证最终数据的一致性。

MySQL的复制可以是基于statement level（基于语句），也可以row level（基于记录） 。

基于row level的复制，可以不记录Sql语句的上下文信息，只需记录数据变更的内容即可，但是由于每行的变更记录都会被记录，这样可能会产生很多的日志内容。

基于statement level的复制，则值记录修改数据的Sql语句 ，减少了Binary log的日志量，解决了I/O成本，但是为了保证SQL能够在Slave上正确的执行，它还需要记录SQL的上下文信息，以保证SQL在Slave上执行的结果与在Master上执行的结果一致。

如图，在实际的应用场景中，MySQL的Master与Slave之间的复制架构可能是这样的。

前端服务器通过Master来执行写操作，数据更新通过Binary log同步到Slave集群，而对于数据的读取请求，则交由Slave来处理。这样Slave集群就分担了数据库的读压力，并且读写分离还保障了数据能够达到最终的数据一致性。

一般情况下，大多数网站的读操作会比写操作更为密集，如果读的压力比较大时，可以通过增加Slave来进行系统的拓展，因此，Master-Slave架构能够很显著的提高系统性能，减轻单个数据库的读压力。

但是Master-Slave架构也存在一个致命的问题，那就是单点故障的问题。当Master宕机之后，系统将无法进行写操作，但是在某些特定的环境下，也可能需要Master停机，以便进行系统的维护和升级。

怎么解决这个问题，在MySQL中，可以采用Master-Master的架构去解决Master单点故障的问题，我们下一篇文章再讲述。