对于一个刚上线的互联网项目来说,由于前期活跃用户数量并不多,并发量也相对较小,所以此时企业一般都会选择将所有数据存放在 一个数据库 中进行访问操作。但随着后续的市场推广力度不断加强,用户数量和并发量不断上升,这时如果仅靠一个数据库来支撑所有访问压力,几乎是在 自寻死路 。所以一旦到了这个阶段,大部分
Mysql DBA
就会将数据库设置成 读写分离状态 ,也就是一个
Master
节点对应多个
Salve
节点。经过
Master/Salve
模式的设计后,完全可以应付单一数据库无法承受的负载压力,并将访问操作分摊至多个
Salve
节点上,实现真正意义上的读写分离。但大家有没有想过,单一的
Master/Salve
模式又能抗得了多久呢?如果用户数量和并发量出现 量级 上升,单一的
Master/Salve
模式照样抗不了多久,毕竟一个
Master
节点的负载还是相对比较高的。为了解决这个难题,
Mysql DBA
会在单一的
Master/Salve
模式的基础之上进行数据库的 垂直分区 (分库)。所谓垂直分区指的是可以根据业务自身的不同,将原本冗余在一个数据库内的业务表拆散,将数据分别存储在不同的数据库中,同时仍然保持
Master/Salve
模式。经过垂直分区后的
Master/Salve
模式完全可以承受住难以想象的高并发访问操作,但是否可以永远 高枕无忧 了?答案是否定的,一旦业务表中的数据量大了,从维护和性能角度来看,无论是任何的
CRUD
操作,对于数据库而言都是一件极其耗费资源的事情。即便设置了索引, 仍然无法掩盖因为数据量过大从而导致的数据库性能下降的事实 ,因此这个时候
Mysql DBA
或许就该对数据库进行 水平分区 (分表,
sharding
),所谓水平分区指的是将一个业务表拆分成多个子表,比如
user_table0
、
user_table1
、
user_table2
。子表之间通过某种契约关联在一起,每一张子表均按段位进行数据存储,比如
user_table0
存储
1-10000
的数据,而
user_table1
存储
10001-20000
的数据,最后
user_table3
存储
20001-30000
的数据。经过水平分区设置后的业务表,必然能够将原本一张表维护的海量数据分配给
N
个子表进行存储和维护,这样的设计在国内一流的互联网企业比较常见
高并发网站原理
最新推荐文章于 2022-03-07 18:30:11 发布