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