MySQL在大型网站的应用架构演变

客官°小女子只卖身不卖艺 2022-08-24 00:53 169阅读 0赞

**摘要：**虽然许多人不满意MySQL被Oracle收购后的发展进度，但是该开源数据库被应用的广泛程度仍然不容质疑。然而开源到大型企业应用必然存在着很多的技术挑战，这里我们一起看不同并发访问量级下，Mysql架构的演变。

【编者按】作为最流行的开源数据库，MySQL被广泛应用在Web应用程序以及其它中小型项目上。然而不可忽视的是，在许多大型IT公司中，MySQL在高度优化和定制化后，已逐渐偏离了原有的开源版本，更像是一种分支，比如Facebook前不久开源的WebScaleSQL。近日，@大熊先生发表了一篇博文，从大型网站架构发展的角度看MySQL应用所发生的改变，这里为大家分享。

--------------------

[![538d3c9d293eb_middle.jpg_55761][]][538d3c9d293eb_middle.jpg_55761 1]**免费订阅“CSDN云计算”微信公众号，实时掌握第一手云中消息！**

CSDN作为国内最专业的云计算服务平台，提供云计算、大数据、虚拟化、数据中心、OpenStack、CloudStack、Hadoop、Spark、机器学习、智能算法等相关云计算观点，云计算技术，云计算平台，云计算实践，云计算产业资讯等服务。

--------------------

**以下为博文：**

**写在最前：**

本文主要描述在网站的不同的并发访问量级下，Mysql架构的演变。

**可扩展性**

架构的可扩展性往往和并发是息息相关，没有并发的增长，也就没有必要做高可扩展性的架构，这里对可扩展性进行简单介绍一下，常用的扩展手段有以下两种：

*  **Scale-up**：纵向扩展，通过替换为更好的机器和资源来实现伸缩，提升服务能力
 *  **Scale-out：**横向扩展, 通过加节点（机器）来实现伸缩，提升服务能力

对于互联网的高并发应用来说，无疑横向扩展才是出路，同事通过纵向购买更高端的机器也一直是我们所避讳的问题，也不是长久之计。那么，在横向扩展的理论下，可扩展性的理想状态是什么？

**可扩展性的理想状态**

![Image 1][] ![Image 1][]

一个服务，当面临更高的并发的时候，能够通过简单增加机器来提升服务支撑的并发度，且增加机器过程中对线上服务无影响（no down time），这就是可扩展性的理想状态！

## 架构的演变 ##

### V1.0 简单网站架构 ###

一个简单的小型网站或者应用背后的架构可以非常简单，数据存储只需要一个Mysql Instance就能满足数据读取和写入需求（这里忽略掉了数据备份的实例），处于这个时间段的网站，一般会把所有的信息存到一个Database Instance里面。

[![5397f3b633529_middle.jpg][]][5397f3b633529_middle.jpg 1]

在这样的架构下，我们来看看数据存储的瓶颈是什么？

*  数据量的总大小 一个机器放不下
 *  数据的索引（B+ Tree）一个机器的内存放不下  
    
 *  访问量（读写混合）一个实例不能承受

只有当以上3件事情任何一件或多件满足时，我们才需要考虑往下一级演变。 从此我们可以看出，事实上对于很多小公司小应用，这种架构已经足够满足他们的需求了，初期数据量准确评估是杜绝过度设计很重要的一环，毕竟没有人愿意为不可能发生的事情而浪费自己的精力。

这里简单举个我的例子，对于用户信息这类表 （3个索引），16G内存能放下，大概2000万行数据的索引，简单的读和写混合访问量3000/s左右没有问题，你的应用场景是否？

### V2.0 垂直拆分 ###

一般当V1.0 遇到瓶颈时，首先最简便的拆分方法就是垂直拆分，何谓垂直？就是从业务角度来看，将关联性不强的数据拆分到不同的Instance上，从而达到消除瓶颈的目标。以图中的为例，将用户信息数据，和业务数据拆分到不同的三个实例上。对于重复读类型比较多的场景，我们还可以加一层Cache，来减少对DB的压力。

[![5397f40ae8264_middle.jpg][]][5397f40ae8264_middle.jpg 1]

在这样的架构下，我们来看看数据存储的瓶颈是什么？

**单实例单业务依然存在V1.0所述瓶颈：**遇到瓶颈时可以考虑往本文更高V版本升级，若是读请求导致达到性能瓶颈可以考虑往V3.0升级， 其他瓶颈考虑往V4.0升级。

### V3.0 主从架构 ###

此类架构主要解决V2.0架构下的读问题，通过给Instance挂数据实时备份的思路来迁移读取的压力，在MySQL的场景下就是通过主从结构，主库抗写压力，通过从库来分担读压力，对于写少读多的应用，V3.0主从架构完全能够胜任。

[![5397f44f21a24_middle.jpg][]][5397f44f21a24_middle.jpg 1]

在这样的架构下，我们来看看数据存储的瓶颈是什么？很明了，写入量主库不能承受。

### V4.0 水平拆分 ###

对于V2.0、V3.0方案遇到瓶颈时，都可以通过水平拆分来解决，水平拆分和垂直拆分有较大区别，垂直拆分拆完的结果，在一个实例上是拥有全量数据的，而水平拆分之后，任何实例都只有全量的1/n的数据，以下图UserInfo的拆分为例，将UserInfo拆分为3个Cluster，每个Cluster持有总量的1/3数据，3个Cluster数据的总和等于一份完整数据。

注：这里不再叫单个实例 而是叫一个Cluster 代表包含主从的一个小MySQL集群。

[![5397f47875748.jpg][]][5397f47875748.jpg]

**那么，这样架构中的数据该如何路由？**

**1. Range拆分**  
  
sharding key按连续区间段路由，一般用在有严格自增ID需求的场景上，如UserId、UserId Range的小例子，以UserId 3000万为Range进行拆分：1号Cluster的UserId是1-3000万，2号Cluster UserId是 3001万-6000万。

**2. List拆分**

List拆分与Range拆分思路一样，都是通过给不同的sharding key来路由到不同的Cluster，但是具体方法有些不同。List主要用来做sharding key不是连续区间的序列落到一个Cluster的情况，如以下场景：

假定有20个音像店，分布在4个有经销权的地区，如下表所示：

业务希望能够把一个地区的所有数据组织到一起来搜索，这种场景List拆分可以轻松搞定

**3. Hash拆分**

通过对sharding key 进行哈希的方式来进行拆分，常用的哈希方法有除余，字符串哈希等等，除余如按UserId%n的值来决定数据读写哪个Cluster，其他哈希类算法这里就不细展开讲了。

**4. 数据拆分后引入的问题**

数据水平拆分引入的问题主要是只能通过sharding key来读写操作，例如以UserId为sharding key的切分例子，读UserId的详细信息时，一定需要先知道UserId，这样才能推算出在哪个Cluster进而进行查询，假设我需要按UserName进行检索用户信息，需要引入额外的反向索引机制（类似HBase二级索引），如在Redis上存储username->userid的映射，以UserName查询的例子变成了先通过查询username->userid，再通过userid查询相应的信息。

实际上这个做法很简单，但是我们不要忽略了一个额外的隐患，那就是数据不一致的隐患。存储在Redis里的username->userid和存储在MySQL里的userid->username必须需要是一致的，这个保证起来很多时候是一件比较困难的事情，举个例子来说，对于修改用户名这个场景，你需要同时修改Redis和Mysql。这两个东西是很难做到事务保证的，如MySQL操作成功，但是Redis却操作失败了（分布式事务引入成本较高）。对于互联网应用来说，可用性是最重要的，一致性是其次，所以能够容忍小量的不一致出现. 毕竟从占比来说，这类的不一致的比例可以微乎其微到忽略不计。（一般写更新也会采用mq来保证直到成功为止才停止重试操作）

在这样的架构下，我们来看看数据存储的瓶颈是什么？

在这个拆分理念上搭建起来的架构，理论上不存在瓶颈（sharding key能确保各Cluster流量相对均衡的前提下)。不过确有一件恶心的事情，那就是Cluster扩容的时候重做数据的成本，如我原来有3个Cluster，但是现在我的数据增长比较快，我需要6个Cluster，那么我们需要将每个Cluster 一拆为二，一般的做法是：

1.  摘下一个slave，停同步
2.  对写记录增量log（实现上可以业务方对写操作多一次写持久化mq或者MySQL主创建trigger记录写等等方式）
3.  开始对静态slave做数据一拆为二
4.  回放增量写入，直到追上的所有增量，与原Cluster基本保持同步
5.  写入切换，由原3 Cluster 切换为6 Cluster

有没有类似飞机空中加油的感觉，这是一个脏活，累活，容易出问题的活，为了避免这个，我们一般在最开始的时候，设计足够多的sharding cluster来防止可能的Cluster扩容这件事情。

### V5.0 云计算 腾飞（云数据库） ###

云计算现在是各大IT公司内部作为节约成本的一个突破口，对于数据存储的MySQL来说，如何让其成为一个SaaS是关键点。在MS的官方文档中，把构建一个足够成熟的SaaS（MS简单列出了SAAS应用的4级成熟度）所面临的3个主要挑战：可配置性，可扩展性，多用户存储结构设计称为"three headed monster"。可配置性和多用户存储结构设计在MySQL SaaS这个问题中并不是特别难办的一件事情，所以这里重点说一下可扩展性。

MySQL作为一个SaaS服务，在架构演变为V4.0之后，依赖良好的sharding key设计，已经不再存在扩展性问题，只是他在面对扩容缩容时，有一些脏活需要干，而作为SaaS，并不能避免扩容缩容这个问题，所以只要能把V4.0的脏活变成：第1，扩容缩容对前端APP透明（业务代码不需要任何改动）；第2，扩容缩容全自动化且对在线服务无影响。如果实现了这两点，那么他就拿到了作为SaaS的门票。

[![5397f595f36c5_middle.jpg][]][5397f595f36c5_middle.jpg 1]

对于架构实现的关键点，需要满足对业务透明，扩容缩容对业务不需要任何改动，那么就必须eat our own dog food，在你MySQL SaaS内部解决这个问题，一般的做法是我们需要引入一个Proxy，Proxy来解析SQL协议，按sharding key来寻找Cluster，判断是读操作还是写操作来请求Master或者Slave，这一切内部的细节都由Proxy来屏蔽。

[![5397f5b833067.jpg][] ][5397f5b833067.jpg]

**这里借淘宝的图来列举一下Proxy需要干哪些事情**

对于架构实现的关键点，扩容缩容全自动化且对在线服务无影响； 扩容缩容对应到的数据操作即为数据拆分和数据合并，要做到完全自动化有非常多不同的实现方式，总体思路和V4.0介绍的瓶颈部分有关，目前来看这个问题比较好的方案就是实现一个伪装Slave的Sync Slave，解析MySQL同步协议，然后实现数据拆分逻辑，把全量数据进行拆分。具体架构见下图：

[![5397f5d686edb.jpg][] ][5397f5d686edb.jpg]

其中Sync Slave对于Original Master来说，和一个普通的Mysql Slave没有任何区别，也不需要任何额外的区分对待。需要扩容/缩容时，挂上一个Sync slave，开始全量同步+增量同步，等待一段时间追数据。以扩容为例，若扩容后的服务和扩容前数据已经基本同步了，这时候如何做到切换对业务无影响？ 其实关键点还是在引入的Proxy，这个问题转换为了如何让Proxy做热切换后端的问题。这已经变成一个非常好处理的问题了。

另外值得关注的是：2014年5月28日——为了满足当下对Web及云应用需求，甲骨文宣布推出MySQL Fabric，在对应的资料部分我也放了很多Fabric的资料，有兴趣的可以看看，说不定会是以后的一个解决云数据库扩容缩容的手段。

### V more ? ###

等待革命……

**淘宝用例**

*  淘宝RDS 云数据库设计： [http://blog.csdn.net/ywh147/article/details/8954625 ][http_blog.csdn.net_ywh147_article_details_8954625][http://www.infoq.com/cn/news/2012/10/taobao-ump][http_www.infoq.com_cn_news_2012_10_taobao-ump]

**Mysql Fabric**

*  [http://mysqlmusings.blogspot.jp/2013/09/brief-introduction-to-mysql-fabric.html][http_mysqlmusings.blogspot.jp_2013_09_brief-introduction-to-mysql-fabric.html] [  
    ][Link 1]
 *  [http://vnwrites.blogspot.jp/2013/09/mysqlfabric-sharding-introduction.html][Link 1] [  
    ][Link 2]
 *  [http://vnwrites.blogspot.in/2013/09/mysqlfabric-sharding-example.html][Link 2] [  
    ][Link 3]
 *  [http://vnwrites.blogspot.in/2013/09/mysqlfabric-sharding-migration.html][Link 3] [  
    ][Link 4]
 *  [http://vnwrites.blogspot.jp/2013/09/mysqlfabric-sharding-maintenance.html][Link 4]

**博文链接：**[Mysql在大型网站的应用架构演变 ][Mysql_]

[538d3c9d293eb_middle.jpg_55761]: http://cms.csdnimg.cn/article/201406/03/538d3c9d293eb_middle.jpg?_=55761
[538d3c9d293eb_middle.jpg_55761 1]: http://cms.csdnimg.cn/article/201406/03/538d3c9d293eb.jpg
[Image 1]: 
[5397f3b633529_middle.jpg]: http://cms.csdnimg.cn/article/201406/11/5397f3b633529_middle.jpg
[5397f3b633529_middle.jpg 1]: http://cms.csdnimg.cn/article/201406/11/5397f3b633529.jpg
[5397f40ae8264_middle.jpg]: http://cms.csdnimg.cn/article/201406/11/5397f40ae8264_middle.jpg
[5397f40ae8264_middle.jpg 1]: http://cms.csdnimg.cn/article/201406/11/5397f40ae8264.jpg
[5397f44f21a24_middle.jpg]: http://cms.csdnimg.cn/article/201406/11/5397f44f21a24_middle.jpg
[5397f44f21a24_middle.jpg 1]: http://cms.csdnimg.cn/article/201406/11/5397f44f21a24.jpg
[5397f47875748.jpg]: http://cms.csdnimg.cn/article/201406/11/5397f47875748.jpg
[5397f595f36c5_middle.jpg]: http://cms.csdnimg.cn/article/201406/11/5397f595f36c5_middle.jpg
[5397f595f36c5_middle.jpg 1]: http://cms.csdnimg.cn/article/201406/11/5397f595f36c5.jpg
[5397f5b833067.jpg]: http://cms.csdnimg.cn/article/201406/11/5397f5b833067.jpg
[5397f5d686edb.jpg]: http://cms.csdnimg.cn/article/201406/11/5397f5d686edb.jpg
[http_blog.csdn.net_ywh147_article_details_8954625]: http://blog.csdn.net/ywh147/article/details/8954625
[http_www.infoq.com_cn_news_2012_10_taobao-ump]: http://www.infoq.com/cn/news/2012/10/taobao-ump
[http_mysqlmusings.blogspot.jp_2013_09_brief-introduction-to-mysql-fabric.html]: http://mysqlmusings.blogspot.jp/2013/09/brief-introduction-to-mysql-fabric.html
[Link 1]: http://vnwrites.blogspot.jp/2013/09/mysqlfabric-sharding-introduction.html
[Link 2]: http://vnwrites.blogspot.in/2013/09/mysqlfabric-sharding-example.html
[Link 3]: http://vnwrites.blogspot.in/2013/09/mysqlfabric-sharding-migration.html
[Link 4]: http://vnwrites.blogspot.jp/2013/09/mysqlfabric-sharding-maintenance.html
[Mysql_]: http://www.cnblogs.com/Creator/p/3776110.html