千万级用户的大型网站，如何进行服务器压力预估？

news2024/10/5 4:30:12

前言：一般情况下，单台Tomcat服务器每秒支撑500请求，单台MySQL数据库每秒支撑5000左右的请求，单台Redis缓存支撑每秒几万请求。

1、千万级用户量的压力预估

假设大型网站预估用户数是1000万，那么根据28法则，每天会来访问这个网站的用户占到20%，也就是200万用户每天会过来访问。通常假设平均每个用户每次过来会有30次的点击，那么总共就有6000万的点击（PV）。每天24小时，根据28法则，每天大部分用户最活跃的时间集中在（24小时 * 0.2）≈ 5小时内，而大部分用户指的是（6000万点击 * 0.8 ≈ 5000万点击）也就是说，在5小时内会有5000万点击进来。

换算下来，在那5小时的活跃访问期内，大概每秒钟会有3000左右的请求量，然后这5小时中可能又会出现大量用户集中访问的高峰时间段。比如在集中半个小时内大量用户涌入形成高峰访问。根据线上经验，一般高峰访问是活跃访问的2~3倍。假设我们按照3倍来计算，那么5小时内可能有短暂的峰值会出现每秒有10000左右的请求。

2、服务器压力预估

大概知道了高峰期每秒钟可能会有1万左右的请求量之后，来看一下系统中各个服务器的压力预估。一般来说一台虚拟机部署的应用服务器，上面放一个Tomcat，也就支撑最多每秒几百的请求。按每秒支撑500的请求来计算，那么支撑高峰期的每秒1万访问量，需要部署20台应用服务。而且应用服务器对数据库的访问量又是要翻几倍的，因为假设一秒钟应用服务器接收到1万个请求，但是应用服务器为了处理每个请求可能要涉及到平均3~5次数据库的访问。按照3次数据库访问来算，那么每秒会对数据库形成3万次的请求。

按照一台数据库服务器最高支撑每秒5000左右的请求量，此时需要通过6台数据库服务器才能支撑每秒3万左右的请求。

3、分布式缓存扛下读请求

这个时候应用服务器层面一般没什么大问题，因为无非就是加机器就可以抗住更高的并发请求。

现在估算出来每秒钟是1万左右的请求，部署个二三十台机器就没问题了。但是目前上述系统架构中压力最大的，其实是数据库层面，因为估算出来可能高峰期对数据库的读写并发会有3万左右的请求。此时就需要引入分布式缓存来抗下对数据库的读请求压力了，也就是引入Redis集群。

一般来说对数据库的读写请求也大致遵循28法则，所以每秒3万的读写请求中，大概有2.4万左右是读请求这些读请求基本上90%都可以通过分布式缓存集群来抗下来，也就是大概2万左右的读请求可以通过 Redis集群来抗住。我们完全可以把热点的、常见的数据都在Redis集群里放一份作为缓存，然后对外提供缓存服务。在读数据的时候优先从缓存里读，如果缓存里没有，再从数据库里读取。这样2万读请求就落到Redis上了，1万读写请求继续落在数据库上。

Redis一般单台服务器抗每秒几万请求，所以Redis集群一般就部署2台机器，抗下每秒2万读请求是绝对没问题的。

4、基于数据库主从架构做读写分离

此时数据库服务器还是存在每秒1万的请求，对于单台服务器来说压力还是过大。但是数据库一般都支持主从架构，也就是有一个从库一直从主库同步数据过去。此时可以基于主从架构做读写分离。也就是说，每秒大概6000写请求是进入主库，大概还有4000个读请求是在从库上去读，这样就可以把1万读写请求压力分摊到两台服务器上去。

这么分摊过后，主库每秒最多6000读写请求，从库每秒最多4000读请求，基本上可以勉强把压力给抗住。