一、目标
每秒处理1万并发请求
不影响其他业务的正常运转
避免超卖问题
预防作弊行为
二、架构设计
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
抢购开始后，所有的请求是先到nginx负载服务器，而经过配置优化的nginx服务器并发请求可以达到3万以上，负载部分ok
api服务器由于要执行具体的php代码，这个本身就需要耗费一定时间，目前的代码并没有什么业务逻辑处理，单机qps基本可以维持在400-500左右，那么我们临时部署20台-25台
api服务器集群的请求统一到redis上，而redis读并发可以达到10万，所以1万并发ok
而最后带令牌的客户端就只有区区几个了，这个后续的具体业务就不能算问题了。
根据上述分析，我们基本上可以实现目标1、2、3，即满足并发需求，不影响其他业务，避免超卖。
那么是否也可以预防作弊呢？
由于新的api是动态获取的，在事先是无法获悉的，这就避免了提前下单、避免批量访问等行为
---------------------
作者：王大刀
来源：CSDN
原文：https://blog.csdn.net/houfangwulu/article/details/81131328
版权声明：本文为博主原创文章，转载请附上博文链接！