使用Cloudflare Workers KV与Promise.all递减计数致数据丢失问题咨询

核心问题：竞态条件导致计数不准 #

你当前的「读取KV数据→修改credits→写回KV」属于非原子操作，本地单进程环境下无并发冲突所以运行正常，但部署后Cloudflare Workers分布式运行，多个请求会同时读取到同一初始值，各自修改后再写回，最终仅保留最后一次写入结果，导致积分递减次数远少于实际请求数。比如10次并发请求同时读到credits=10，各自减到9后写回，最终KV值为9而非0，这就是计数不准确的根本原因。

KV是否适合该场景？ #

完全不适合。Cloudflare KV是最终一致性的分布式存储，设计目标是承载读多写少、一致性要求低的场景（如静态资源、静态配置）。它不支持原子修改操作，也无锁机制，无法保证并发场景下状态更新的准确性，完全不符合积分这类强一致性计数需求。

Durable Objects vs D1：哪个更合适？ #

Durable Objects（DO） #

• 核心优势：每个DO实例单线程运行，同一时间仅处理一个请求，天然规避并发竞态。你可以为每个用户创建对应DO实例（用用户ID作为DO标识），直接在DO内存中维护credits和时间戳，每次/decrementCreditsByOne请求到达时，直接修改内存值并异步持久化，操作完全原子。
• 时间戳支持：可直接在DO状态中添加updatedAt字段，更新credits时同步设置为当前时间，实现简单。
• 适用场景：仅需单用户状态管理（如积分、用户会话），无复杂查询需求的场景，性能最优，实现成本最低。

D1 #

• 核心优势：Cloudflare推出的SQLite兼容关系型数据库，支持事务与原子更新语句。你可通过以下原子操作实现积分递减：

  UPDATE user_credits 
  SET credits = credits - 1, updated_at = CURRENT_TIMESTAMP 
  WHERE user_id = ?
  

  该语句在数据库层面原子执行，不会出现并发覆盖问题。
• 时间戳支持：利用SQL的CURRENT_TIMESTAMP自动生成更新时间，无需额外逻辑。
• 适用场景：需要多用户数据关联查询、统计分析，或已有SQL使用经验的场景，灵活性更强。

优化建议 #

1. 立即停止使用KV处理积分这类强一致性状态，切换至Durable Objects或D1。
2. 若选择DO：
   • 创建DO类，内部维护用户credits与updatedAt状态。
   • 在Worker中根据用户ID路由至对应DO实例，调用DO的递减方法。
3. 若选择D1：
   • 创建用户积分表（包含user_id、credits、updated_at字段）。
   • 将/decrementCreditsByOne接口逻辑替换为执行上述原子UPDATE语句，无需先读再写。

内容的提问来源于stack exchange，提问作者learyjk