If the lock fails and two nodes end up doing the same piece of work, the Efficiency: Taking a lock saves you from unnecessarily doing the same work twice (e.g.
To distinguish these cases, you can ask what
AtĪ high level, there are two reasons why you might want a lock in a distributed application:įor efficiency or for correctness . To a shared storage system, to perform some computation, to call some external API, or suchlike. Work, only one actually does it (at least only one at a time). The purpose of a lock is to ensure that among several nodes that might try to do the same piece of Arguably, distributed locking is one of those areas. Stronger consistency and durability expectations – which worries me, because this is not what Redis However, Redis has been gradually making inroads into areas of data management where there are Request counters per IP address (for rate limiting purposes) and sets of distinct IP addresses per For example, a good use case is maintaining You occasionally lose that data for whatever reason. Some transient, approximate, fast-changing data between servers, and where it’s not a big deal if I think it’s a good fit in situations where you want to share I won’t go into other aspects of Redis, some of which have already been critiquedīefore I go into the details of Redlock, let me say that I quite like Redis, and I have successfully Who is already relying on this algorithm, I thought it would be worth sharing my notes publicly. Since there are already over 10 independent implementations of Redlock and we don’t know I spent a bit of time thinking about it and writing up these notes.
The algorithm instinctively set off some alarm bells in the back of my mind, so Leases ) on top of Redis, and the page asks for feedback from people who are intoĭistributed systems. The algorithm claims to implement fault-tolerant distributed locks (or rather, As part of the research for my book, I came across an algorithm called Redlock on the
0 kommentar(er)
