看到 pg_try_advisory_xact_lock (咨询锁)可以事务中免等待
实际场景是啥?
看很多描述是秒杀场景,那就拿秒杀来说,,一件商品,多人下单,那就是多个事物,只有一个人能下单(扣减库存)成功。
然后没拿到锁的呢?直接前端抛出个抢购失败的异常?然后刷新页面一看还有库存?业务代码逻辑自动重试?重试多少次呢?
因为很多场景其实并不都是极限秒杀场景(成百上千人抢),可能就是平常的一个商品,某个店铺搞了个活动(平台也不晓得)突然就大流量上来了。
就是不固定不定时毫无预兆的普通商品抢购,自动重试次数少了,刷新页面看还有库存。自动重试次数多了,那还不如事物里锁这条数据呢。
更具体的使用场景或姿势是啥?
1
liprais 2021-07-04 15:25:50 +08:00
|
2
dzdh OP @liprais 就是看了这个。业务中如何实现呢。
非秒杀,两个用户同时请求,一个成功,另一个告知稍后重试?还是抛个异常说库存不足了?没拿到锁的在业务代码中自动重试?重试多少次呢?重试 3 次?那抢购场景重试三次后告知人太多刷新页面一看库存依然充足,再下单依然提示抢购人数太多?这体验并不觉得多好鸭。 |
3
oclock 2021-07-05 09:12:56 +08:00
好几年不写后端,胡扯一句:“自动重试”通常是糟糕的设计
|
5
MoYi123 2021-07-05 09:30:05 +08:00
个人观点不一定对。
这个锁在并发量小的时候,基本上是必定成功,在并发量大的时候,成功率也不低。 一般来说,秒杀场景没有那么多的库存,如果参与的人多,那么再次刷新页面的时候,库存一定没了,如果人少,那就不会拿不到锁。 |