再问秒杀锁问题

[cevincheung]

现成的技术解决方案太多，redis 的并发性能真的是没得说，关键是想问问都是怎么处理数据同步的问题的。

发布秒杀活动，发布成功后就直接入 redis ？

if (insert ok) redis.set('ms:itemid',stock) ?

入 redis 失败了呢？ redis 挂掉这阶段的数据没保存呢（还没来得及 fsync)？

活动结束后 怎么删除(不能用 setnx 的场景，没过期时间，售完算完）？

if(decr('ms:itemid')<0) del('ms:itmeid') ?

怎么及时的删除脏数据？

大半夜睡不着不知道自己在纠结什么。 :(

[hareandlion]

额，启用热备，一个备份不够就多上几个？剩下的就是预防成本高于实际需求的小概率情况了吧？

[jalja27]

‘ 1

[linpf]

讲道理，业务上改一改规则的话，没必要完全实现秒杀，假设同一秒有 1 万个用户抢购 100 件商品，nginx 直接按照 97%的几率抛弃请求，返回“抢购失败，还有机会，请重新抢购”，省下大约 300 个请求，直接用 mysql 就行了。这样购买时间都是同一秒的请求，用户也不知道他到底在这 1 秒之内的顺序。对活动方来说，活动效果也实现了。毕竟运气也是实力的一部分。

[esile]

@linpf 666 啊 先随机排除，然后在进行计算😂

[xrlin]

@linpf 这想法很不错。

[jyz19880823]

@linpf 666

[TheLamb]

@linpf 很 6 的想法

[t333st]

@linpf 套路深，学习了

[cevincheung]

@linpf #3 23333

[cevincheung]

@linpf #3 就直接 select for update 了？

[paragon]

前面加验证码 后面提交验证的验证码就丢了

[kamushin]

@linpf 然后出现一件商品非常冷门, 很少有人愿意抢, 唯一一个客户需要下单 33 次才能购买到. 这个用户体验炸裂

[MrFireAwayH]

@kamushin #12 虽然不是很懂 但是我觉得判断一下并发请求数目后再进行 97%概率抛弃是能做到的吧

[yexiangyang]

1.if(decr('ms:itemid')<0) del('ms:itmeid') ?
可以修改为
if(decr('ms:itemid')=0) del('ms:itmeid')
2.入 redis 失败了呢？ redis 挂掉这阶段的数据没保存呢（还没来得及 fsync)？
建议采用 sentinel 模式
挂掉后故障转移,时间不会很久,期间可以业务失败

[caijihui11]

@linpf 这个实现 6，但我们也要维护参与活动的公平性，不能以运气来搞

[qiyuey]

@caijihui11 随机难道不公平吗

[linpf]

@kamushin 没看到返回的文字吗“抢购失败，还有机会，请重新抢购”，也就是可以再点啊。

[linpf]

@caijihui11 这就要看为了这点公平性，提升的成本能不能接受了

[linpf]

@caijihui11 而且每个用户访问请求接口，网络环境的不同也会存在延迟也有几毫秒到几秒的随机，其实请求到达服务器的顺序本身就已经不是按照点按钮的顺序了。

[tausi0661]

@qiyuey 吹毛求疵的说, "秒杀"的意思是"比谁快". 而随机意味着"我比你快, 但我被随机掉了"
(3#666, 我也打算这么实现...)