GaussDB(DWS) 中的分布式死锁问题实践

本文分享自华为云社区《GaussDB(DWS)中的分布式死锁问题实践》，作者： 他强由他强 。

1、什么是分布式死锁

分布式死锁是相对于单机死锁而言，一个事务块中的语句，可能会分散在集群里多个节点（CN/DN）执行，在不同节点上可能都会持有锁，当并发事务进行时可能会导致分布式（全局）死锁，如下图所示，会话 SESSION1 持有了 DN1 上的 lock1 资源后再去请求 DN2 上的 lock2，会话 SESSION2 持有了 DN2 上的 lock2 资源后再去请求 DN1 上的 lock1，两个会话形成互相等待。出现分布式死锁现象后，如果没有外部干预，通常是一方等待锁超时报错后，事务回滚清理持有锁资源，另一方可继续执行。

2、常见的分布式死锁场景

一般来说，分布式死锁的产生与在不同节点上的并发时序或持锁顺序有关，所以现网实际发生概率较低，分布式死锁通常都是 RegularLock 类型，下面是几种常见的分布式死锁场景，举例说明两个并发事务产生的分布式死锁：

1）锁升级

# 集群两个CN，两个DNcreate table mytable(a int, b int);insert into mytable values(1,1),(2,2);

其中 sessionA 与 sessionB 由不同 CN 发起（sessionA：CN1，session2：CN2），执行时序如下：

可以看到 sessionA 里 select 会持有本地 1 级锁，truncate 会持有 8 级锁，出现锁升级现象，导致 sessionA 在 CN2 上等锁，sessionB 在 CN1 上等锁，形成相互等待。

2）行更新冲突

# 集群两个CN，两个DNcreate table mytable(a int, b int);insert into mytable values(1,1),(2,2); 

行存表发生行更新冲突是比较常见的分布式死锁场景。因为表是 round robin 分布，所以行 a = 1 与 a = 2 数据可以保证分别分布在 DN1 和 DN2 节点。

一个事务在更新数据时需要在对应 DN 节点持有本 xid 事务锁的 Exclusive 锁，当发生行更新冲突时（写写冲突），一个事务需要阻塞等待另一个事务提交（等待获取对方事务锁 ShareLock），形成相互等待时造成分布式死锁。

其中 sessionA 与 sessionB 可由相同或者不同 CN 发起，执行时序如下：

3）CU 更新冲突

# 集群两个CN，两个DNcreate table mytable(a int, b int) with (orientation = column);insert into mytable values(1,1),(2,2),(3,3),(4,4);

其中 sessionA 与 sessionB 可由相同或者不同 CN 发起，执行时序如下：

当出现更新冲突时，对于行存表来说是对一行数据加锁（如场景 2 所述），但对于列存表来说是对一个 CU 加锁。所以一个事务里的更新语句如果涉及到不同的 CU，也会拿事务锁，可能就会产生分布式死锁。

我们可以通过如下语句观察 ctid 信息判断数据是否分布在同一个 CU 上，如下图：可以看到 a = 1 与 a = 3 分布在 DN1 上，且在同一个 CU；a = 2 与 a = 4 分布在 DN2 上，且在同一个 CU。所以这也能解释为什么看上去列存表更新不同的“行数据”也会产生锁阻塞和分布式死锁现象。

4）单语句出现分布式死锁

前面几种场景都是事务块里涉及到多条 SQL 语句，可能会到不同节点上去交错拿锁导致的分布式死锁，但有时候某些单语句场景可能也会出现分布式死锁，如下：

此类问题与数据分布有关，如下场景都可能会导致这个现象：

1）若表是复制表，每个 DN 节点上都有数据，更新时会去所有 DN 并发执行

2）表是普通行存表或列存表，但有行数据（如 a=1）同时分布在了多个 DN 节点上，如 round robin 分布下插入两条相同 a=1 的数据

insert into mytable values(1,1)；insert into mytable values(1,2)；

此场景需要具体去排查数据分布是否会造成此情况。

3、规避分布式死锁的方法

1）控制锁级别，减少锁升级

按照各类操作的锁级别建议规则使用，开发时不要盲目提高锁级别，造成可能发生的不必要的锁等待

2）控制锁粒度

合理控制锁使用范围，及时释放

3）控制拿锁顺序

尽量控制对资源操作的顺序，比如对各分区表的操作顺序，避免乱序造成的死锁。但全局各节点的拿锁情况或顺序一般无法提前预测，往往为了考虑提高性能，请求会在节点间并发执行，但我们可以在某个节点上控制并发互斥以规避分布式死锁问题，如操作某个表时先去 FirstCN 上请求持锁，持锁成功后再对其他 CN 和 DN 并行拿锁。GaussDB(DWS)内核的很多地方的设计中会有这种思想，如 DDL 语句，autoanalyze 等。

4）主动设置较短的锁超时时间

一般用在非关键的用户路径操作上，如用户语句在 runtime analyze 子事务的流程里会主动设置锁超时时间为 2 秒，发生阻塞后可及时放锁，避免出现长时间锁等待，也能规避潜在的分布式死锁场景

4、如何排查系统是否产生了分布式死锁

本质上是发现集群中是否有全局的死锁环等待关系，内核中提供有许多视图可以辅助观察持锁等待情况，但需要注意的是，因为查询到的锁等待关系可能只是暂时的瞬间状态，只有持续存在的锁等待才会造成分布式死锁，需要判断锁是否稍后会主动释放（事务提交前），还是只能等到事务提交后释放。如何判断系统是否产生了分布式死锁，有以下方法：

1）查询 pgxc_deadlock 视图，会输出全局死锁环信息，如果信息为空，则代表无分布式死锁，但需要注意在某些复杂的场景可能会出现误报，即输出有死锁环信息，但可能并没有形成分布式死锁；

当有分布式死锁时，直到等待锁超时后，某一方事务会出现“Lock wait timeout...”，打印具体的锁信息及锁语句，报错后释放锁，另一方解除阻塞。相关的锁超时参数是 lockwait_timeout 或 update_lockwait_timeout。

2）在 GaussDB(DWS)的 8.3.0 版本及以后，内核已经支持了自动化地分布式死锁检测，当检测到系统中存在分布式死锁等待关系后，会自动报错和挑选事务进行 cancel，具体原理下一节中会详细介绍。

如下图所示，若用户出现“cancelled by global deadlock detector”报错，代表检测到分布式死锁并被查杀，此时可以去检测 CN 上（FirstCN 或者 CCN）上去找相关日志信息，会输出具体死锁和 session 查杀信息，需要注意用户语句执行 CN 和检测 CN 可能并不是一个，此时检测 CN 会向执行 CN 发起事务 cancel。

5、分布式死锁检测原理

分布式死锁检测的目标原则是做到不误报，争取不漏报，尽量及时报。

我们使用了中心化的收集检测思想，如流程图所示：首先挑选一个 CN 作为检测 CN（类似 master 角色），CN 上新增后台线程启动 GlobalDeadlockDetector 模块，周期性向集群所有节点收集锁等待关系，计算等待者和持有者信息，然后构造全局有向图（WFG），依赖定义的规则对图的顶点和边进行消除，判断是否能消除完成。如果无法消除完成，则出现了死锁环，并进行二次 DoubleCheck，如果两次的死锁环信息有交集，则报告死锁信息。当发现死锁后，按照事务时间戳挑选最年轻的事务（youngest）进行中断，并会对用户报错。

我们在设计上主要参考了 Greenplum 的思路，由于与 GaussDB(DWS)架构和应用场景上的差异性，也针对做了一些改造和优化，主要包括：

1、检测节点的选择：在 FirstCN 或 CCN 上启动后台检测线程，依赖外部 OM 模块做高可用切换；

2、等待关系图节点的标识：由检测 CN 构造全局唯一 global_session 下发，格式为：timestamp.pid.node_name（timestamp 为事务开始的时间戳，pid 为执行 CN 上的线程号，node_name 为执行 CN 名称）；

3、虚实边关系定义：支持定义线程级别虚实边，过滤掉不必要的死锁误报；

• 实边：锁等待关系的变化，需要等到持有者事务会话 commit 或 abort

• 虚边：锁等待关系的变化，不需要等到持有者事务会话 commit 或 abort

4、死锁结果的合法性检查：增加 DoubleCheck 机制，提高检测结果准确性，结果以连续两次检测到的死锁环交集为准；

5、死锁消除：执行 CN 与检测 CN 可能不同，可能存在跨 CN 发起的事务中断；

6、与单机死锁检测算法互补：当分布式死锁检测算法如果发现检测到单机的死锁环路等待关系后，则忽略，与单机死锁检测算法处理不冲突； 

分布式死锁检测相关参数：

• enable_global_deadlock_detector：分布式死锁检测功能是否开启，默认 off

• global_deadlock_detector_period：分布式死锁检测周期，默认 5 秒

点击关注，第一时间了解华为云新鲜技术~