Prisma+PostgreSQL行级锁下匿名聊天APP循环匹配问题排查

1. 当前FOR UPDATE锁机制的问题 #

你的锁机制存在两个核心缺陷：

• 锁定顺序不一致：当多个用户同时发起匹配请求时，可能出现A锁自己后尝试锁B、B锁自己后尝试锁C、C锁自己后尝试锁A的死锁循环。PostgreSQL会自动回滚其中一个事务，但剩余事务可能因状态不一致触发错误匹配，最终导致循环。
• 间隙状态不可控：先锁当前用户再查询潜在匹配的流程中，存在时间窗口——其他事务可能在你查询到潜在用户后、锁定它之前，已经将该用户匹配给别人，导致你拿到的是过时数据，进而引发异常匹配。

2. 优化匹配算法避免循环匹配 #

方案一：强制统一锁定顺序 #

所有匹配事务按照用户ID字典序锁定用户（先锁ID更小的用户，再锁ID更大的），彻底避免死锁，同时保证匹配原子性：

async findMatch(id: string): Promise<User[] | null> {
  return await prisma.$transaction(async (tx) => {
    // 查询当前用户基础信息
    const [user] = await tx.$queryRaw<User[]>`SELECT * FROM "User" WHERE "id" = ${id}`;
    if (!user) throw new Error("用户不存在");

    // 查询符合条件的潜在匹配用户
    const [match] = await tx.$queryRaw<User[]>`
      SELECT * FROM "User"
      WHERE "online" = true
        AND "gender" = ${user.preferGender} 
        AND "id" != ${id}
        AND ("lastMatch" != ${id} OR "lastMatch" IS NULL)
        AND "currentChatPartner" IS NULL
      LIMIT 1
    `;

    if (!match) {
      await tx.user.update({ where: { id }, data: { online: true } });
      return null;
    }

    // 按ID字典序确定锁定顺序
    const [firstId, secondId] = id < match.id ? [id, match.id] : [match.id, id];
    
    // 批量锁定两个用户，避免间隙竞争
    await tx.$queryRaw`SELECT * FROM "User" WHERE "id" IN (${firstId}, ${secondId}) FOR UPDATE`;

    // 再次校验双方状态，防止锁之前被其他事务修改
    const [checkedUser, checkedMatch] = await tx.$queryRaw<User[]>`
      SELECT * FROM "User" WHERE "id" IN (${id}, ${match.id})
    `;

    if (checkedUser.currentChatPartner || checkedMatch.currentChatPartner) {
      throw new Error("用户已参与其他聊天");
    }

    // 批量更新双方匹配状态
    await tx.user.update({
      where: { id },
      data: {
        online: false,
        currentChatPartner: match.id,
        lastMatch: match.id
      }
    });
    await tx.user.update({
      where: { id: match.id },
      data: {
        online: false,
        currentChatPartner: id,
        lastMatch: id
      }
    });

    return [checkedUser, checkedMatch];
  });
}

方案二：引入内存匹配队列 #

用Redis有序集合实现匹配队列，替代直接数据库查询，彻底规避并发锁问题：

• 用户上线时，将ID、性别、偏好性别存入Redis队列（按偏好性别分组）
• 后台定时任务（或实时消费）扫描队列，取出符合条件的两个用户，标记为匹配中后更新数据库状态
• 这种方式将并发匹配逻辑从数据库转移到内存队列，避免锁竞争，匹配逻辑更可控

3. 实时聊天应用的额外策略与最佳实践 #

• 事务超时控制：给匹配事务设置明确超时时间（PostgreSQL可通过SET statement_timeout = '5s'配置，或代码中加超时判断），避免长时间锁等待
• 状态幂等校验：每次更新用户状态前，必须二次校验currentChatPartner、online等核心字段，防止脏数据写入
• 离线状态清理：定时清理长时间未活跃用户（比如超过10分钟无操作），将其online设为false、currentChatPartner置空
• 扩展去重逻辑：将lastMatch字段改为lastMatches数组，存储最近5-10个匹配过的用户ID，避免短时间内重复匹配
• 实时通知替代轮询：用WebSocket推送匹配结果，减少数据库查询压力，提升用户体验
• 监控告警：监控数据库死锁次数、匹配失败率、队列积压量，设置告警阈值，及时发现异常

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