redis php 秒杀

想了解下秒杀系统的设计 于是百度如下

1. 访问压力 即使是单纯静态页面 高并发下也是需要加机器的 解决方法 增加服务器 负载均衡
2. 处理请求 网上有讲用redis队列缓存请求 然后取秒杀商品数量记录返回秒杀成功 其他秒杀失败 秒杀结束或者库存为0 停止加入队列
3. 库存准确性需要特殊处理吗（使用队列的情况下）？
4. 限流（随机1%的请求通过 99%直接返回失败）这一点我觉得小米的预约做的很好 没预约的直接无法进入抢购系统

但是对具体实现有很多疑问
比如：
用户的请求是什么样的过程，从请求到返回结果？
redis队列解决了那些问题？
负载均衡查询redis服务器？
整个过程不需要mysql参与吧？
秒杀商品数据缓存在redis？
如果用户秒到了 仅仅是redis标记这个人有购买资格而已吧 当进入购买时查询这个资格有则创建订单 理解对吗？

求大神解惑

回复内容：

想了解下秒杀系统的设计 于是百度如下

1. 访问压力 即使是单纯静态页面 高并发下也是需要加机器的 解决方法 增加服务器 负载均衡
2. 处理请求 网上有讲用redis队列缓存请求 然后取秒杀商品数量记录返回秒杀成功 其他秒杀失败 秒杀结束或者库存为0 停止加入队列
3. 库存准确性需要特殊处理吗（使用队列的情况下）？
4. 限流（随机1%的请求通过 99%直接返回失败）这一点我觉得小米的预约做的很好 没预约的直接无法进入抢购系统

但是对具体实现有很多疑问
比如：
用户的请求是什么样的过程，从请求到返回结果？
redis队列解决了那些问题？
负载均衡查询redis服务器？
整个过程不需要mysql参与吧？
秒杀商品数据缓存在redis？
如果用户秒到了 仅仅是redis标记这个人有购买资格而已吧 当进入购买时查询这个资格有则创建订单 理解对吗？

求大神解惑

用户请求：
用户进入代理机，代理机把请求分发给后端某一个web服务器，web服务器拿到用户请求以后通过php操作数据库或者redis，然后把结果返回给web服务器，最后呈现给用户。

redis队列主要解决了大并发的问题，因为他是队列的形式，一条一条处理的，不会造成因为并发大几个人同时更新一条数据，你想想看，如果有几百人的并发，没有用到redis，你的抢购资格是有限的，因为数据库缓存或者memcache的某些原因，几个人同时查到有一个抢购资格，结果都在update这条数据，造成的结果可能就是最后一个人update这条数据的人获得真正的抢购资格，其他人被他更新掉了，但是其他人前台返回的是已经抢到了。

正常来说，是不用mysql的，因为你的抢购资格，都会缓存在redis里面，看具体需求。

我也是菜鸟，大神勿喷。

采用层层过滤的思想来设计秒杀，前置nosql数据库过滤大多数用户，具体数字可以为库存的放大2到10倍，接下入队列，后端消费者接收队列消息，然后操作mysql数据库进行更新下单，减库存。前台轮询结果

顶一下 求解

秒杀系统不要将流量都到落到后台处理服务器上，你有200个秒杀的产品，放前1000个用户过来就足够了（放200w个进来干嘛，纯粹累服务器）；
通过这么一过滤，根本没有什么压力嘛；