如何设计幂等性机制防止重复扣费？
解读
在大模型应用落地的付费场景（如按 token 计费、按调用次数计费、按高级功能订阅计费）中，网络超时、用户重试、网关重发、异步消息重复消费都会导致同一笔业务订单被扣费多次。面试官想确认候选人能否在高并发、分布式、LLM 长时推理环境下，用低成本、高吞吐、对业务无侵入的方案保证“同一业务凭证只扣一次费”。回答必须体现订单域、支付域、账户域三域协同，并兼顾LLM 推理异步回调的特殊性。
知识点
- 幂等令牌（Idempotency Key）：由客户端生成全局唯一字符串，随请求头或订单体上传，服务端以此作为唯一业务标识，相同 Key 多次到达只处理一次。
- 数据库唯一索引：在订单表对幂等 Key + 产品码建联合唯一索引，插入冲突即判定重复，直接返回原订单结果，避免先查后插竞态。
- 状态机与乐观锁：订单状态机只有待支付→支付中→已支付单向流转，更新时使用版本号或状态条件（
where status='待支付'），仅一条线程能扣费成功。 - 分布式锁：对账户维度加Redis 红锁（Redisson），锁键=用户ID+产品码+计费周期，过期时间≥LLM 最大推理耗时+回调缓冲，防止并发下单造成额度超扣。
- 异步消息去重：LLM 推理完成后发送扣费消息到 MQ，消费端用Redis Set 结构缓存已消费消息ID（幂等键或消息ID），过期时间≥消息最大重试窗口，实现至少一次消费语义下的幂等入账。
- 对账与冲正：每日离线对账将支付系统流水与订单系统流水按幂等键对齐，发现长款自动触发异步冲正，短款触发补偿扣费，保证最终一致性。
- LLMOps 特殊点：
- 长时推理场景下，先落“预扣费”订单并返回订单号，推理成功后再异步确认扣费；失败或超时则自动取消预扣费，释放用户额度。
- 流式输出计费采用累计 token 数+回调批次方式，同一请求ID下多次回调仅更新一次订单金额，避免中间回调重复扣费。
答案
线上实战采用“前端生成幂等键 + 后端唯一索引 + 状态机乐观锁 + 分布式锁 + 异步消息去重 + 日终对账”六级防线：
- 客户端在首次调用前生成UUIDv4作为Idempotency-Key，并持久化到本地存储；重试时不变更该 Key。
- 网关层把 Key 写入请求上下文透传到订单服务；订单服务先尝试插入（
insert ignore）订单表，唯一索引为**（user_id, product_code, idempotency_key）**。 - 插入成功则进入状态机：status=待支付；并发线程再次插入时因唯一索引冲突被驳回，直接返回原订单号与支付状态，无额外扣费。
- 进入支付环节前，Redisson 红锁锁定账户维度（
lock_key=user:{user_id}:billing:{product_code}:{cycle}），过期时间=LLM 最大推理时间+30s，防止并发下单导致额度竞扣。 - 支付成功后，订单状态机使用乐观锁更新：
update t_order set status='已支付', version=version+1 where order_id=? and version=? and status='支付中'；仅一条线程能更新成功，其余线程影响行数为0，自动丢弃。 - LLM 推理完成触发异步扣费消息（带订单号+幂等键），消费端用Redis SETEX缓存已处理消息ID（TTL=24h），重复消息直接ACK 丢弃，保证入账幂等。
- 每日凌晨离线对账作业按幂等键对齐支付流水与订单流水，差异>0自动异步冲正，差异<0触发补偿扣费，T+1 完成最终一致性。
通过以上机制，任何重试、重发、并发场景下同一 Idempotency-Key 仅扣费一次，P99 延迟增加<5ms，对 LLM 推理链路零侵入，已在国内某头部云厂商百亿参数大模型计费系统稳定运行一年零故障。
拓展思考
- 多端协同场景：若Web、App、小程序三端可能同时触发同一笔订单，可把幂等键的生成规则收敛到服务端——由服务端预分配订单号作为幂等键返回给各端，避免客户端时钟差异导致重复 Key。
- Serverless 弹性扩缩：函数计算实例冷启动可能导致同一消息被不同实例重复消费，可把 Redis 去重升级为 Lua 脚本原子化：
EVAL "if redis.call('exists',KEYS[1])==0 then redis.call('setex',KEYS[1],ARGV[2],1); return 1; else return 0; end;" 1 {msgId} 86400，保证判断与写入原子性。 - 跨境多币种扣费：汇率波动会导致同一幂等键在不同时间扣费金额不同，此时幂等键需追加 “币种+汇率版本” 字段，同一业务凭证在不同币种下允许分别扣费，避免汇率差异造成资损。