分布式锁的工程实践深度剖析 — 从 Redlock 争议到 Fencing Token 的生产级安全

在微服务架构中，分布式锁是协调多节点访问共享资源的核心基础设施。然而，一个经典的争论困扰着无数工程师：Redis 的 Redlock 算法到底安不安全？本文将从分布式锁的基本定义出发，深入剖析 Redlock 争议的技术本质，并提出基于 Fencing Token 的生产级安全方案，最终用 Rust 从零实现一个高可用的分布式锁服务。

一、分布式锁的本质需求

分布式锁的目标极其简单：在多个竞争者（进程/节点/线程）中，保证同一时刻只有一个能执行某段临界区代码。但这个"简单"的目标，在分布式系统的三大恶魔（网络延迟、节点故障、时钟漂移）面前变得异常棘手。

一个正确的分布式锁必须满足以下三个核心属性：

互斥性（Mutual Exclusion）：任意时刻最多一个客户端持有锁。

无死锁（Deadlock Free）：即使持有锁的客户端崩溃，锁最终也能被释放（通过过期机制）。

容错性（Fault Tolerance）：只要多数锁服务节点存活，客户端就能正常获取和释放锁。

看似清晰的三条属性，在工程实践中却充满了微妙陷阱。我们先来看最直觉的单 Redis 实例方案。

二、单实例 Redis 锁：简单但不完美

Redis 的 SET key value NX PX 命令天然适合实现分布式锁：

use redis::Commands;
use std::time::{SystemTime, UNIX_EPOCH};

const LOCK_KEY: