PostgreSQL群聊应用Npgsql死锁问题求助及解决方案咨询

这个死锁问题我之前在类似的群聊系统里遇到过，核心原因就是多用户并发更新同一条消息的ViewedUserIds数组时，行锁的竞争导致了死锁——当5个以上用户高频操作时，事务获取锁的顺序不一致，就容易触发PostgreSQL的死锁检测。下面给你几个实用的解决思路，按推荐程度排序：

1. 彻底重构：将已读状态拆分为单独的关联表（最推荐） #

用数组存储已读用户ID的设计，天然会导致所有用户的已读操作都竞争同一条消息行的锁。最彻底的解决办法是把已读状态拆成独立的关联表，让每个用户的已读操作变成插入新行而非更新原消息行，从根源上消除锁冲突。

步骤： #

• 创建关联表：

  CREATE TABLE public.chatmessageview (
    chatmessageid uuid NOT NULL REFERENCES public.chatmessage(chatmessageid),
    userid uuid NOT NULL,
    viewed_at timestamp with time zone NOT NULL DEFAULT timezone('utc'::text, now()),
    -- 复合主键避免重复标记
    PRIMARY KEY (chatmessageid, userid)
  );
  

• 替换原来的更新语句为插入语句（通过NOT EXISTS避免重复插入）：

  INSERT INTO chatmessageview (chatmessageid, userid)
  SELECT cm.chatmessageid, @UserId
  FROM ChatMessage cm
  WHERE cm.PlanId = @PlanId
    AND @UserId = ANY(cm.AllowedUserIds)
    AND cm.Deleted = False
    AND NOT EXISTS (
      SELECT 1 FROM chatmessageview cv 
      WHERE cv.chatmessageid = cm.chatmessageid AND cv.userid = @UserId
    );
  

• 查询已读状态时，通过关联表判断即可，比如要检查某用户是否已读某消息：

  SELECT EXISTS(
    SELECT 1 FROM chatmessageview 
    WHERE chatmessageid = @ChatMessageId AND userid = @UserId
  );
  

优势： #

完全避免了行锁竞争，每个用户的操作都是独立的插入，并发性能拉满，还能保留已读时间戳的额外信息，扩展性更好。

2. 优化现有更新逻辑：先锁定再更新（无需改表结构） #

如果暂时不想调整表结构，可以通过显式行锁让所有并发事务按顺序执行，避免死锁。核心是用SELECT ... FOR UPDATE先锁定要更新的消息行，再执行更新操作。

示例事务： #

BEGIN;
-- 先查询并锁定符合条件的消息行，后续事务会排队等待锁释放
SELECT chatmessageid FROM ChatMessage 
WHERE PlanId = @PlanId 
  AND @UserId = ANY(AllowedUserIds) 
  AND NOT (@UserId = ANY(ViewedUserIds)) 
  AND Deleted = False
FOR UPDATE;

-- 执行更新
UPDATE ChatMessage 
SET ViewedUserIds = ViewedUserIds || @UserId 
WHERE PlanId = @PlanId 
  AND @UserId = ANY(AllowedUserIds) 
  AND NOT (@UserId = ANY(ViewedUserIds)) 
  AND Deleted = False;
COMMIT;

原理： #

FOR UPDATE会在查询阶段就锁定匹配的行，所有并发的更新事务都会按到达顺序排队获取锁，不会出现循环等待锁的情况，自然就不会触发死锁。

3. 乐观锁机制：版本号控制（适合低到中并发场景） #

给ChatMessage表添加一个version字段，每次更新时带上当前版本号，当并发冲突时让应用层重试。

步骤： #

• 给表添加版本字段：

  ALTER TABLE public.chatmessage ADD COLUMN version INT NOT NULL DEFAULT 1;
  

• 修改更新语句：

  UPDATE ChatMessage 
  SET ViewedUserIds = ViewedUserIds || @UserId, version = version + 1
  WHERE PlanId = @PlanId 
    AND @UserId = ANY(AllowedUserIds) 
    AND NOT (@UserId = ANY(ViewedUserIds)) 
    AND Deleted = False
    AND version = @CurrentVersion;
  

• 应用层逻辑：先查询目标消息的当前version，然后执行更新；如果更新返回的行数为0，说明有并发修改，重试整个操作即可。

注意： #

这个方案不会完全避免锁竞争，但会把死锁转化为可重试的冲突，适合并发不是特别高的场景，实现成本较低。

4. 谨慎使用：降低事务隔离级别（不推荐） #

如果业务能接受脏读，可以考虑把事务隔离级别从默认的READ COMMITTED降到READ UNCOMMITTED，但这会带来数据一致性风险，比如可能读到未提交的更新，一般不建议在群聊这种对数据一致性有要求的场景使用。

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