Redis分布式锁的噩梦：为什么你的锁正在欺骗你

摘要

本文深入剖析了分布式系统中Redis锁的安全隐患。作者通过金融场景的Race Condition案例，揭示了看似简单的SET NX PX锁实现存在的致命问题：当JVM发生GC停顿超过TTL时，锁会过期但持有者不知情，导致多个进程同时访问共享资源。文章还简要提及了Antirez提出的Redlock算法以及Kleppmann对其数学正确性的质疑。

内容框架与概述

文章开篇以金融应用中的取款Race Condition为切入点，说明单机锁在分布式环境中的失效问题。随后介绍了分布式锁的三种主流方案：Redis、ZooKeeper/Etcd和数据库锁，分析了大多数团队选择Redis的原因。文章重点揭示了Redis简单锁实现的陷阱：GC停顿会导致进程看似死亡而锁已过期，引发数据损坏。最后预告了Redlock算法的争议以及正确的解决方案。

核心概念及解读

Race Condition：竞态条件，指多个进程并发访问共享资源时执行顺序不确定，可能导致非预期结果，如重复取款。

TTL Time To Live：锁的过期时间，用于防止应用崩溃后锁永久存在，但GC停顿期间进程仍可能误认为持有锁。

GC Pause Stop-the-World：JVM垃圾回收导致的进程暂停，期间应用完全无响应，但外部时钟仍在流逝，可能超过锁的TTL。

Distributed Lock：分布式锁，独立于应用服务器的共享互斥机制，用于协调多个节点对资源的访问顺序。

Clock Drift：时钟漂移，分布式系统中不同机器时钟不同步的问题，Redlock算法因此被质疑存在正确性缺陷。

原文信息

此摘要卡片由 AI 自动生成