前言：一般情况下，单台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读请求，基本上可以勉强把压力给抗住。
总结
本文主要是探讨在千万级用户场景下的大型网站的高并发架构设计，也就是预估出了千万级用户的访问压力以及对应的服务端系统为了要抗住高并发，在业务系统、缓存、数据库几个层面的架构设计以及抗高并发的分析。
大型网站架构中涉及的技术远远不止这些，还包括了MQ、CDN、静态化、分库分表、NoSQL、搜索、大数据实时计算、微服务架构，等等很多话题，但是本文就不一一涉及，主要是在高并发这个角度分析一下系统如何抗下每秒上万的请求。
参考链接：
【干货走一波】千万级用户的大型网站，应该如何设计其高并发架构？
