充值cursor时如何避免重复扣款和状态不一致？

Question

在基于 Cursor（游标）的分页充值场景中（如按时间戳或自增ID分页批量处理用户充值请求），若上游重试机制与下游幂等性设计缺失，极易引发重复扣款与状态不一致：例如，服务A推送充值指令后超时重试，而首次请求已成功扣款并更新账户余额，但未及时持久化“充值任务完成”状态（如 Redis 中的 cursor 偏移量或 DB 中的 last_processed_id），导致重试时再次执行相同充值记录。更严重的是，若 cursor 更新与业务操作（扣款+记账）未在同一个事务或强一致性上下文中完成，可能出现“扣款成功但 cursor 未推进”（重复消费）或“cursor 已推进但扣款失败”（数据丢失）。该问题本质是分布式环境下“处理-确认-位点提交”三阶段缺乏原子性保障，常见于消息队列消费、定时任务分片及 API 批量回调等场景。

Answer 1

```html

一、现象层：重复扣款与状态漂移的典型故障表征

• 用户投诉“同一笔充值被扣两次”，账户余额异常减少，但订单系统仅显示一条成功记录
• 监控发现 Redis 中 cursor:recharge:ts 值长期停滞，而 DB 中 last_processed_id 与实际已处理记录不匹配
• 日志中高频出现 "Processing record id=10086, but balance already deducted" 类警告
• 定时任务每轮拉取 WHERE created_at > ? ORDER BY created_at LIMIT 100，但部分记录被跳过或重复处理

二、机制层：游标分页在分布式重试下的原子性断裂点

本质是三阶段操作（处理→业务变更→位点提交）未形成强一致性闭环。下表对比常见断裂场景：

断裂环节	表现后果	根本原因
业务执行成功 + cursor 更新失败	重复消费（如重复扣款）	Redis 写入网络抖动 / AOF刷盘延迟 / 无重试补偿
cursor 更新成功 + 业务执行失败	数据丢失（如充值未到账）	DB事务回滚未联动 rollback cursor 状态
上游超时重试 + 下游无幂等键	同一请求被多次进入处理流水线	缺乏 request_id 或 trace_id 全局去重上下文

三、设计层：从“先更新后处理”到“状态驱动型事务编排”

推荐采用「状态机+预占+异步确认」模式，核心流程如下：

// 伪代码：幂等化游标处理主干
function processBatch(cursorVal) {
  // 1. 幂等校验：基于 request_id + cursorVal 构建唯一业务键
  const idempotentKey = `recharge:${reqId}:${cursorVal}`;
  if (redis.setnx(idempotentKey, "processing", "EX", 300)) {
    try {
      // 2. 执行业务（扣款+记账），包裹在 DB 事务中
      db.beginTransaction();
      deductBalance(userId, amount);
      insertLedger(userId, amount, "RECHARGE");
      // 3. 仅当业务成功，才推进游标（且与事务同库！）
      updateLastProcessedId(cursorVal); // 在同一事务内
      db.commit();
      redis.del(idempotentKey);
    } catch (e) {
      db.rollback();
      throw e;
    }
  }
}

四、架构层：构建跨组件的最终一致性保障体系

graph LR A[上游服务
带重试的HTTP/API] -->|含request_id| B(幂等网关
Redis SETNX去重) B --> C{业务服务} C --> D[DB事务：
• 扣款
• 记账
• 更新last_processed_id] D --> E[异步事件：
recharge.success] E --> F[对账服务
比对cursor/ledger/balance] F -->|差异告警| G[人工干预工单] F -->|自动修复| H[补偿任务：
补记/冲正/重推cursor]

五、工程实践层：可落地的七项加固措施

1. 强制游标持久化与业务库同源：避免 Redis cursor 与 MySQL last_id 分离，优先用 DB 的 UPDATE ... WHERE last_id = ? 实现CAS推进
2. 引入双写屏障（Dual-Write Barrier）：在事务提交前，先写入 recharge_cursor_log 表（含 version 字段），再更新业务状态
3. 下游提供幂等回调接口：充值结果通知必须携带 idempotency_key，接收方校验并返回 200 OK 或 409 Conflict
4. 建立游标水位监控看板：实时比对 max(id)、last_processed_id、min(unprocessed.created_at) 三值偏差
5. 灰度发布时启用游标偏移验证：新版本启动时，先读取旧游标值，校验其对应记录是否已被处理
6. 关键字段全链路染色：从 API 入口注入 X-Request-ID，贯穿日志、DB trace_id、MQ headers、Redis key 前缀
7. 每月执行反向对账脚本：扫描所有 recharge_order，验证其是否在 account_balance_log 和 cursor_position 中存在一致映射

```