如何设计一个高可用、高并发秒杀系统 应该如何设计其高并发架构？
目录
（1）单块架构
（2）初步的高可用架构
（3）千万级用户量的压力预估
（4）服务器压力预估
（5）业务垂直拆分
（6）用分布式缓存抗下读请求
（7）基于数据库主从架构做读写分离
（8）总结
（1）单块架构
一般一个网站刚开始建立的时候，用户量是很少的，大概可能就几万或者几十万的用户量，每天活跃的用户可能就几百或者几千个。
这个时候一般网站架构都是采用单体架构来设计的，总共就部署3台服务器，1台应用服务器，1台数据库服务器，1台图片服务器。
研发团队通常都在10人以内，就是在一个单块应用里写代码，然后写好之后合并代码，接着就是直接在线上的应用服务器上发布。 很可能就是手动把应用服务器上的Tomcat给关掉，然后替换系统的代码war包，接着重新启动Tomcat。
数据库一般就部署在一台独立的服务器上，存放网站的全部核心数据。
然后在另外一台独立的服务器上部署NFS作为图片服务器，存放网站的全部图片。应用服务器上的代码会连接以及操作数据库以及图片服务器。如下图所示：
（2）初步的高可用架构
但是这种纯单块系统架构下，有高可用问题存在，最大的问题就是应用服务器可能会故障，或者是数据库可能会故障
所以在这个时期，一般稍微预算充足一点的公司，都会做一个初步的高可用架构出来。
对于应用服务器而言，一般会集群化部署。当然所谓的集群化部署，在初期用户量很少的情况下，其实一般也就是部署两台应用服务器而已，然后前面会放一台服务器部署负载均衡设备，比如说LVS，均匀的把用户请求打到两台应用服务器上去。
如果此时某台应用服务器故障了，还有另外一台应用服务器是可以使用的，这样就避免了单点故障问题。如下图所示：
对于数据库服务器而言，此时一般也会使用主从架构，部署一台从库来从主库同步数据，这样一旦主库出现问题，可以迅速使用从库继续提供数据库服务，避免数据库故障导致整个系统都彻底故障不可用。如下图：
（3）千万级用户量的压力预估
这个假设这个网站预估的用户数是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左右的请求。
（4）服务器压力预估
大概知道了高峰期每秒钟可能会有1万左右的请求量之后，来看一下系统中各个服务器的压力预估。
一般来说一台虚拟机部署的应用服务器，上面放一个Tomcat，也就支撑最多每秒几百的请求。
按每秒支撑500的请求来计算，那么支撑高峰期的每秒1万访问量，需要部署20台应用服务。
而且应用服务器对数据库的访问量又是要翻几倍的，因为假设一秒钟应用服务器接收到1万个请求，但是应用服务器为了处理每个请求可能要涉及到平均3~5次数据库的访问。
按照3次数据库访问来算，那么每秒会对数据库形成3万次的请求。
按照一台数据库服务器最高支撑每秒5000左右的请求量，此时需要通过6台数据库服务器才能支撑每秒3万左右的请求。
图片服务器的压力同样会很大，因为需要大量的读取图片展示页面，这个不太好估算，但是大致可以推算出来每秒至少也会有几千次请求，因此也需要多台图片服务器来支撑图片访问的请求。
（5）业务垂直拆分
一般来说在这个阶段要做的第一件事儿就是 业务的垂直拆分
因为如果所有业务代码都混合在一起部署，会导致多人协作开发时难以维护。在网站到了千万级用户的时候，研发团队一般都有几十人甚至上百人。
所以这时如果还是在一个单块系统里做开发，是一件非常痛苦的事情，此时需要做的就是进行业务的垂直拆分，把一个单块系统拆分为多个业务系统，然后一个小团队10个人左右就专门负责维护一个业务系统。如下图
（6）分布式缓存扛下读请求
这个时候应用服务器层面一般没什么大问题，因为无非就是加机器就可以抗住更高的并发请求。
现在估算出来每秒钟是1万左右的请求，部署个二三十台机器就没问题了。
但是目前上述系统架构中压力最大的，其实是 数据库层面 ，因为估算出来可能高峰期对数据库的读写并发会有3万左右的请求。
此时就需要引入 分布式缓存 来抗下对数据库的读请求压力了，也就是引入Redis集群。
一般来说对数据库的读写请求也大致遵循28法则，所以每秒3万的读写请求中，大概有2.4万左右是读请求
这些读请求基本上90%都可以通过分布式缓存集群来抗下来，也就是大概2万左右的读请求可以通过 Redis集群来抗住。
我们完全可以把热点的、常见的数据都在Redis集群里放一份作为缓存，然后对外提供缓存服务。
在读数据的时候优先从缓存里读，如果缓存里没有，再从数据库里读取。这样2万读请求就落到Redis上了，1万读写请求继续落在数据库上。
Redis一般单台服务器抗每秒几万请求是没问题的，所以Redis集群一般就部署3台机器，抗下每秒2万读请求是绝对没问题的。如下图所示：
（7）基于数据库主从架构做读写分离
此时数据库服务器还是存在每秒1万的请求，对于单台服务器来说压力还是过大。
但是数据库一般都支持主从架构，也就是有一个从库一直从主库同步数据过去。此时可以基于主从架构做 读写分离 。
也就是说，每秒大概6000写请求是进入主库，大概还有4000个读请求是在从库上去读，这样就可以把1万读写请求压力分摊到两台服务器上去。
这么分摊过后，主库每秒最多6000写请求，从库每秒最多4000读请求，基本上可以勉强把压力给抗住。 如下图：
（8）总结
本文主要是探讨在千万级用户场景下的大型网站的高并发架构设计，也就是预估出了千万级用户的访问压力以及对应的后台系统为了要抗住高并发，在业务系统、缓存、数据库几个层面的架构设计以及抗高并发的分析。
但是要记住，大型网站架构中共涉及的技术远远不止这些，还包括了MQ、CDN、静态化、分库分表、NoSQL、搜索、分布式文件系统、反向代理，等等很多话题，但是本文不能一一涉及，主要是在 高并发 这个角度分析一下系统如何抗下每秒上万的请求。
如今的互联网已经在海量服务领域有了很成熟的理论，因此自己也很庆幸，能够从 0 到 1 完整践行海量服务。微视春节项目中的集卡瓜分活动，是一个典型的秒杀场景，自己参与其中，分享一些心得和总结。
秒杀系统的难点
友好的用户体验
用户不能接受破窗的体验，例如：系统超时、系统错误的提示，或者直接 404 页面
瞬时高并发流量的挑战
木桶短板理论，整个系统的瓶颈往往都在 DB，如何设计出高并发、高可用系统？
如何设计
上图是一个典型的互联网业务，用户完成一个写操作，一般会通过接入层和逻辑层，这里的服务都是无状态，可以通过平行拓展去解决高并发的问题；到了 db 层，必须要落到介质中，可以是磁盘/ssd/内存，如果出现 key 的冲突，会有一些并发控制技术，例如 cas/加锁/串行排队等。
直筒型
直筒型业务，指的是用户请求 1:1 的洞穿到 db 层，如下图所示。在比较简单的业务中，才会采用这个模型。随着业务规模复杂度上来，一定会有 db 和逻辑层分离、逻辑层和接入层分离。
漏斗型
漏斗型业务，指的是，用户的请求，从客户端到 db 层，层层递减，递减的程度视业务而定。例如当 10w 人去抢 1 个物品时，db 层的请求在个位数量级，这就是比较理想的模型。如下图所示
这个模型，是高并发的基础，翻译一下就是下面这些：
及早发现，及早拒绝
Fast Fail
前端保护后端
如何实现漏斗型系统
漏斗型系统需要从产品策略/客户端/接入层/逻辑层/DB 层全方位立体的设计。
产品策略
轻重逻辑分离，以秒杀为例，将抢到和到账分开；
抢到，是比较轻的操作，库存扣成功后，就可以成功了
到账，是比较重的操作，需要涉及到到事务操作
用户分流，以整点秒杀活动为例，在 1 分钟内，陆续对用户放开入口，将所有用户请求打散在 60s 内，请求就可以降一个数量级
页面简化，在秒杀开始的时候，需要简化页面展示，该时刻只保留和秒杀相关的功能。例如，秒杀开始的时候，页面可以不展示推荐的商品。
客户端
重试策略非常关键，如果用户秒杀失败了，频繁重试，会加剧后端的雪崩。如何重试呢？根据后端返回码的约定，有两种方法：
不允许重试错误，此时 ui 和文案都需要有一个提示。同时不允许重试
可重试错误，需要策略重试，例如二进制退避法。同时文案和 ui 需要提示。
ui 和文案，秒杀开始前后，用户的所有异常都需要有精心设计的 ui 和文案提示。例如：【当前活动太火爆，请稍后再重试】【你的货物堵在路上，请稍后查看】等
前端随机丢弃请求可以作为降级方案，当用户流量远远大于系统容量时，人工下发随机丢弃标记，用户本地客户端开始随机丢弃请求。
接入层
所有请求需要鉴权，校验合法身份
如果是长链接的服务，鉴权粒度可以在 session 级别；如果是短链接业务，需要应对这种高并发流量，例如 cache 等
根据后端系统容量，需要一个全局的限流功能，通常有两种做法：
设置好 N 后，动态获取机器部署情况 M，然后下发单机限流值 N/M。要求请求均匀访问，部署机器统一。
维护全局 key，以时间戳建 key。有热 key 问题，可以通过增加更细粒度的 key 或者定时更新 key 的方法。
对于单用户/单 ip 需要频控，主要是防黑产和恶意用户。如果秒杀是有条件的，例如需要完成 xxx 任务，解锁资格，对于获得资格的步骤，可以进行安全扫描，识别出黑产和恶意用户。
逻辑层
逻辑层首先应该进入校验逻辑，例如参数的合法性，是否有资格，如果失败的用户，快速返回，避免请求洞穿到 db。
异步补单，对于已经扣除秒杀资格的用户，如果发货失败后，通常的两种做法是：
事务回滚，回滚本次行为，提示用户重试。这个代价特别大，而且用户重试和前面的重试策略结合的话，用户体验也不大流畅。
异步重做，记录本次用户的 log，提示用户【稍后查看，正在发货中】，后台在峰值过后，启动异步补单。需要服务支持幂等
对于发货的库存，需要处理热 key。通常的做法是，维护多个 key，每个用户固定去某个查询库存。对于大量人抢红包的场景，可以提前分配。
存储层
对于业务模型而言，对于 db 的要求需要保证几个原则：
可靠性
主备：主备能互相切换，一般要求在同城跨机房
异地容灾：当一地异常，数据能恢复，异地能选主
数据需要持久化到磁盘，或者更冷的设备
一致性
对于秒杀而言，需要严格的一致性，一般要求主备严格的一致。
实践——微视集卡瓜分系统
微视集卡瓜分项目属于微视春节项目之一。用户的体验流程如下：
架构图
客户端主要是微视主 app 和 h5 页面，主 app 是入口，h5 页面是集卡活动页面和瓜分页面。
逻辑部分为分：发卡来源、集卡模块、奖品模块，发卡来源主要是任务模块；集卡模块主要由活动模块和集卡模块组成。瓜分部分主要在活动控制层。
奖品模块主要是发钱和其他奖品。
瓜分降级预案
为了做好瓜分时刻的高并发，对整个系统需要保证两个重要的事情：
全链路梳理，包括调用链的合理性和时延设置
降级服务预案分析，提升系统的鲁棒性
如下图所示，是针对瓜分全链路调用分析如下图，需要特别说明的几点：
时延很重要，需要全链路分析。不但可以提高吞吐量，而且可以快速暴露系统的瓶颈。
峰值时刻，补单逻辑需要关闭，避免加剧雪崩。
我们的降级预案大概如下：
一级预案，瓜分时刻前后 5 分钟自动进入：
入口处 1 分钟内陆续放开入口倒计时，未登录用户不弹入口
主会场排队，进入主会场以 100wqps 为例，超过了进入排队，由接入层频控控制
拉取资格接口排队，拉取资格接口 100wqps，超过了进入排队，由接入层频控控制
抢红包排队，抢红包 100wqps，超过了进入排队，由接入层频控控制
红包到账排队，如果资格扣除成功，现金发放失败，进入排队，24 小时内到账。异步补单
入口处调用后端非关键 rpc:ParticipateStatus，手动关闭
异步补单逻辑关闭。
二级预案，后端随机丢请求，接入层频控失效或者下游服务过载，手动开启进入
三级预案，前端随机丢请求，后端服务过载或者宕机进入。手动开启
综上，整个瓜分时刻体验如下所示：
回顾下漏斗模型，总结下整个实践
总结
“做程序员，圈子和学习最重要”因为有有了圈子可以让你少走弯路，扩宽人脉，扩展思路，学习他人的一些经验及学习方法！同时在这分享一下是一直以来整理的Java后端进阶笔记文档和学习资料免费分享给大家！
小伙伴们有兴趣想了解内容和更多相关学习资料的请点赞收藏+评论转发+关注我，后面会有很多干货。我有一些面试题、架构、设计类资料可以说是程序员面试必备！所有资料都整理到网盘了，需要的话欢迎下载！私信我回复【学习】即可免费获取
