这是一个创建于 531 天前的主题，其中的信息可能已经有所发展或是发生改变。
用户发起提现申请的时候，要去判断用户时间段内已申请的次数和提现成功的总金额
- 检查用户是否完善手机号
- 检查用户时间段内提现的次数
- 检查用户时间段内提现成功的金额+正在申请中的金额
- 冻结用户余额
- 新增提现申请
- 提现审核自动通过 /手动通过
这边存在的一个疑问就是如何防止用户恶意的调用两次接口，导致数据出异常。
冻结余额和更新提现状态,我使用的 乐观锁的更新方式。应该没什么问题。这边异常的点在于，检查时间段内次数和总金额，我是使用了快照读，这样用户连续请求就有可能导致判断出错，产生多的记录。其他人给出的方案有，直接使用 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
是啊 提现 退款 这些 都是存在表里 然后定时任务 每隔几分钟扫描然后执行 。
|
Select Language