5.3. Distributed Locking
A distributed lock promises mutual exclusion across machines, but the promise is fragile: the moment a lock holder pauses — for GC, for a network blip — its lease can expire and a second holder can acquire the same lock, with both believing they hold it. This chapter covers lease-based locking, the fencing tokens that make locks safe for correctness (not just efficiency), and the Redlock debate that crystallizes exactly when a distributed lock can and cannot be trusted.
Topics Covered
Section titled “Topics Covered”- 5.3.1. Lock Fundamentals: Mutual Exclusion in Distributed Systems: Establishes mutual exclusion in a distributed setting and why it is fundamentally harder than in-process locking.
- 5.3.2. Lease-Based Locking: TTL, Renewal, and Expiry Semantics: Covers lease-based locking with TTL, renewal, and the expiry semantics that make locks self-releasing.
- 5.3.3. Fencing Tokens: Preventing Stale Lock Holders: Explains fencing tokens in depth, the monotonic counter that stops a paused lock holder from corrupting state.
- 5.3.4. Redlock Algorithm: The Redis Distributed Lock Debate: Presents both sides of the Redlock debate and when a Redis-based lock can and cannot be trusted.
- 5.3.5. ZooKeeper and etcd Recipes: Production Lock Implementations: Covers production-grade lock recipes built on ZooKeeper and etcd using ephemeral nodes and leases.