用户发起提现申请的时候,要去判断用户时间段内已申请的次数和提现成功的总金额
这边存在的一个疑问就是如何防止用户恶意的调用两次接口,导致数据出异常。
冻结余额和更新提现状态,我使用的 乐观锁的更新方式。应该没什么问题。这边异常的点在于,检查时间段内次数和总金额,我是使用了快照读,这样用户连续请求就有可能导致判断出错,产生多的记录。其他人给出的方案有,直接使用 Redis 分布式锁,对用户提现这个操作进行加锁,这样是可以解决问题,但是这不就又变成了悲观锁了嘛。
想知道还有没有其他的方案。
1
hhjswf 2023-06-12 09:21:08 +08:00
幂等
|
2
tanjnr 2023-06-12 09:26:49 +08:00 via iPhone
提现这种非高频的,敏感业务,加个人工审核,用户随便调接口,用户端直接返回处理状态[提交成功,审核中,处理中 …]。后台人工审核通过才生效。
|
3
gimp 2023-06-12 09:36:49 +08:00
Redis 还是要上的,首先客户端可以传一个 once code ,如果 code 相同,说明是一个请求两次提交(客户端未限制连点或接口重放攻击)则丢弃请求,Redis 缓存 code 的时间可以设置几百毫秒或一两秒,这个值需要大于接口处理的时间。用 Reds 加锁让单个用户提现请求变为顺序的,另外前端也需要增加一些动效,增加用户点击提现的间隔,给数据库同步数据一点儿时间,按说是可以解决你的问题的。
|
4
bjzhush 2023-06-12 09:55:20 +08:00
入队列,确保一个前后顺序
|
5
LeegoYih 2023-06-12 10:20:33 +08:00
锁也是锁个人的,有什么影响
|
6
huiyadanli 2023-06-12 10:26:20 +08:00
分布式锁(悲观锁)是最佳方案,如果你觉的用户体验不佳可以加入自旋等待(自旋锁),获取锁失败则等待一会后重新获取,超时放弃并报错
|
7
R18 2023-06-12 10:29:37 +08:00
悲观锁就悲观锁呗,反正试行锁,影响的也只有正在提现的这个人。这个人正在提现,他还想同时进行其他操作吗?
|
8
guaguaguaxia1 2023-06-12 10:30:04 +08:00
直接跟产品说,这种非高频的接口,一个用户 X 分钟内只能提交一次申请,不就解决了。这个时间可以是十分钟,半小时
|
9
christin 2023-06-12 10:31:15 +08:00
once code 呢?没见你提到
|
10
Dream95 2023-06-12 10:35:17 +08:00
乐观锁怎么用的,为什么会有错误数据
|
11
liuzhedash 2023-06-12 10:58:30 +08:00
最简单,且实践过的方式:提现申请放到一个表里,加个定时任务挨个处理。
|
12
FlyToSKy 2023-06-12 11:17:59 +08:00
这种需求需要从业务方面进行限制就可以了,一是前端限制多久时间之内不允许再次提交,二是后端直接返回成功,显示提交成功,审核中。
|
13
hccsoul 2023-06-12 11:41:15 +08:00
是啊 提现 退款 这些 都是存在表里 然后定时任务 每隔几分钟扫描然后执行 。
|