不上悲观锁也不上 Redis：一个 AI 网站的钱包并发是怎么搞的

事情是这样的。怎么说呢，

我们这个 AI 网站有套"星源值"积分钱包。使用者充值换星源值，调模型的时候按 token 扣。本来挺简单一事——查余额、扣钱、完事。直到有一天测试妹子跑过来跟我说："我开了三个浏览器标签页同时发消息，结果扣费扣出负数了。"

我一看日志，好家伙。三个请求几乎同时读到同一个余额，各自算出"够扣 "，接下来都去扣。UPDATE wallet SET star_credits = star_credits - 500 这条 SQL 跑了三遍，最终余额变成了 -500。

经典的并发扣减问题！教科书级别，话说回来，

先说说我一开始是怎么想的

第一反应：上悲观锁呗！简单粗暴，

BEGIN;老实说，SELECT star_credits FROM t_wallet WHERE user_id = 123 FOR UPDATE;-- 锁住
-- 应用层算好新余额
UPDATE t_wallet SET star_credits = 500 WHERE user_id = 123;COMMIT，

写完自己跑了一下没问题。正准备提测时突然反应过来——这他妈的是 LLM 调用啊！慢得离谱，

• LLM 调用特点：从 reserve 预扣到 commit 结算间隔十几秒甚至几分钟
• FOR UPDATE 锁表会阻塞所有其他操作：改头像？等着吧，查余额？排队吧，如果超时未释放？数据库连接池直接爆炸，
• 高并发场景下 MySQL 的连接数和锁等待会直接崩溃——前面那篇《某大厂连接池泄漏导致服务崩溃》事故里就是这么整出来的人命...

那分布式锁呢？话说回来，Redis 搞不定吗？

确实可以解决并发问题...但代价太大了！

• 项目架构完全没有 Redis 中间件单独为了这个场景引入成本太高...
• Redisson 的 watchdog 需要维护续期逻辑、主从切换监控...
• 钱包更新冲突很少发生——99% 情况都是串行更新...
• 为这种偶尔发生但必须兜住底线需求引入 Redis 分布式锁...杀鸡用牛刀啊！ ，！

再看乐观锁，适合"冲突不多但要兜住"的场景

• - "为什么选择这个方案？": 在长时间 LLM 推理过程中需要保证钱包余额安全。但传统悲观/分布式链路都存在致命缺陷,而本方案能够以最小代价解决主要痛点!
• - "它如何工作?" : 基于数据库原生 version 字段机制+应用层智能重试逻辑组合拳!
• - "效果如何?" : 上线后零误差运行。TP99 延迟≤1ms,比较符合 SLA!

MyBatis-Plus 配置教程

@Configuration
public MybatisPlusConfig {
@Bean // 注册插件集必选项！public mybatisPlusInterceptor {
interceptor.addInnerInterceptor // 分页支持
interceptor.addInnerInterceptor // 🎯🎯🎯乐观所插件！}
}
@Entity @TableName
public Wallet extends BaseEntity {
private Long userId;private BigDecimal balance;private BigDecimal credits;🎯@Version // 🎯🎯此注解启动 MyBatis-Plus 对乐优先支持!private Integer version;// 数据库名称必须与字段匹配！}




关键实现细节
java line-numbers title=""
@Transactional
public Map //否则失败继续循环...

} return {...};说起来，}

- 注意每次失败后都需要重新 select 最新数据!/li< /ul=

- 建议设置 maxRetries 值为 ~ 次覆盖绝大多数场景!/ li< /

最终