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

  • 时间:
  • 浏览:1

只能当以上3件事情任何一件或多件满足时,亲戚大伙才时要考虑往下一级演变。 从此亲戚大伙能只能看出,事实上对于一些一些小公司小应用,你这些架构意味着足够满足亲戚大伙的需求了,初期数据量准确评估是杜绝过度设计不怎样才能要的一环,毕竟没有人我想要为不意味着居于的事情而浪费个人的精力。

5个多 简单的小型网站意味着应用身前的架构能只能非常简单,数据存储只时要5个多 Mysql Instance就能满足数据读取和写入需求(这里忽略掉了数据备份的实例),居于你这些时间段的网站,一般会把所有的信息存到5个多 Database Instance里面。

在以前的架构下,亲戚大伙来看看数据存储的瓶颈是哪些?

其中Sync Slave对于Original Master来说,和5个多 普通的Mysql Slave没有任何区别,一些时要任何额外的区分对待。时要扩容/缩容时,挂上5个多 Sync slave,刚开始全量同步+增量同步,守候一段时间追数据。以扩容为例,若扩容后的服务和扩容前数据意味着基本同步了,这以前怎样才能做到切换对业务无影响? 人太好关键点还是在引入的Proxy,你这些问題转换为了怎样才能让Proxy做热切换后端的问題。这意味着变成5个多 非常好避免的问題了。

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

注:这里不再叫单个实例 一些叫5个多 Cluster 代表带有主从的5个多 小MySQL集群。

淘宝用例 

数据水平拆分引入的问題主一些只能通过sharding key来读写操作,类事以UserId为sharding key的切分例子,读UserId的完正信息时,一定时要先知道UserId,以前也能推算出在哪个Cluster进而进行查询,假设我时要按UserName进行检索用户信息,时要引入额外的反向索引机制(类事HBase二级索引),如在Redis上存储username->userid的映射,以UserName查询的例子变成了先通过查询username->userid,再通过userid查询相应的信息。

博文链接:Mysql在大型网站的应用架构演变 

可扩展性的理想请况

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

在你这些拆分理念上搭建起来的架构,理论上不居于瓶颈(sharding key能确保各Cluster流量相对均衡的前提下)。不过确有一件恶心的事情,那一些Cluster扩容的以前重做数据的成本,如我以前有5个Cluster,一些现在我的数据增长比较快,我时要6个Cluster,没有亲戚大伙时要将每个Cluster 一拆为二,一般的做法是:

假定有20个音像店,分布在5个多 有经销权的地区,如下表所示: 

另外值得关注的是:2014年5月28日——为了满足当下对Web及云应用需求,甲骨文回应推出MySQL Fabric,在对应的资料偏离 我也放了一些一些Fabric的资料,有兴趣的能只能看看,说不定会是以前的5个多 避免云数据库扩容缩容的手段。 

有没有类事飞机空中加油的感觉,这是5个多 脏活,累活,容易出问題的活,为了避免你这些,亲戚大伙一般在最刚开始的以前,设计足够多的sharding cluster来避免意味着的Cluster扩容这件事情。

实际上你这些做法很简单,一些亲戚大伙太满忽略了5个多 额外的隐患,那一些数据不一致的隐患。存储在Redis里的username->userid和存储在MySQL里的userid->username时要需一些一致的,你这些保证起来一些一些以前是一件比较困难的事情,举个例子来说,对于修改用户名你这些场景,你时要一齐修改Redis和Mysql。你这些个多 东西是没有做到事务保证的,如MySQL操作成功,一些Redis却操作失败了(分布式事务引入成本较高)。对于互联网应用来说,可用性是最重要的,一致性是其次,一些一些也能容忍几滴 的不一致再次冒出. 毕竟从占比来说,类事的不一致的比例能只能微乎其微到忽略不计。(一般写更新也会采用mq来保证直到成功为止才停止重试操作)

此类架构主要避免V2.0架构下的读问題,通过给Instance挂数据实时备份的思路来迁移读取的压力,在MySQL的场景下一些通过主从组织结构,主库抗写压力,通过从库来分担读压力,对于写少读多的应用,V3.0主从架构完正也能胜任。

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

这里简单举个我的例子,对于用户信息类事表 (5个索引),16G内存能放下,要花费800万行数据的索引,简单的读和写混合访问量800/s左右没有问題,你的应用场景否是?

List拆分与Range拆分思路一样,时要通过给不同的sharding key来路由到不同的Cluster,一些具体法律法子一些不同。List主要用来做sharding key时要连续区间的序列落到5个多 Cluster的请况,如以下场景:

在以前的架构下,亲戚大伙来看看数据存储的瓶颈是哪些?很明了,写入量主库只能承受。

5个多 服务,当面临更高的并发的以前,也能通过简单增加机器来提升服务支撑的并发度,且增加机器过程中对线上服务无影响(no down time),你这些些可扩展性的理想请况! 

云计算现在是各大IT公司组织组织结构作为节约成本的5个多 突破口,对于数据存储的MySQL来说,怎样才能让其成为5个多 SaaS是关键点。在MS的官方文档中,把构建5个多 足够性性性成熟是什么是什么的SaaS(MS简单列出了SAAS应用的4级性性性成熟是什么是什么度)所面临的5个主要挑战:可配置性,可扩展性,多用户存储组织结构设计称为"three headed monster"。可配置性和多用户存储组织结构设计在MySQL SaaS你这些问題中并时要不怎样才能难办的一件事情,一些一些这里重点说一下可扩展性。

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

没有,以前架构中的数据该怎样才能路由?

对于架构实现的关键点,时要满足对业务透明,扩容缩容对业务不时要任何改动,没有就时要eat our own dog food,在你MySQL SaaS组织组织结构避免你这些问題,一般的做法是亲戚大伙时要引入5个多 Proxy,Proxy来解析SQL协议,按sharding key来寻找Cluster,判断是读操作还是写操作来请求Master意味着Slave,你这些切组织组织结构的细节都由Proxy来屏蔽。

一般当V1.0 遇到瓶颈时,首先最简便的拆分法律法子一些垂直拆分,何谓垂直?一些从业务深度1来看,将关联性不强的数据拆分到不同的Instance上,从而达到消除瓶颈的目标。以图中的为例,将用户信息数据,和业务数据拆分到不同的5个多 实例上。对于重复读类型比较多的场景,亲戚大伙还能只能加一层Cache,来减少对DB的压力。

3. Hash拆分

在以前的架构下,亲戚大伙来看看数据存储的瓶颈是哪些?

对于互联网的高并发应用来说,无疑横向扩展才是出路,一齐通过纵向购买更高端的机器也5个多劲是亲戚大伙所避讳的问題,也时要长久之计。没有,在横向扩展的理论下,可扩展性的理想请况是哪些?

守候革命……

在以前的架构下,亲戚大伙来看看数据存储的瓶颈是哪些?

单实例单业务依然居于V1.0所述瓶颈:遇到瓶颈时能只能考虑往本文更高V版本升级,若是读请求意味着达到性能瓶颈能只能考虑往V3.0升级, 一些瓶颈考虑往V4.0升级。

1. Range拆分 

sharding key按连续区间段路由,一般用在有严格自增ID需求的场景上,如UserId、UserId Range的小例子,以UserId 800万为Range进行拆分:1号Cluster的UserId是1-800万,2号Cluster  UserId是 801万-8000万。

Mysql  Fabric

2. List拆分

MySQL作为5个多 SaaS服务,在架构演变为V4.0以前,依赖良好的sharding key设计,意味着不再居于扩展性问題,一些他在面对扩容缩容时,有一些脏活时要干,而作为SaaS,太满能避免扩容缩容你这些问題,一些一些而且能把V4.0的脏活变成:第1,扩容缩容对前端APP透明(业务代码不时要任何改动);第2,扩容缩容全自动化且对在线服务无影响。意味着实现了这两点,没有他就拿到了作为SaaS的门票。

可扩展性

文正分派自:http://www.csdn.net/article/2014-06-10/2820180

4. 数据拆分后引入的问題