PostgreSQL 的 pg_try_advisory_xact_lock 正确使用姿势是什么
dzdh · 2021-07-04 14:37:03 +08:00 · 1559 次点击这是一个创建于 1241 天前的主题，其中的信息可能已经有所发展或是发生改变。
看到 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
个人观点不一定对。
这个锁在并发量小的时候，基本上是必定成功，在并发量大的时候，成功率也不低。 一般来说，秒杀场景没有那么多的库存，如果参与的人多，那么再次刷新页面的时候，库存一定没了，如果人少，那就不会拿不到锁。 |
Select Language