AI图像生成SaaS的计费系统：如何在没有事务的Postgres驱动上避免四个竞态坑

我运营着一个AI图像生成SaaS。用户购买积分，每次生成消耗一定积分，生成失败自动退款。听起来是个已经解决的标准问题——直到你尝试把后端构建在Neon的serverless Postgres HTTP驱动上。这个驱动不支持多语句事务，每条查询都是独立的往返，BEGIN/COMMIT根本不可用。这意味着每个计费操作都必须在单条语句中保证完全正确，否则就是错账。

如果你的SaaS跑在阿里云RDS或者腾讯云Postgres上，事务随手可用。但当你选择serverless架构，就得接受这把双刃剑。下面四个竞态问题，是我真正踩过的坑，每个都在测试阶段毫无踪迹，却在售后收件箱里排队等着你。

并发扣费：检查与写入的分离

最原始的写法，几乎所有开发都会先这么写：

const balance = await getBalance(userId);
if (balance < cost) throw new Error("积分不足");
await setBalance(userId, balance - cost);

两个并发请求同时读到余额为5，同时通过检查，同时写入余额4。用户花一分钱，换来了两次生成。这是典型的检查与写入分离导致的竞态。

在有事务的情况下，你只需包一层SERIALIZABLE事务。但在serverless模式里，没有事务。修复方法是把检查条件直接塞进UPDATE语句里：

UPDATE credits_balance
SET balance = balance - $amount
WHERE user_id = $userId
 AND balance >= $amount
RETURNING balance

Postgres的单条UPDATE本身是原子的。如果余额不足，WHERE条件匹配不到任何行，影响行数为0，你就知道扣费失败了。不需要事务，也不需要锁。

这里总结出一个通用模式：把不变量写进WHERE子句。行不匹配，写入就不发生。

Webhook重试：重复充值的幂等

支付服务商（比如Stripe）会在超时、500错误、网络抖动时重发webhook。即使一切正常，同一个事件也可能偶尔投递两次。如果你的处理器收到事件就给用户加积分，“至少一次投递”就等于“至少一次到账”，用户会白嫖积分。

常规修复方式是建一张processed_events表，配合事务：先插入事件ID，插入重复就抛异常，然后再更新余额。但在没有事务的环境里，这两个语句之间一旦崩溃，要么重试时重复加款，要么直接丢失这次加款。

可行的单语句解法，是用数据修改CTE，让记账插入作为闸门：

WITH gate AS (
 INSERT INTO credits_transactions (user_id, delta, type, ref_id, balance_after)
 SELECT $userId, $amount, 'pack_purchase', $refId, ...
 ON CONFLICT (ref_id) WHERE type IN ('plan_grant', 'pack_purchase') DO NOTHING
 RETURNING id
)
INSERT INTO credits_balance (user_id, topup_balance)
SELECT $userId, $amount WHERE EXISTS (SELECT 1 FROM gate)
ON CONFLICT (user_id) DO UPDATE
 SET topup_balance = credits_balance.topup_balance + EXCLUDED.topup_balance

这背后需要一个部分唯一索引：

CREATE UNIQUE INDEX credits_tx_grant_idem_idx
 ON credits_transactions (ref_id)
 WHERE type IN ('plan_grant', 'pack_purchase');

ref_id就是支付会话ID或发票ID。当同一事件重放时，INSERT触发冲突，RETURNING没有返回行，EXISTS(gate)为false，余额更新就被跳过了。整个流程依旧是一条SQL搞定，没有事务，没有崩溃窗口。

实践中的细节

• 部分唯一索引必须与ON CONFLICT的WHERE条件完全一致，否则Postgres不会使用它。
• balance_after字段需要你自己算，因为不支持事务回滚。建议在触发器里计算，或者用上次余额加delta。
• 数据清理：processed_events表会膨胀，但部分索引可以显著缩小占用。

为什么这也适合你的后端开发

也许你会说，我用的RDS完整支持事务，干嘛要学这个？一方面，Serverless Postgres正在成为很多新项目的默认选项，尤其是AI相关SaaS——低流量、零空闲成本、自动扩缩。另一方面，即使你有事务，把业务规则压缩进单条SQL语句也能减少锁竞争和死锁概率，提高吞吐。

在闲鱼、猪八戒上确实有人卖AI图像生成服务，但那是人工代跑，不是SaaS。真正的SaaS自动处理用户充值、扣费、退款，计费系统是唯一的护城河。如果这里出错，用户流失是分分钟的事。

以我自己的服务为例，100积分售价10美元，约合72元人民币。每次生成消耗1积分，失败自动退还。每天有几千次生成，webhook回调几十次，全靠上面这几条SQL撑着，没有事务，却从未发生过一笔超扣或重复到账。

总结

Serverless Postgres驱动不支持多语句事务，但这不意味着你必须放弃数据一致性。核心思路只有一条：把你需要确保的不变量放进WHERE子句或唯一索引里，让Postgres的原子操作为你兜底。并发扣费用UPDATE加条件，幂等充值用CTE加部分唯一索引，有效且优雅。

下一次当你面对计费系统重构，或者在后端开发中遇到“没有事务怎么保证原子性”的质疑时，可以把这篇文章翻出来。在serverless的边界里，单条语句不是约束，而是简化。越少的移动部件，越少的出错方式，也越快的响应时间。这就是AI图像生成SaaS计费系统的正确打开方式。