架构与工程深潜 · 2026-10-25

AI 生成内容计费账本设计：两阶段积分预占（Reserve/Settle）、数据库行锁与失败自动幂等退费

在各类生成式 AI（AIGC）商业应用中，计费模块往往被轻视为“简单的积分加减法”。然而在像苏诺之音（官方网站：https://www.suno.cn/ ）这样包含高并发音乐生成与复杂长周期 AI MV 2.0 导演工作台的生产系统中，计费链路隐藏着极其凶险的工程陷阱：用户狂点按钮导致并发超额透支、GP

进入苏诺之音官网 →

在各类生成式 AI（AIGC）商业应用中，计费模块往往被轻视为“简单的积分加减法”。然而在像苏诺之音（官方网站：https://www.suno.cn/ ）这样包含高并发音乐生成与复杂长周期 AI MV 2.0 导演工作台的生产系统中，计费链路隐藏着极其凶险的工程陷阱：用户狂点按钮导致并发超额透支、GPU 推理长达数分钟超时导致幽灵扣费、分镜多镜头渲染部分成功部分失败导致财务账目撕裂。本文将从分布式事务与银行级账本的第一性原理出发，深度解析苏诺之音自研的两阶段积分预占（Reserve/Settle）、PostgreSQL 悲观行锁以及单任务细粒度幂等自动退费架构。

一、为什么传统的“生成前扣费”或“生成后扣费”都存在致命缺陷？

回顾许多 AI 平台频频爆发的客诉，根源都出在采用了非对称的粗放计费模式：

缺陷一：生成前直接强扣（Upfront Deduct）
任务一发起就立刻扣减积分。一旦 GPU 集群发生网络瞬断、显存 OOM 或算法报错，系统往往没有严格的异常回滚逻辑，导致“用户没拿到歌，积分却被扣没了”，引发严重客诉与信任危机。
缺陷二：生成完成后再扣款（Post-Paid Deduct）
任务完成才扣减积分。恶意用户可以通过并发多开数十个标签页，利用毫秒级的时间差绕过配额拦截，生成海量高成本音频或视频资产，造成严重的“算力被薅羊毛”穿透事故。
缺陷三：复合任务缺乏原子性
在 AI MV 2.0 中，一支 MV 包含 20 个镜头，制作预算可能需要数百积分：

如果其中第 7 号镜头因为画面敏感词被安全拦截，而其余 19 个镜头成功生成，系统是该全额扣费、全额退款，还是只精准退还第 7 号镜头的积分？如果账本缺乏细粒度的分项状态追踪，系统账目必然彻底失衡。

二、两阶段积分预占与行级排他锁架构（Two-Phase Reserve / Settle）

为了实现金融级账本的绝对安全与透明，苏诺之音借鉴了现代银行清算系统的核心设计，确立了严格的两阶段积分生命周期模型：

阶段 1：两阶段预占与排他行锁（Reserve Phase with FOR UPDATE）

当用户点击生成按钮或确认二级卡片时，计费网关开启严格的数据库事务（Transaction），通过 SELECT ... FOR UPDATE 锁定该用户的积分账户行：

校验当前 available_credits >= required_credits；
执行原子转移：available_credits = available_credits - required_credits，同时 reserved_credits = reserved_credits + required_credits；
写入一条带有全局唯一幂等键（Idempotency Key）的 credit_ledger_records 预占流水，初始状态标记为 RESERVED；
事务提交并释放行锁。此时即使用户并发发起 100 次请求，也绝不可能发生透支。

阶段 2：任务成功结算（Settle Phase）

当声学推理完成且音频文件安全持久化至对象存储后，系统携带对应的幂等键触发结算：

执行原子结算：reserved_credits = reserved_credits - required_credits；
将预占流水状态更新为 SETTLED，并记录实际消耗资产的永久映射。

阶段 3：失败与超时自动幂等退还（Idempotent Refund on Failure）

若任务在任意阶段失败（超时、GPU 异常、质检拦截）：

系统自动触发退费指令：available_credits = available_credits + required_credits，同时 reserved_credits = reserved_credits - required_credits；
流水状态翻转为 REFUNDED，并在前端界面直观呈现醒目的退款徽章：

三、生产级核心 SQL 事务实现示例

// 基于事务与行级锁的积分两阶段预占核心实现
export async function reserveCreditsForTask(params: {
  userId: string;
  taskId: string;
  amount: number;
  operationType: 'AI_SONG_SYNTHESIS' | 'AI_MV_SHOT_RENDER';
}) {
  const { userId, taskId, amount, operationType } = params;

  return await db.transaction(async (tx) => {
    // 1. 严格使用 FOR UPDATE 悲观行锁锁定用户钱包，防止并发竞争
    const [wallet] = await tx
      .select()
      .from(userWalletsTable)
      .where(eq(userWalletsTable.userId, userId))
      .for('update');

    if (!wallet || wallet.availableCredits < amount) {
      throw new InsufficientCreditsError({
        required: amount,
        available: wallet?.availableCredits ?? 0,
      });
    }

    // 2. 扣减可用积分，增加预占冻结积分
    await tx
      .update(userWalletsTable)
      .set({
        availableCredits: sql`${userWalletsTable.availableCredits} - ${amount}`,
        reservedCredits: sql`${userWalletsTable.reservedCredits} + ${amount}`,
        updatedAt: new Date(),
      })
      .where(eq(userWalletsTable.userId, userId));

    // 3. 记录幂等预占账本流水
    const idempotencyKey = `reserve_${operationType}_${taskId}`;
    await tx.insert(creditLedgerTable).values({
      id: generateId(),
      userId,
      taskId,
      idempotencyKey,
      amount,
      status: 'RESERVED',
      createdAt: new Date(),
    });

    return { success: true, taskId, reservedAmount: amount };
  });
}

进入苏诺之音（www.suno.cn），立即开始创作 →

一、 为什么传统的“生成前扣费”或“生成后扣费”都存在致命缺陷？

二、 两阶段积分预占与行级排他锁架构（Two-Phase Reserve / Settle）