如何避免及处理Neo.TransientError.Transaction.DeadlockDetected死锁异常

死锁根源分析：
当多个并发事务执行MERGE (i)-[:TAGGED]->(t)操作时，针对同一个Tag节点t，每个事务会先尝试获取该节点关系组的共享锁以检查关系是否存在，若不存在则需要升级为排他锁来创建新关系。高并发场景下，多个事务会互相等待对方释放锁，最终触发Forseti锁管理器检测到死锁并终止其中一个事务。

1. 统一节点匹配顺序 #

所有涉及Tag和Item关联的事务，必须固定节点MATCH的顺序（比如始终先MATCH Tag，再MATCH Item），绝对不能出现部分事务先查Item再查Tag、另一些则顺序相反的情况。固定的访问顺序可以避免交叉锁等待，从根源减少死锁概率。

2. 替换MERGE为CREATE UNIQUE（特定场景） #

对于仅需“创建不存在的关系”的场景，使用CREATE UNIQUE替代MERGE。CREATE UNIQUE的锁策略更轻量，处理热点节点时冲突概率更低：

MATCH (t:Tag {name: "a"})
MATCH (i:Item {name: "x"})
CREATE UNIQUE (i)-[:TAGGED]->(t)

注意：CREATE UNIQUE仅在关系完全不存在时创建，不会修改已有关系或节点属性，语义上和单纯的关系MERGE一致，适合当前场景。

3. 批量处理关联请求 #

将多个Item关联同一个Tag的请求合并为单个事务批量执行，减少并发事务的数量：

MATCH (t:Tag {name: "a"})
UNWIND $itemNames AS itemName
MATCH (i:Item {name: itemName})
MERGE (i)-[:TAGGED]->(t)

通过批量操作，把原本几十上百个并发事务缩减为少数几个，大幅降低锁冲突的可能性。

4. 优化重试策略 #

在现有重试机制基础上，改用指数退避重试（比如第一次间隔100ms，第二次200ms，第三次400ms，最多重试N次），避免短时间内重复重试加剧锁竞争。同时可以调整Neo4j的dbms.lock.timeout配置（默认60s），让无法获取锁的事务更快失败并进入重试，减少资源占用。

5. 调整数据模型（可选） #

如果Tag节点的热度极高，可考虑临时调整模型：

• 将Tag属性直接存储为Item节点的数组字段（如i.tags = ["a", "b"]），但会失去标签节点的关联查询能力（如统计每个Tag的关联Item数），适合临时应急。
• 引入“分片Tag”：将热点Tag拆分为多个逻辑相同的节点（如Tag {name: "a", shard: 1}），分散锁竞争，但会增加查询复杂度。

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