The post examines the Redlock algorithm for distributed locking on Redis, highlighting its limitations in terms of timing assumptions and lack of support for fencing tokens, which are crucial for ensuring correctness. It argues that while Redis is suitable for some non-critical locking scenarios, Redlock may not be reliable for critical applications requiring strong consistency. It suggests using more robust consensus algorithms like ZooKeeper when correctness is essential.
Table of contents
What are you using that lock for?Protecting a resource with a lockMaking the lock safe with fencingUsing time to solve consensusBreaking Redlock with bad timingsThe synchrony assumptions of RedlockConclusionReferencesSort: