应用出现重复UUID问题：删除用户后新用户复用同一UUID

问题场景 #

我们的用户注册流程出现异常，不同用户被分配了相同的uuid。流程逻辑为：用户注册时先创建User数据库记录，再发送可能失败的外部请求；若外部请求失败，则删除已创建的User记录。

实际触发场景：前端同时发送两个相同的注册请求，第一个请求因外部请求失败删除了User #1，但第二个请求复用了刚被释放的uuid，创建了User #2，最终导致不同id的用户拥有完全相同的uuid。

当前uuid的数据库定义代码：

t.uuid "uuid", default: -> { "gen_random_uuid()" }, null: false
t.index ["uuid"], name: "index_users_on_uuid", unique: true

简化时序：

• 创建User #1，id=100，uuid=40e6215d-b5c6-4896-987c-f30f3678f608
• 删除User #1
• 创建User #2，id=101，uuid=40e6215d-b5c6-4896-987c-f30f3678f608
  以上三步几乎同时发生。

问题根源 #

1. 唯一索引的局限性：数据库的唯一索引仅约束当前存在的记录，当User #1被删除后，其uuid立即回到可用池，并发请求触发gen_random_uuid()时，极小概率会生成重复值（高并发+瞬时复用的场景会放大这一概率）。
2. 流程无互斥机制：注册流程未做并发控制，多个相同请求可同时进入创建用户的逻辑，无法阻止uuid被重复分配。

解决方案 #

1. 重构注册流程（最优解） #

• 优先调用外部请求，确认成功后再创建User记录，从根源上避免“创建后删除用户”导致的uuid释放问题。
• 若必须先创建用户（如需要用户信息调用外部服务），给User表增加status字段（如pending/active/cancelled），请求失败时标记为cancelled而非硬删除。此时唯一索引会永久占用该uuid，不会被复用。

2. 强化数据库层面的唯一性保障 #

• 如果必须硬删除用户，新增deleted_user_uuids表存储已删除的uuid，创建用户前先查询该表，确保uuid未被使用过。
• 改用带时间戳的UUID版本（如UUIDv1、UUIDv7），这类uuid包含时间维度信息，并发场景下重复概率趋近于0，同时能避免瞬时删除后的复用问题。

3. 增加请求幂等控制 #

• 前端发送注册请求时生成全局唯一的request_id，后端先校验该request_id是否已处理，避免重复执行相同请求。
• 对注册接口增加分布式锁，同一用户标识（如手机号、邮箱）的注册请求同一时间仅能处理一个，阻止并发请求进入流程。

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