系统与基础设施martin.kleppmann.com编辑精选
如何实现分布式锁
How to do distributed locking
2016 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Martin Kleppmann 论述为什么基于 Redis 的 Redlock 算法不是安全的分布式锁：进程暂停、时钟漂移和网络延迟都可能导致锁失效，进而破坏数据正确性。他建议分布式锁只用于效率目的，若涉及正确性应使用 fencing token，或改用 ZooKeeper/etcd 等共识系统。
为什么经久不衰：它把'锁'这个看似简单的原语背后的正确性问题讲透，多年后仍是分布式系统设计者绕不开的参考。
HN 评论精选
Redlock 作者 antirez 逐条反驳，认为唯一 token 足够且系统模型分析有误，将另文回应。
感谢 Martin 对 Redlock 的分析，我期待已久。但我不同意其中两个主要论点。简言之：当持锁者的工作最终体现为数据库写入时，Redlock 的唯一随机 token 足以做 Check & Set（注意 Martin 提出的方案反而需要一个线性一致的数据库来比较 token 大小）；我认为其系统模型分析有问题，算法并不依赖有界的网络延迟，而不同进程在无绝对时钟的情况下以有界误差（如 10%）计量相对时间是可信的。我正在深入分析并写一篇博客详细回应。另外，通常需要分布式锁是因为没有更合理的处理竞态的方式，否则一开始就该用更弱或乐观锁的形式。
antirez查看英文原文
Thanks to Martin for analyzing Redlock, I looked forward to an analysis. I don't agree with the two main arguments of the analysis. TLDR: I think the unique random token of Redlock is enough for Check & Set when the lock holder work materializes into a database write (also note that it requires a linearizable database, to check token_A_ID > token_B_ID in the Martin proposed solution), and I think the system model is very real world (AFAIK the algorithm is not dependent on bounded network delays, I think there is an issue in the analysis, details in my blog post so other people can evaluate), and that the fact different processes can count relative time, without any absolute clock, with a bound error (like, 10%) is absolutely credible. However, I'm analyzing the analysis in depth right now and writing a blog post with the details to be posted tomorrow. Also note that usually when you need a distributed lock, it's because you have no sane way to handle race conditions, otherwise you can do with some weaker and/or optimistic locking form to start with.
总结文章主旨为'用对工具'，推荐用 ZooKeeper 而非 Redis 做分布式锁。
文章很长，但主旨是'用合适的工具做合适的事'。Redis 在某些方面很出色，但就其目前的实现而言，分布式锁不是其中之一。如果你需要在分布式环境中获取锁，我推荐使用 ZooKeeper，可以参考 Jepsen 对 ZooKeeper 在网络分区下表现的测试。
dmuth查看英文原文
It's a long read, but the gist of this article is "use the right tool for the job". Redis is really good for some things, but in its current implementation, distributed locking is not one of them. Along with the author of this blog post, I would recommend the usage of Zookeeper if you have a need for obtaining a lock in a distributed environment. You can read an analysis of how Zookeeper performs under a (intentionally) partitioned network here: https://aphyr.com/posts/291-jepsen-zookeeper
从可扩展性角度指出：需要锁本身就意味着共享，是扩展性的瓶颈。
想要真正并行的系统，就不能在进程间共享资源。需要锁就意味着共享资源，而按 Amdahl 定律这意味着可扩展性受限。要实现无限扩展，必须确保没有单一数据存储被所有进程共享，且进程间通信量不随进程增加而增长。共享越多，越难扩展。
jondubois查看英文原文
If you want to have a truly parallel system, you cannot share resources between processes. If you need a lock, then that implies sharing of resources... Which implies limited scalability according to Amdahl's law. To achieve unlimited scalability, you need to make sure that no single data store is shared between all processes and that the amount of interprocess communication (on a per-process basis) doesn't increase as you add more processes. The more sharing you have, the less you can scale your system.
质疑文中 GitHub 90 秒延迟案例的表述，澄清其实是网络分区而非数据包滞留。
文中引用 GitHub 数据包被延迟约 90 秒的事例让我困惑。读原始资料后，实际情况似乎是数据包被交换机丢弃、节点被分区 90 秒，分区恢复后两个节点都自认为是 leader 并要求对方关闭。让数据包在网络中滞留 90 秒似乎很难。重新读后我认为作者指的是网络栈整体：临时分区可能延迟请求送达，若在 TCP 重试上限之前恢复，请求可能晚于预期到达。
erentz查看英文原文
"If you still don’t believe me about process pauses, then consider instead that the file-writing request may get delayed in the network before reaching the storage service. Packet networks such as Ethernet and IP may delay packets arbitrarily, and they do [7]: in a famous incident at GitHub, packets were delayed in the network for approximately 90 seconds [8]. This means that an application process may send a write request, and it may reach the storage server a minute later when the lease has already expired." This statement confused me. It seems to say that the packets were delayed in the network for 90 seconds before being delivered. From reading the original sources it actually sounds like packets were discarded by the switches, so the original requests discarded, and the nodes were partitioned for 90 seconds. When the partition was removed both nodes thought they were the leader and simultaneously requested the other to shutdown. Can anyone confirm? Keeping packets delayed in a network for 90 seconds would seem quite difficult (though not impossible assuming certain bugs). Edit: On re-reading I think this is just talking about the network stack in general - not the network. A temporary partition may delay delivery of your request until max TCP retries is exceeded on your host, if its recovered before then your request may arrive later than you intended.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选