对于一个刚上线的互联网项目来说,由于前期活跃用户数量并不多,并发量也相对较小,所以此时企业一般都会选择将所有数据存放在 一个数据库 中进行访问操作。但随着后续的市场推广力度不断加强,用户数量和并发量不断上升,这时如果仅靠一个数据库来支撑所有访问压力,几乎是在 自寻死路 。所以一旦到了这个阶段,大部分 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 个子表进行存储和维护,这样的设计在国内一流的互联网企业比较常见
高并发网站原理
转载
提问和评论都可以,用心的回复会被更多人看到
评论
发布评论
相关文章
-
构建高并发网站-网站架构(架构优化)
构建高并发网站-网站架构
构建 网站 高并发 -
构建高并发网站-基本概念
构建高并发网站-基本概念
构建 网站 高并发 -
高并发网站架构解决方案
一个小型的网站,比如个人网站,可以使用最简单的html静态页面就实现了,配合一些图片达到美化效果,所有的页面均存放在一个目录
数据库 服务器 负载均衡 apache 应用服务器 -
大型站点高并发架构 高并发网站架构图
高并发,高可用,可扩展性软件架构
大型站点高并发架构 软件架构 高并发 可扩展性