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

news/2024/5/21 15:55:34/文章来源:https://cxydev.blog.csdn.net/article/details/102738641

点击上方 蓝字字体 加关注吧

作者：大熊先生

原文：http://www.cnblogs.com/Creator/p/3776110.html

作为最流行的开源数据库，MySQL被广泛应用在Web应用程序以及其它中小型项目上。然而不可忽视的是，在许多大型IT公司中，MySQL在高度优化和定制化后，已逐渐偏离了原有的开源版本，更像是一种分支，比如Facebook前不久开源的WebScaleSQL。下面是来自博主大熊先生的一篇文章：

写在最前可扩展性无疑Scale out才是出路，通过纵向的买更高端的机器一直是我们所避讳的问题，也不是长久之计，在scale out的理论下，可扩展性的理想状态是什么？可扩展性的理想状态能够通过简单增加机器来提升服务支撑的并发度，且增加机器过程中对线上服务无影响(no down time)，这就是可扩展性的理想状态！架构的演变

V1.0 简单网站架构

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

640?wx_fmt=png 在这样的架构下，我们来看看数据存储的瓶颈是什么？V2.0 垂直拆分

640?wx_fmt=png 在这样的架构下，我们来看看数据存储的瓶颈是什么？V3.0 主从架构在这样的架构下，我们来看看数据存储的瓶颈是什么？V4.0 水平拆分

640?wx_fmt=png 数据如何路由？1. Range拆分2. List拆分

假定有20个音像店，分布在4个有经销权的地区，如下表所示： 640?wx_fmt=jpeg 3. Hash拆分数据拆分后引入的问题：数据水平拆分引入的问题主要是只能通过sharding key来读写操作，例如以userid为sharding key的切分例子，读userid的详细信息时，一定需要先知道userid,这样才能推算出再哪个cluster进而进行查询，假设我需要按username进行检索用户信息，需要引入额外的反向索引机制（类似HBASE二级索引），如在redis上存储username->userid的映射，以username查询的例子变成了先通过查询username->userid，再通过userid查询相应的信息。在这样的架构下，我们来看看数据存储的瓶颈是什么？V5.0 云计算腾飞（云数据库） 可配置性，可扩展性，多用户存储结构设计称为'three headed monster'。可配置性和多用户存储结构设计在Mysql saas这个问题中并不是特别难办的一件事情，所以这里重点说一下可扩展性。 1. 扩容缩容对前端APP透明(业务代码不需要任何改动)；2. 扩容缩容全自动化且对在线服务无影响，那么他就拿到了作为Saas的门票。 640?wx_fmt=png

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

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

640?wx_fmt=jpeg 需要扩容/缩容时，挂上一个Sync slave，开始全量同步+增量同步，等待一段时间追数据。以扩容为例，若扩容后的服务和扩容前数据已经基本同步了，这时候如何做到切换对业务无影响？其实关键点还是在引入的proxy，这个问题转换为了如何让proxy做热切换后端的问题。这已经变成一个非常好处理的问题了。甲骨文宣布推出MySQL Fabric，在对应的资料部分我也放了很多Fabric的资料，有兴趣的可以看看，说不定会是以后的一个解决云数据库扩容缩容的手段。V more ?等待革命...