vlambda博客
学习文章列表

部分互联网公司选用Mysql做为数据库，体现在它的扩展性，mysql可以架构出一个分布式集群，相对于oracle这种大型数据库来说，他显得灵活，轻盈，而且他还是开源免费的。

为什么mysql在互联网公司那么受到青睐， 因为互联网公司相对于传统企业来说，他的数据量增长的很快，单点数据库已经无法满足数据的实时查询和存储的要求了，所以需要扩展数据库架构。

Mysql数据库架构的演化分为几个阶段：

单节点数据库

一主一从架构

一主多从架构

双主多从架构

对比上面的架构图，来具体看看这几种架构的区别。

单节点数据库

大部分的童鞋接触到的都是这种单节点的数据库架构，一个JAVA程序使用数据库连接池操作一个数据库，这个是不是很熟悉，就是J2EE的典型应用。

上点代码看看，更熟悉一点

架构上面来说就是一个应用连接一个数据库，十分简单，也就不多说了，如下图：

一主一从架构

随着互联网访问量的迅速增加、以及数据量的增大，单点数据库会出现延迟，假死，更严重的出现崩溃的情况，在用户端看到的现象会是这样的

这种情况下，数据库已经负担不起这么大的压力了，海豚自恃清高也没用，于是有人想出用两个海豚来解决这个问题，最简单的就是这种一主一从的架构

为什么要这样子来架构呢？

这样我们先来分析一下造成系统性能的瓶颈在哪里。

从硬件计算机系统来说，系统的性能主要取决于CPU, 内存, 磁盘I/O, 网络I/O

再仔细分析

内存的读写速度是 24165M/s，

机械硬盘的读写速度在100M/s，

网络带宽一般机房可以到千兆带宽，

很明显我们可以看出，硬盘的读写速度跟内存相差200多倍，很容易找出，我们系统的瓶颈在硬盘读写这一块，当然这里只是简单的推理，也有一些专业的工具对其进行测试。

现在我们有两个方法来解决这个问题：

1、提高硬盘的读写速度，让其达到内存的速度

2、分摊压力，把硬盘读写的压力分摊到不同的节点上面

第一个方法那是硬盘厂商的事情了，我们控制不了，当然现在市面上也有读写快的，例如固态硬盘可以选配。

我们要说的就是如何用现有的硬件来解决问题，也就是第二种方法。

我们再来分析业务：

数据库的操作insert  , delete ,update ,select

在正式的生产环境中，我们会发现，对比insert写的操作，用户更多的在select查询上面的操作.

例如：我们经常浏览新闻、逛淘宝，还在看我写的这篇文章，这些都是在进行读查询.

那么我们一主一从的架构就是让应用从 2个节点上面读取，来进行分摊压力，而这种从两个节点上面读取的策略 可以 通过 负载均衡来实现，意思就是说 如果有10个请求过来，把5个读的请求转发到 A 节点， 另外5个转发到B节点上面。

那么这个一主一从是如何实现的呢？

可以通过MySQL replication复制的方式来做：

选定一个节点的MySQL作为master，另外一个节点的MySQL作为slave。

插入更新数据我们通过master完成，master会通过replication的方式来完成对slave的同步更新.

这时slave就会有相同的数据，应用就可以通过从slave读取数据来减轻master的压力.Master/Slave复制原理及方式

1、Master所有的数据更新会记录到日志binlog中，Master A把binlog日志传给Slave B

2、B先把A的binlog日志放到称为relaylog中继日志的 地方

3、最后B通过relaylog日志中的内容对自己的binlog进行更新，复制数据。

从这种机制上我们可以看出，可以保证A和B的数据一致，但是同步或许会有延时(不考虑网络因素)

A 的执行可以并发执行，等A的binlog日志写到B的relaylog，然后B从relaylog读取复制到binlog，这个过程中会发生延时.

于是出现了

同步复制 的方式 ：

同步复制是用户在前端访问，Master收到insert请求，这个时候需要等待slave复制完成后确认，才能返回结果给用户，显然这种方式不可取，因为会造成用户请求变的很慢的情况。而这种方式也不是MySQL的默认方式。

异步复制：

Master只要完成自己的数据更新就返回结果给用户，而同步在异步状态下进行。MySQL默认设置。

半同步复制：

即是 如果slave有很多个，也是后面讲的一主多从的架构下，master只要保证其中一个slave同步复制成功，就返回结果给用户端。

一主多从架构

一主一从是一主多从架构中的特例，一主一从学会了，很容易理解一主多从的架构了。

在Mysql的配置上面区别不大，后面实战进行架构的搭建会讲到。

这里就不衍生开了。

双主多从架构

为什么会有双主多从架构出现呢，肯定是为了解决某种问题而产生的。

是的，当我们用了一主多从架构以后，我们会发现一个致命的问题，当我有5个节点，肯定是1个Master，另外4个是slave , 这个时候master就相当于是中心领导的地位，他这么重要，如果master崩掉了怎么办，整个系统就不能正常运行了，这个时候采用双主多从，来用副领导保证。

就像master1是一个总经理， 如果总经理不舒服或者有事走开了，这个时候就由master2 副总来接替他的工作。

Mysql Sharding

master-slave这种架构，不管是一主多从还是双主多从，我们发现他的性能瓶颈是在master上面，整个系统也并不是可以通过增加master来达到性能的倍数增长的。

slave越多，master复制到slave的日志越多，master的负担就越重，同步的延时就越大

会出现读取到脏数据，以及数据不一致的问题。

问题出现了，新的架构也随之而来。

一种分表分库的分布式架构就出现了。

简单来讲，分表分库不是在master和slave之间进行数据复制以减轻读的压力。

而是把数据内容进行切分，分别放到不同的节点上  。

例如 ：现在有10个用户的数据

master-slave的做法是复制10个用户的数据到slave下面去，这个时候整个系统就有10*N个slave的数据量了。

而 分表分库则是其中5个用户数据放到A节点上 ， 另外5个用户数据放到B节点上，整个系统数据还是10个数据量。

这里简单讲这些，详细的放到后面章节中来讲。

在分表分库我们用Mycat中间件，在每个节点的分库中，我们还可以采用Master-Slave这种架构作为混合架构使用。

小张讲解

读写分离

通过MySQL replication我们可以复制数据到不同的数据库中，但是上面讲到读取需要从不同的节点中读取，还要有策略作负载均衡，这个功能逻辑就需要应用来进行实现。（应用要连接不同的数据库节点，分离读写）

市面上有很多成熟的中间件可以实现负载均衡、读写分离，例如：MySQL-Proxy ,应用层可以像 刚开始那样代码不变，所有的读写分离工作交给 MySQL-Proxy中间件来实现。

MySQL replication

下一节中，我们具体来动手来做一个一主一从这种架构，通过配置MySQL的replication ,以及在应用层进行负载均衡、读写分离的实现，用最轻的方式来进行性能的最大提升。