以下方案建议不要用了,rabbitMQ安装方便又好用,比redis做队列直接多了,还不用考虑大部分的问题。
"用一个线程循环处理",我就不明白该如何下手了,啥时候开启这个"线程"?
我的方案是,先写好一个专门处理队列中的数据的程序,用定时任务(linux的crontab)每分钟调用一次此程序。
此程序使用blPop或者brPop堵塞获取list的数据(这两个方法的区别可看redis文档得知),要堵塞的原因是,万一这一分钟没有数据,过了30秒后数据进来了,就要再等30秒才能处理。堵塞的最大时间我设了59秒。同时为了兼容大量数据的情况,此程序会循环从list读数据,每次读数据用的都是堵塞方式,所以每次堵塞的时间都会根据当前程序运行的时长动态改变。理论上如果业务不复杂,这个程序运行一次不会超过60秒,也就达到要求了,如果超过了60秒,也会自动新增线程来执行下一次循环。
你接下来的问题有点不理解,你是了解大的流程的,我说一下这个流程里的细节吧
我是用redis的list的,其它答案里有提到用锁,如果是你这个方案,完全不需要用锁,因为list已经为你解决了并发问题。
只要用户点了“抢”,你就把用户的信息lPush或者rPush进一个list,这时会返回一个int,就是告诉你这个操作之后,list里有多少条数据了,这个int是线程安全的,即使再高的并发,也不会造成这个int对于这个用户来说已经过时,所以你可以判断这个int有没有超过库存,如果超过了,直接告诉前端这个用户错过秒杀了,如果否,则让前端等待抢购结果。(此时并不需要把超过库存的用户从list里删除。库存数建议在秒杀前查询出来放到redis中,之后也不要修改redis的库存数,因为这个库存数是专门用于跟list长度做对比的)
接下来的步骤就根据不同的业务需求了,如果接下来要用户填写补充信息,则最简单了:写一个接口接收用户补充的信息,查询list中用户排第几,跟库存对比一下他是不是真的秒杀到了,然后做入库操作。
如果接下来没有让用户操作的需要了,则跟上面回答你第一个疑问那样,写一个堵塞轮询的接口。