mysql 在大型应用中的架构演变

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云数据库 Tair(兼容Redis),内存型 2GB
简介:

文正整理自:http://www.csdn.net/article/2014-06-10/2820160

可扩展性

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

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

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

可扩展性的理想状态

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

架构的演变

V1.0  简单网站架构

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

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

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

只有当以上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主从架构完全能够胜任。

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

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 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个有经销权的地区,如下表所示: 

 

 

地区  商店ID 号 
北区  3, 5, 6, 9, 17 
东区  1, 2, 10, 11, 19, 20 
西区  4, 12, 13, 14, 18 
中心区  7, 8, 15, 16 

业务希望能够把一个地区的所有数据组织到一起来搜索,这种场景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的门票。

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

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

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

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

V more ?

等待革命……

淘宝用例 

Mysql  Fabric

本文转自 张冲andy 博客园博客,原文链接: http://www.cnblogs.com/andy6/p/5789252.html   ,如需转载请自行联系原作者
相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
打赏
0
0
0
0
100
分享
相关文章
MySQL进阶突击系列(03) MySQL架构原理solo九魂17环连问 | 给大厂面试官的一封信
本文介绍了MySQL架构原理、存储引擎和索引的相关知识点,涵盖查询和更新SQL的执行过程、MySQL各组件的作用、存储引擎的类型及特性、索引的建立和使用原则,以及二叉树、平衡二叉树和B树的区别。通过这些内容,帮助读者深入了解MySQL的工作机制,提高数据库管理和优化能力。
MySQL的架构与SQL语句执行过程
MySQL架构分为Server层和存储引擎层,具有高度灵活性和可扩展性。Server层包括连接器、查询缓存(MySQL 8.0已移除)、分析器、优化器和执行器,负责处理SQL语句;存储引擎层负责数据的存储和读取,常见引擎有InnoDB、MyISAM和Memory。SQL执行过程涉及连接、解析、优化、执行和结果返回等步骤,本文详细讲解了一条SQL语句的完整执行过程。
38 3
MySQL原理简介—2.InnoDB架构原理和执行流程
本文介绍了MySQL中更新语句的执行流程及其背后的机制,主要包括: 1. **更新语句的执行流程**:从SQL解析到执行器调用InnoDB存储引擎接口。 2. **Buffer Pool缓冲池**:缓存磁盘数据,减少磁盘I/O。 3. **Undo日志**:记录更新前的数据,支持事务回滚。 4. **Redo日志**:确保事务持久性,防止宕机导致的数据丢失。 5. **Binlog日志**:记录逻辑操作,用于数据恢复和主从复制。 6. **事务提交机制**:包括redo日志和binlog日志的刷盘策略,确保数据一致性。 7. **后台IO线程**:将内存中的脏数据异步刷入磁盘。
|
17天前
|
类似ComfyUI和Midjourney这样的文生图图生图应用的API与服务架构该怎么设计
文生图图生图应用的API与服务架构分析。或和微服务类似,但是不同。ComfyUI其 API 架构设计为我们理解此类应用提供了很好的参考模型。但距离生产级别的应用差距还有很远。
48 0
云卓越架构:云上网络稳定性建设和应用稳定性治理最佳实践
本文介绍了云上网络稳定性体系建设的关键内容,包括面向失败的架构设计、可观测性与应急恢复、客户案例及阿里巴巴的核心电商架构演进。首先强调了网络稳定性的挑战及其应对策略,如责任共担模型和冗余设计。接着详细探讨了多可用区部署、弹性架构规划及跨地域容灾设计的最佳实践,特别是阿里云的产品和技术如何助力实现高可用性和快速故障恢复。最后通过具体案例展示了秒级故障转移的效果,以及同城多活架构下的实际应用。这些措施共同确保了业务在面对网络故障时的持续稳定运行。
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
96 3
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
367 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等