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