01｜直面痛点：秒杀系统的挑战和设计原则

1：秒杀系统和其它业务系统隔离。 2：扣减库存，不能超卖。 3：防止非法用户刷单。 4：降级，熔断。

秒杀系统会进行压测吗？压测值要如何评估和设定？希望老师指点

1、瞬间高并发； 2、活动页面静态化（减少不必要的服务端请求）； 3、使用CDN加速（全称是Content Delivery Network，即内容分发网络），降低网络拥塞，提高用户访问响应速度和命中率； 4、可以使用分布式锁、缓存预热等方式避免大量请求同时访问数据库， 5、扣减库存问题，可以通过在redis中写lua脚本来避免超卖等问题 6、限流：对同一用户限流、对同一ip限流、对接口限流、加验证码、提高业务门槛等

以上的都是基于明确有商品要秒杀而去搭建系统。而对于某些突然火爆的商品（预期之外的），系统层面应该做哪些预备方案？

老师，流量激增和热点都是 主要是读 请求吗？ 下单和和抢购 这两个写 操作 之前都会对其进行限流吗 ？是可以理解为 抗住大量查询 减缓写到数据库的压力

瞬时流量之后的数据怎么存储，如何做补偿

请问整个课程时长多少？怎么联系销售呢？

根据自己对于秒杀业务的了解，除了瞬时的流量，还需要考虑如下的点： 1）秒杀系统从入口到流量都需要与普通的入口进行隔离，防止系统间的影响； 2）需要实现多地多机房部署，保证系统的高可用； 3）实现分布式事务，保证用户下单、库存、扣款等操作的事务性，防止出现超买超卖问题； 4）增加风控能力，防刷； 5）增加限流、熔断和降级方案； 6）热点商品的自动发现与自动预警机制； 7）人工补偿机制

**1）秒杀业务逻辑是怎样的？** - 商家拿出稀缺商品，事先在秒杀的运营系统中设置好活动的开始、结束时间，以及投入的库存。 - 活动开始之后，用户可以通过活动抢购入口（商品详情页或者链接），进入到活动的结算页，然后点击下单，完成商品的抢购  **2）如果想对流量有个预期上限，方便做备战工作，那么应该怎么做？** - 加上预约功能，预约的才有抢购资格 **3）如果业务场景更加复杂怎么办？** - 联合风控，在参加活动时校验用户资质，踢掉黄牛以及有过不良行为的人，尽量将资源给到优质用户。 **4）如果业务再复杂些呢？** - 可以搭配限购开展活动，控制个人维度下一段时间内的购买数，让抢购成功的快乐触达更多的人。 **5）秒杀系统面临的挑战有哪些？** - 巨大的瞬时流量 - 短短几秒中，几十上百万的流量 - 热点数据问题 - 热门商品数据库的并发访问量太大，数据库，还是分布式缓存，都无法支持几十万、上百万对同一个 key 的读写 - 刷子流量 - 刷子通过浏览器或是抓包工具拿到请求数据，自己通过程序实现接口的直接调用，并可以设置请求的频率。 **6）秒杀系统如何设计？** **6.1）一次 HTTP 请求所经过的链路路径有哪些？** **6.1.1）DNS的作用是什么？** - 域名解析，将你的域名请求指定一个实际的IP来处理，一般浏览器会缓存这个IP一段时间。下次请求来的时候直接用这个IP来建立连接，就不用麻烦DNS了。 **6.1.2）Nginx的作用是什么？** 被 DNS 指定来处理请求的 IP - 反向代理 - 负载均衡 - 也可以用来做静态资源服务器 - Nginx 接收到客户端请求后，根据负载均衡算法（默认是轮询）将请求分发给下游的 Web 服务。 **6.1.2）Web 服务的作用是什么？** - 实际业务的增删改查都在这里 **6.1.3）RPC 服务的作用是什么？** - 基础不牢，地动山摇。这个是实际业务的地基。仅供内部服务间调用，不对外开放，安全性高。 **7）用户的一次抢购过程中，每次和系统的交互都要做什么事情？** 商详页部分和支付页部分，对于一般平台来说，都是通用板块，而从“点击抢购”开始到“下单成功待支付”，这一段是属于秒杀系统的业务范畴。 **8)哪几件事情是需要秒杀系统来做的?** - 提供活动数据 - 提供结算页 - 提供结算页页面渲染所需数据 - 提供下单： **9）秒杀系统设计的基本原则有哪些？** - 校验前置 - 分层过滤

nginx再强，一般单机只支持5万并发？千万级并发的请求，需要通过DNS分流，和专用LB服务器吧？