Distributed Mutex in Go with Redlock

Local mutexes synchronise access to data within a single process, but many real-world systems need to coordinate access to shared resources such as databases or queues. This talk examines how the Redlock algorithm, built on Redis, enables Go services to manage concurrency safely and efficiently across multiple instances.

Transcript

1. Distributed Mutex in Go with Redlock Wisdom Matthew Senior Backend Engineer @ Nala
2. Problem: Race Condition
3. What we want
4. What we might get This Or This
5. Distributed Locks: What? A distributed lock coordinates access to a shared resource across multiple processes or services, ensuring that only one of them can access or modify that resource at a time.
6. Distributed Locks: Why? 💥 Prevent race conditions across distributed services 🔒 Protect shared resources ‼ Avoid double-processing and duplicate side-effects 🚫 Essential when partial/atomic updates aren’t supported
7. Redlock: What? 🔐 Distributed locking algorithm built on top of Redis 🗳 Uses a majority of Redis nodes to grant a lock ⏳ Locks have a TTL to prevent deadlocks 🆔 Uses a unique token to validate lock ownership
8. Redlock: Guarantees 🔐 Mutual Exclusion ⏳ Deadlock Free 💥 Fault Tolerance
9. Redlock: Algorithm
10. Retry on Failure 🔁 Lock acquisition attempts can fail 🧹 Clean up partial locks first ⏱ Retry after a random delay
11. Single Instance Lock Acquisition
12. Single Instance Lock Release
13. Example with Distributed Lock
14. What we will always get
15. Code Snippet with Redsync: Initialization
16. Code Snippet with Redsync
17. References redis.io/topics/distlock github.com/go-redsync/redsync martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html antirez.com/news/101
18. Thank You! @wisdommatt