关于提现如何防止用户恶意调用接口的疑问

[sanyuedev]

用户发起提现申请的时候，要去判断用户时间段内已申请的次数和提现成功的总金额

1. 检查用户是否完善手机号
2. 检查用户时间段内提现的次数
3. 检查用户时间段内提现成功的金额+正在申请中的金额
4. 冻结用户余额
5. 新增提现申请
6. 提现审核自动通过 /手动通过

这边存在的一个疑问就是如何防止用户恶意的调用两次接口，导致数据出异常。

冻结余额和更新提现状态,我使用的 乐观锁的更新方式。应该没什么问题。这边异常的点在于，检查时间段内次数和总金额，我是使用了快照读，这样用户连续请求就有可能导致判断出错，产生多的记录。其他人给出的方案有，直接使用 Redis 分布式锁，对用户提现这个操作进行加锁，这样是可以解决问题，但是这不就又变成了悲观锁了嘛。

想知道还有没有其他的方案。

[hhjswf]

幂等

[tanjnr]

提现这种非高频的，敏感业务，加个人工审核，用户随便调接口，用户端直接返回处理状态[提交成功，审核中，处理中 …]。后台人工审核通过才生效。

[gimp]

Redis 还是要上的，首先客户端可以传一个 once code ，如果 code 相同，说明是一个请求两次提交（客户端未限制连点或接口重放攻击）则丢弃请求，Redis 缓存 code 的时间可以设置几百毫秒或一两秒，这个值需要大于接口处理的时间。用 Reds 加锁让单个用户提现请求变为顺序的，另外前端也需要增加一些动效，增加用户点击提现的间隔，给数据库同步数据一点儿时间，按说是可以解决你的问题的。

[bjzhush]

入队列，确保一个前后顺序

[LeegoYih]

锁也是锁个人的，有什么影响

[huiyadanli]

分布式锁（悲观锁）是最佳方案，如果你觉的用户体验不佳可以加入自旋等待（自旋锁），获取锁失败则等待一会后重新获取，超时放弃并报错

[R18]

悲观锁就悲观锁呗，反正试行锁，影响的也只有正在提现的这个人。这个人正在提现，他还想同时进行其他操作吗？

[guaguaguaxia1]

直接跟产品说，这种非高频的接口，一个用户 X 分钟内只能提交一次申请，不就解决了。这个时间可以是十分钟，半小时

[christin]

once code 呢？没见你提到

[Dream95]

乐观锁怎么用的，为什么会有错误数据

[liuzhedash]

最简单，且实践过的方式：提现申请放到一个表里，加个定时任务挨个处理。

[FlyToSKy]

这种需求需要从业务方面进行限制就可以了，一是前端限制多久时间之内不允许再次提交，二是后端直接返回成功，显示提交成功，审核中。

[hccsoul]

是啊 提现 退款 这些 都是存在表里 然后定时任务 每隔几分钟扫描然后执行 。