这种不是很正常的逻辑嘛,所在地区不同,可能会导致这种情况,你可以去监控库存的情况,然后去自动化的去均衡库存,或者手动调整啊
这个归还是正常逻辑啊,这样就不用考虑是否是秒杀是否完成了,但是你归还库存的话如果此时秒杀没有完成怎么办?如果秒杀规定是5分钟,可以设置1分钟内不支付归还库存,保证一人一单
可以给桶设置一个容量
在本地的都不是很安全
大小限制的是多少
统一减库存一般是Redis集群,本身有高可用方案,挂了一台,Redis的哨兵会把从机器顶替上。可以学习了解一下Redis的集群方案实现
要做一定的防止二次的工作
conRedis使用了单例模式,为了不重复创建redis连接,所以$redisObj要用静态变量。
至于其他地方用静态变量,应该是个人编码习惯吧。
这是个好问题,可以flock函数加一个非阻塞的文件锁,抢到锁的用户去减本地库存;
是的,需要单独写脚本去消费处理队列中数据,队列一般不建议直接使用Redis,因为没有ack机制,一条数据不能保证被可靠的消费,建议使用 kafka队列
放在本地内存中
本地存apcu是可行的,或直接用go这种常驻内存语言来做也可以
这位老师讲的就是大概的思路:
遇到高并发,要做减法或者分流,保重点,去除冗余的服务
遇到高并发,要相对隔离,避免一个点坏了,影响整体
明白了,本地减库存可以避免网络io,只有那些减库存成功的才去更新redis统一扣减库存,大大降低了网络io
这个已经知道了 老师通过redis减库存
可以关闭问题的
不能的
Redis中总库存吗?list也可以实现,但是你得导入数据,较麻烦
还是PHP操作Redis,执行的是Redis的eval命令,这个命令传入的字符串是lua代码,可以在Redis服务器执行这段lua代码。
仔细听,强调了需要有订单超时处理机制,避免占用库存长时间不支付的场景出现。而且之所以选择第三个方案原因为对比第一个方案,创建订单等写库耗时操作可以异步化,性能更占优势。
同学你好, 只是示例代码,不能直接用于生产环境
apcu只是其中一种本地缓存的方案,本地缓存还可以通过在本地安装redis来实现。
opcache 和 apcu 冲突的指的是什么冲突呢?
这种感觉要做集群
理论上是这样的