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

点击上方“全球Java架构师*”，选择“设为星标”

技术文章第一时间送达！

写在最前:

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

可扩展性

架构的可扩展性往往和并发是息息相关，没有并发的增长，也就没有必要做高可扩展性的架构，这里对可扩展性进行简单介绍一下，常用的扩展手段有以下两种 Scale-up :   纵向扩展，通过替换为更好的机器和资源来实现伸缩，提升服务能力 Scale-out : 横向扩展,  通过加节点（机器）来实现伸缩，提升服务能力 Scale out才是出路 ，通过纵向的买更高端的机器一直是我们所避讳的问题，也不是长久之计，在scale out的理论下，可扩展性的理想状态是什么？

可扩展性的理想状态

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

架构的演变

V1.0  简单网站架构

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

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

V2.0 垂直拆分

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

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

1.单实例单业务 依然存在V1.0所述瓶颈

遇到瓶颈时可以考虑往本文更高V版本升级, 若是读请求导致达到性能瓶颈可以考虑往V3.0升级， 其他瓶颈考虑往V4.0升级

V3.0  主从架构

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

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

1.写入量主库不能承受

V4.0  水平拆分

对于V2.0 V3.0方案遇到瓶颈时，都可以通过水平拆分来解决，水平拆分和垂直拆分有较大区别，垂直拆分拆完的结果，在一个实例上是拥有全量数据的，而水平拆分之后，任何实例都只有全量的1/n的数据，以下图Userinfo的拆分为例，将userinfo拆分为3个cluster，每个cluster持有总量的1/3数据，3个cluster数据的总和等于一份完整数据（注：这里不再叫单个实例 而是叫一个cluster 代表包含主从的一个小mysql集群）

数据如何路由？

1.Range拆分

 sharding key按连续区间段路由，一般用在有严格自增ID需求的场景上，如Userid, Userid Range的小例子：以userid 3000W 为Range进行拆分   1号cluster  userid 1-3000W  2号cluster  userid   3001W-6000W

2.List拆分

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

3.Hash拆分

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

数据拆分后引入的问题：

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

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

V5.0  云计算 腾飞  

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

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

百度也有类似的解决方案，见文章最后资料部分链接 扩容缩容全自动化且对在线服务无影响 ；扩容缩容对应到的数据操作即为数据拆分和数据合并，要做到完全自动化有非常多不同的实现方式，总体思路和V4.0介绍的瓶颈部分有关，这里就不细展开讲了。以扩容为例，扩容后的服务和扩容前数据已经基本同步了，这时候如何做到切换对业务无影响？其实关键点还是在引入的proxy,这个问题转换为了如何让proxy做热切换后端的问题。这已经变成一个非常好处理的问题了.

其他资料

百度Dbproxy设计   http://tech.it168.com/a2012/0413/1337/000001337034.shtml淘宝RDS 云数据库设计：http://blog.csdn.net/ywh147/article/details/8954625     http://www.infoq.com/cn/news/2012/10/taobao-umpMysql  Fabrichttp://mysqlmusings.blogspot.jp/2013/09/brief-introduction-to-mysql-fabric.htmlhttp://vnwrites.blogspot.jp/2013/09/mysqlfabric-sharding-introduction.htmlhttp://vnwrites.blogspot.in/2013/09/mysqlfabric-sharding-example.htmlhttp://vnwrites.blogspot.in/2013/09/mysqlfabric-sharding-migration.htmlhttp://vnwrites.blogspot.jp/2013/09/mysqlfabric-sharding-maintenance.html

看到这里，说明你喜欢本文

你的转发，是对我最大的鼓励！在看亦是支持↓