统一积分系统的设计实践

积分系统看起来简单。用户有余额,消费扣钱,失败退款。但真正运行起来,问题会一个接一个出现。

两套积分系统会让用户困惑。Header 显示一个数字,生成视频时检查的是另一个数字。前端展示的余额和后端验证的不一致。技术上也麻烦,需要维护两套扣费逻辑、两套退款逻辑,还要防止它们相互干扰。

统一成单一积分池,这个决定听起来理所当然。但实现时必须处理好原子性。两个用户同时提交任务,都看到余额充足,系统可能让余额变成负数。这不是理论问题,是生产环境会真实发生的事。

行级锁的必要性

数据库事务保证一致性,但不保证并发安全。两个请求在同一毫秒到达,都读到 credits = 50,都扣除 10,最终余额可能是 40 而不是 30。

FOR UPDATE 锁定用户的行。第一个事务获得锁,第二个事务必须等待。等待不是浪费,是正确性的代价。用户宁可等 100 毫秒,也不想看到余额突然变负。

这个锁只存在于事务内。事务提交后,锁立即释放。所以它不会造成长时间阻塞,只是串行化了同一用户的并发操作。

失败时的退款

任务失败需要退款。但怎么知道该退多少?

记录很重要。每个任务在 ai_generations 表中有 credits_consumed 字段。扣费时写入,退款时读取。不能依赖前端传来的参数,那可能被篡改。不能从模型配置重新计算,那可能已经改变。

退款函数查询这个字段。如果是 NULL 或 0,说明没有扣费,不需要退。如果有值,把这个数字加回用户余额,然后清空这个字段。清空很重要,防止重复退款。

-- 简化的退款逻辑
SELECT user_id, credits_consumed INTO v_user_id, v_credits
FROM ai_generations
WHERE id = p_job_id;

IF v_credits > 0 THEN
  UPDATE profiles
  SET credits = credits + v_credits
  WHERE id = v_user_id;

  UPDATE ai_generations
  SET credits_consumed = NULL
  WHERE id = p_job_id;
END IF;

退款失败怎么办?记录到 Dead Letter Queue。手动处理。自动重试可能造成重复退款,那比不退款更糟。

相关的幂等性设计可以参考 idempotency-check。RPC 原子操作 中也讨论了类似的一致性保证问题。

前后端的双重计算

前端需要实时显示成本,不能每次都请求后端。用户改变参数,成本立即更新,这是基本的体验。

后端不能信任前端的计算。恶意用户可能修改 JavaScript,传一个低成本参数。所以后端必须独立计算。

两边用同样的公式。从数据库读取模型的 credit_cost_rules,应用相同的乘法逻辑。前端算出 10,后端也算出 10,扣费 10。如果前端传来 5,后端忽略,按自己算出的 10 扣费。

这不是冗余,是分工。前端负责体验,后端负责正确性。

成本公式的存储

成本规则存在数据库的 JSONB 字段里:

{
  "calculationType": "formula",
  "formula": "base * duration * resolution",
  "base_cost": 10,
  "duration_multiplier": {
    "3s": 1.0,
    "5s": 1.5,
    "10s": 2.5
  },
  "resolution_multiplier": {
    "480p": 1.0,
    "720p": 1.5,
    "1080p": 2.0
  }
}

这个设计让成本调整变简单。不用改代码,不用重新部署。更新数据库,立即生效。前后端都读这个配置,所以它们始终同步。

但这也要求计算逻辑必须通用。不能针对某个模型写特殊代码。所有模型都用同一套计算器,只是参数不同。

迁移的风险

从双积分系统迁移到单积分系统,最危险的是数据丢失。用户的 video_credits 怎么办?

先查询。生产环境中,986 个用户,0 个人有视频积分。这个发现很关键。如果有人有余额,必须先合并,或者给用户发通知。

删除列之前,删除所有引用它的函数。函数可能有多个版本,签名不同,必须全删干净。PostgreSQL 不会自动处理函数重载,DROP FUNCTION 需要指定完整的参数列表。

Migration 048 做了删除,但遗漏了一些旧版本的函数。结果 Migration 049 花了更多时间清理。这个教训是:数据库迁移需要验证,不能假设。查询实际的函数定义,确认没有 video_credits 的引用,才能算完成。

关于数据库迁移的更多实践可以参考 database-migration-methods。prisma-migration-with-mcp 中讨论了使用 MCP 工具验证迁移的方法。

监控与审计

积分系统需要监控。不是为了抓作弊,是为了发现 bug。

用户报告"明明有积分却提示不足",这可能是前后端不同步。查询他的任务历史,看 credits_consumed 的总和,对比当前余额,就能找到差异。

积分余额突然变负,这肯定是 bug。可能是退款逻辑错误,可能是并发控制失效。监控脚本每小时跑一次,发现异常就报警。

每日统计也有用。消费总量和购买总量的比率,显示了系统的经济健康度。如果消费远大于购买,可能是成本定价太低。如果购买远大于消费,可能是功能吸引力不够。

简单的价值

统一积分系统的最大价值不是技术优雅,是用户理解起来简单。

一个数字代表所有余额。所有功能消耗同一个池子。没有"图片积分"和"视频积分"的区别,没有"这个积分不能用在那个功能"的限制。

技术上也简单。一个扣费函数,一个退款函数。所有功能调用同样的接口。添加新的 AI 功能,不用考虑是否需要新的积分类型。

简单不是偷懒。简单是经过深思熟虑后的选择。复杂系统看起来功能更强,但维护成本会随时间指数增长。统一积分系统放弃了差异化定价的灵活性,换来的是长期的可维护性。

这个取舍值得。