分布式锁噩梦解决方案：Fencing令牌

摘要

本文是分布式锁系列文章的第二部分，重点解决分布式锁的核心理念缺陷：客户端无法信任自己是否仍持有锁。当客户端因 GC 暂停而失去锁却毫不知情时，会导致数据被覆盖。文章提出 Fencing Token 作为根本解决方案，通过让数据库验证单调递增的令牌来确保数据安全，并对比分析了 Postgres Advisory Locks 等替代方案的优缺点。

内容框架与概述

文章首先揭示了一个反直觉的事实：即使使用 ZooKeeper 或 Etcd 这类高可用协调服务，分布式锁仍然不安全。核心问题在于客户端无法准确判断自己是否仍持有锁——当 Client A 因 GC 暂停时，锁会被释放并被 Client B 获取，但 Client A 醒来后可能覆盖 Client B 的数据。这种信任危机是分布式系统的根本挑战。

为解决这一问题，文章引入了 Fencing Token 机制。当客户端获取锁时，锁服务器会颁发一个单调递增的编号。关键在于，客户端写入数据库时必须携带该令牌，由数据库主动拒绝过期令牌的写入请求。这将信任从不可靠的客户端转移到权威的数据库，实现了真正可靠的保护。文章强调：分布式锁本身无法保证安全，唯有资源本身参与验证才能解决竞态条件。

此外，文章建议在采用 ZooKeeper 等复杂方案前，首先评估 Postgres Advisory Locks。这类锁直接集成在数据库事务中，自动管理锁生命周期，且无需额外运维基础设施，特别适合创业团队。文章最后预告将提供 C# 实现示例和决策框架，帮助读者在实际项目中做出合理选择。

核心概念及解读

Fencing Token：分布式锁服务器颁发的单调递增编号，用于标识锁的获取顺序。数据库通过拒绝旧令牌来防止过时写入。

GC Pause 问题：垃圾回收导致的程序暂停，可能使客户端持有的锁在不知情的情况下被释放，引发数据不一致。

分布式锁信任危机：客户端无法可靠地判断自己是否仍持有锁，这是分布式系统协调的根本挑战。

Postgres Advisory Locks：数据库内置的锁机制，通过锁定抽象数字实现资源保护，无需额外基础设施。

资源层锁验证：将锁的验证责任从客户端转移到受保护的资源本身，确保数据安全性不依赖于客户端的自我判断。

原文信息

此摘要卡片由 AI 自动生成