我认为这只是个表达队列操作的demo,没有涉及到订单操作

那要用任务来处理吧

课程里面只是个演示吧，超卖设置库存锁或者，锁秒杀之类的就能控制了

老师课程里面的只是限制了存储长度，具体怎么用看业务场景吧

还要提供一个计数器队列总数是10，弹出一个就减去1

视频中采用for循环测试，这个是有序的，所以不会出现超卖现象；如果并发测试的话，会出现超卖现象；这里提供一个解决思路：活动前定义一个长度为10的list；利用lpop的原子性可以保障不会超卖；就是每次请求先lpop，如果可以获取到值，表示秒杀成功；获取不到说明已抢完。

采用异步的原因是根据实际的业务逻辑，用户只关心是否抢购成功的结果，并不需要详细数据，所以只返回给用户成功或失败的提示，实际队列中的抢购数据一般是通过定时任务由消费者进行消费，定时任务可以是系统级别的crontab，也可以是php的定时器等

 考虑后期维护没？这不叫多此一举，MVC更特么多此“几”举。还不是为抽象概念，让当前操作后后期操作的人能看的懂。 

视频中采用for循环测试，这个是有序的，所以不会出现超卖现象；如果并发测试的话，会出现超卖现象；这里提供一个解决思路：活动前定义一个长度为10的list；利用lpop的原子性可以保障不会超卖；就是每次请求先lpop，如果可以获取到值，表示秒杀成功；获取不到说明已抢完。

以课程案例为例，前10个秒杀成功，这个结果是实时的，可以直接返给前端。实际项目时，也是在得到秒杀成功的标识之后，才进行后续的付款操作。

确实会有这样的问题发生，解决方案有两个：

1、提前将秒杀数据写入到队列中，比如你写10个随机数（token）进入队列，然后有请求过来的时候，你开始pop这个token，并判断得到的值是否为空，如果为空说明10个token已经被取完了，秒杀结束。因为pop是redis的原始操作，不用担心重复返回相同值的问题。

2、在你的消费进程中设置为单线程处理，只处理10个记录。

自己敲一下吧，还能加深印象

你的composer安装出错吧，重装composer

是的，插入失败用lpush插回左侧

老师的代码是是，插入失败的话，还是放在队列的头部，顺序依旧保持不变，下一次循环还是会继续取出进行插入的。

可以可以

2个只是测试，如果瞬间有十万个请求（或者更多），存值那块会不会卡住。用redis先存起来（内存操作，速度很快），以后在慢慢存到数据库，

https://blog.csdn.net/u011415782/article/details/77864102

测试是10个 没有问题啊

队列里的数据时异步处理的，然后存进数据库，但是他访问那个连接的时候就相当于多个用户去秒杀了，输出的结果（成功或者结束）就实时的反应了是否秒杀成功。

在根目录运行 ./goods.sh回车，会提示“坏的解释器....”,然后输入：sed -i 's/\r$//' goods.sh回车，再继续运行shell脚本试试

我也这么想的，肯定是他写错了，口里说的插入左边，写的RPUSH插入右边。。。

redis是单线程，瞬时100个客户端请求过来，还是一条条加入队列，不会一次性进入100个

一半你请求三方接口，三方接口会做限制，不会让你太高频次的请求，也不会有并发的情况出现。如果出现的你说的情况是可以的，也要看你说的比较是多大，redis单个值的最大长度是512M，但是好像不要超过1M，否则效率不是很好，用memcached会好一点吧

按照课程的讲法的意思，在pop的时候设置了seelp(2) 两秒钟执行一次pop， 因为秒杀的时候速度非常的快，最多只是微妙数不同，其实在这pop的时间间隔内队列中早已插入了限定的元素个数了不会在插入元素了，也就是说这个时候前端对于秒杀已经判断好了。也就是说已经结束了。这个时候后面在对这十个元素进行入库操作。

?fffffffffffffffffff

一般定时任务会设计成上一次任务执行完成，才会执行下一次，取决于时间间隔。

这个锁完全是自己yy的一个锁， 完全没有起到作用；

 试想一下：

 第一次执行

     修改2条记录为  状态更新为2 。 

    然后搜索状态为 2 的数据  （2条）；

    处理数据 （此时处理流程在复杂状态下1分钟内只处理了1条）；

1分钟后， 第二次执行     

    修改2条记录为  状态更新为2 。 

    然后搜索状态为 2 的数据  （3条，2条是本次更新的记录，还有1条是上次没有处理完成的）；

    处理数据 （此时是不是有一条数据重复处理了？？？）；

听着像，有青岛贵妇的口音