| 作为最流行的开源数据库，MySQL被广泛应用在Web应用程序以及其它中小型项目上。然而不可忽视的是，在许多大型IT公司中，MySQL在高度优化和定制化后，已逐渐偏离了原有的开源版本，更像是一种分支，比如Facebook前不久开源的WebScaleSQL。近日，@大熊先生发表了一篇博文，从大型网站架构发展的角度看MySQL应用所发生的改变，这里为大家分享。 本文主要描述在网站的不同的并发访问量级下，Mysql架构的演变。 可扩展性 架构的可扩展性往往和并发是息息相关，没有并发的增长，也就没有必要做高可扩展性的架构，这里对可扩展性进行简单介绍一下，常用的扩展手段有以下两种：
对于互联网的高并发应用来说，无疑横向扩展才是出路，同事通过纵向购买更高端的机器也一直是我们所避讳的问题，也不是长久之计。那么，在横向扩展的理论下，可扩展性的理想状态是什么？ 可扩展性的理想状态 一个服务，当面临更高的并发的时候，能够通过简单增加机器来提升服务支撑的并发度，且增加机器过程中对线上服务无影响（no down time），这就是可扩展性的理想状态！ 架构的演变V1.0 简单网站架构一个简单的小型网站或者应用背后的架构可以非常简单，数据存储只需要一个Mysql Instance就能满足数据读取和写入需求（这里忽略掉了数据备份的实例），处于这个时间段的网站，一般会把所有的信息存到一个Database Instance里面。 在这样的架构下，我们来看看数据存储的瓶颈是什么？
只有当以上3件事情任何一件或多件满足时，我们才需要考虑往下一级演变。 从此我们可以看出，事实上对于很多小公司小应用，这种架构已经足够满足他们的需求了，初期数据量准确评估是杜绝过度设计很重要的一环，毕竟没有人愿意为不可能发生的事情而浪费自己的精力。 这里简单举个我的例子，对于用户信息这类表 （3个索引），16G内存能放下，大概2000万行数据的索引，简单的读和写混合访问量3000/s左右没有问题，你的应用场景是否？ V2.0 垂直拆分一般当V1.0 遇到瓶颈时，首先最简便的拆分方法就是垂直拆分，何谓垂直？就是从业务角度来看，将关联性不强的数据拆分到不同的Instance上，从而达到消除瓶颈的目标。以图中的为例，将用户信息数据，和业务数据拆分到不同的三个实例上。对于重复读类型比较多的场景，我们还可以加一层Cache，来减少对DB的压力。 在这样的架构下，我们来看看数据存储的瓶颈是什么？ 单实例单业务依然存在V1.0所述瓶颈：遇到瓶颈时可以考虑往本文更高V版本升级，若是读请求导致达到性能瓶颈可以考虑往V3.0升级， 其他瓶颈考虑往V4.0升级。 V3.0 主从架构此类架构主要解决V2.0架构下的读问题，通过给Instance挂数据实时备份的思路来迁移读取的压力，在MySQL的场景下就是通过主从结构，主库抗写压力，通过从库来分担读压力，对于写少读多的应用，V3.0主从架构完全能够胜任。 在这样的架构下，我们来看看数据存储的瓶颈是什么？很明了，写入量主库不能承受。 |
