支撑1万并发请求的秒杀架构设计

一、目标

1. 每秒处理1万并发请求
2. 不影响其他业务的正常运转
3. 避免超卖问题
4. 预防作弊行为

二、架构设计

1、充分利用cdn来进行静态资源的响应，这在秒杀开始前夕，用户频繁刷新页面会有帮助

2、活动开始后，用户点击抢购，则调用抢购api，这个请求会首先到达Nginx负载服务器，由其进行分发，确保每台实际的api服务可以接收到处理能力范围内的请求数量。

3、实际的api服务器并不执行秒杀业务相关逻辑处理，而仅仅是向redis缓存服务器申请一个令牌，redis服务器拥有一个令牌list，list数目与实际要提供的商品数量保持一致，比如有10个商品用于抢购，则list就有10条数据。这个申请令牌的行为，实际上就是在pop数据。

4、如果请求可以成功pop到一条数据，也就是获取到了令牌，那么响应客户端的消息体就增加一项内容，一个新的带令牌的api地址，否则就直接响应客户端，抢购失败等内容。

5、客户端接收到消息后，如果消息体带有新的api地址，则自动进行一次新的请求，这时就相当于一次普通的购买行为了。因为只有非常有限的客户端才会走到这一步。

三、架构分析

Q：是否可以支持10000并发请求？

A：
抢购开始前，基本上请求都是由cdn在处理，这个基本可以不用考虑，ok

抢购开始后，所有的请求是先到n