Mysql在大型网站的应用架构演变在大型网站的应用架构演变
写在最前写在最前:
本文主要描述在网站的不同的并发访问量级下,Mysql架构的演变
可扩展性可扩展性
架构的可扩展性往往和并发是息息相关,没有并发的增长,也就没有必要做高可扩展性的架构,这里对可扩展性进行简单介绍
一下,常用的扩展手段有以下两种
Scale-up :纵向扩展,通过替换为更好的机器和资源来实现伸缩,提升服务能力
Scale-out :横向扩展, 通过加节点(机器)来实现伸缩,提升服务能力
对于互联网的高并发应用来说,无疑Scale out才是出路,通过纵向的买更高端的机器一直是我们所避讳的问题,也不是长久
之计,在scale out的理论下,可扩展性的理想状态是什么?
可扩展性的理想状态可扩展性的理想状态
一个服务,当面临更高的并发的时候,能够通过简单增加机器来提升服务支撑的并发度,且增加机器过程中对线上服务无影响
(no down time),这就是可扩展性的理想状态!
架构的演变
V1.0 简单网站架构简单网站架构
一个简单的小型网站或者应用背后的架构可以非常简单, 数据存储只需要一个mysql instance就能满足数据读取和写入需求
(这里忽略掉了数据备份的实例),处于这个时间段的网站,一般会把所有的信息存到一个database instance里面。
在这样的架构下,我们来看看数据存储的瓶颈是什么?
1.数据量的总大小 一个机器放不下时
2.数据的索引(B+ Tree)一个机器的内存放不下时
3.访问量(读写混合)一个实例不能承受
只有当以上3件事情任何一件或多件满足时,我们才需要考虑往下一级演变。 从此我们可以看出,事实上对于很多小公司小应
用,这种架构已经足够满足他们的需求了,初期数据量的准确评估是杜绝过度设计很重要的一环,毕竟没有人愿意为不可能发
生的事情而浪费自己的经历。
这里简单举个我的例子,对于用户信息这类表 (3个索引),16G内存能放下大概2000W行数据的索引,简单的读和写混合访
问量3000/s左右没有问题,你的应用场景是否
V2.0 垂直拆分垂直拆分
一般当V1.0 遇到瓶颈时,首先最简便的拆分方法就是垂直拆分,何谓垂直?就是从业务角度来看,将关联性不强的数据拆分
到不同的instance上,从而达到消除瓶颈的目标。以图中的为例,将用户信息数据,和业务数据拆分到不同的三个实例上。对
于重复读类型比较多的场景,我们还可以加一层cache,来减少对DB的压力。