平时我们遇到的高并发场景：
案例一：12306抢票，这个属于有限资源出现的供小于求的情况
案例二：股票交易系统，数据量大、增量大、体量大
案例三:类似于周边(商家、景点等)接入，属于单次计算量比较大
下面我们从非程序实现的角度来分析下面对高流量的访问需求下的设计思路：
漏斗型系统：
-
产品层:逻辑分离、用户分流、页面简化
-
客户端：重试策略、UI文案
-
接入层：鉴权、限流
-
逻辑层：逻辑校验、异步、缓存
-
存储：CAP理论(可靠性、一致性)
不要忽视下游
我们还需要做全局的考虑，比如我们在做一个活动系统的时候，并不是这一个系统的在扛流量，还有订单、库存、消息等系统在支持者活动，所以一定不要忽视了一些下游的一些设施。
更好的交互
出现这样的文案，给用户的感觉就是系统崩了，这都是我们程序员经常写出的文案，比如我们讲网络议程修改了商品已经卖完，请你下次再来，这就从用户侧给了管理预期。
延迟交互
延迟交互：比如你没有抢到商品，我可以给你发一个5元钱的代金券，可以在活动里写明，代金券24小时内到账，这就将券系统摘出去了，不需要做正在的发放，减小了压力；
风控:其实是需要一定的时间去运算并识别的系统，短时间内不太好实现，所以就可以将跟风控有关系的校验性的点延后，前面只给一个预期，也完全是可以的。
压测
-
系统的承载力要心里有底
-
不能全靠压测，毕竟不是真实的场景
-
有限保障存活，服务别挂
-
交互来兜底
附上一个完整的思路
-
场景分析：什么是秒杀？特点是什么？
顺时流量高、常态流量低、库存少、业务流程简单。
-
技术难点？对现有业务有冲击、需要控制开始的时间、页面的流量会激增。我们需要去评估和预测这些点。
-
系统:客户端：前后端分离、人为的不要去忽视这块；
接入层：入口页面、重复提交、交互(人性化的设计、安慰型按钮)；
API系统：限流、限流、还是限流。削峰、缓存、异步。
-
监控：能否做到秒级监控：正在的秒级监控 还是平均秒级监控
作用：反应系统的状态。
-
日志：全、有设计、可追溯 ，通常我们对日志比较随意，能看，能用，能定位问题就可以了，这些可能是不够的， 常规的设计是 什么时候、什么接口、谁、做了什么事情、前提是什么、结果是什么。
-
安全：这里主要指的是风控。第一风控是个系统，可以认为是秒杀的依赖系统，要做好降级，系统设计看前面就好了，还有识别：比如我们希望我们的优惠不会被黄牛党带走，而是真正给到的所需要的人。
-
运营：callcenter万岁！事中分析(数据回收、快速分析)、售后运营(补救、客诉)。
原文始发于微信公众号（二进制跳动）：类似秒杀场景下瞬时大流量并发设计思路
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/166856.html
