Distributed Locks with Redis (2014)
1–10 of 41 posts
Re: Distributed Locks with Redis (2014)
#2Martin Kleppmann has some interesting thoughts on Redlock:
> I think the Redlock algorithm is a poor choice because it is “neither fish nor fowl”: it is unnecessarily heavyweight and expensive for efficiency-optimization locks, but it is not sufficiently safe for situations in which correctness depends on the lock.
https://martin.kleppmann.com/2016/02/08/how-to-do-distribute...
Re: Distributed Locks with Redis (2014)
#3Where's the Jepsen suite tests?
Without it this is alphaware at best
Re: Distributed Locks with Redis (2014)
#4Martin Kleppmann has some interesting thoughts on Redlock: > I think the Redlock algorithm is a poor choice because it is “neither fish nor fowl”: it is unnecessarily heavyweight and expensive for efficiency-optimization locks, but it is not sufficiently safe for situations in which correctness depends on the lock. https://martin.kleppmann.com/2016/02/08/how-to-do-distribute...
Salvatore Sanfilippo (author of Redis and Redlock) wrote a response to Martin Kleppmann's analysis that is worth a read (though it is a bit dense and hard to follow at times): http://antirez.com/news/101
I think I agree with Kleppmann's analysis, though.
Re: Distributed Locks with Redis (2014)
#5Famously broken badly for anything mission critical.
Re: Distributed Locks with Redis (2014)
#6Martin Kleppmann has some interesting thoughts on Redlock: > I think the Redlock algorithm is a poor choice because it is “neither fish nor fowl”: it is unnecessarily heavyweight and expensive for efficiency-optimization locks, but it is not sufficiently safe for situations in which correctness depends on the lock. https://martin.kleppmann.com/2016/02/08/how-to-do-distribute...
Salvatore Sanfilippo (author of Redis and Redlock) wrote a response to Martin Kleppmann's analysis that is worth a read (though it is a bit dense and hard to follow at times): http://antirez.com/news/101 I think I agree with Kleppmann's analysis, though.
> The algorithm's goal was to move away people that were using a single Redis instance, or a master-slave setup with failover, in order to implement distributed locks, to something much more reliable and safe, but having a very low complexity and good performance.
I think this is good perspective. More reliable + more safe + good performance - Fine, its not perfect, but I bet if you are currently using a single node redis lock and keep running into problems when it goes down, these improvements sound nice.
Some of antirez's comments surprise me a bit though
> A distributed lock without an auto release mechanism, where the lock owner will hold it indefinitely, is basically useless.
I have found durable locks very practical and useful
Re: Distributed Locks with Redis (2014)
#7Something I don't enjoy about remote/distributed locks is that unlike distributed transactions they're usually unable to provide any strict guarantees about things they protect.
E.g. if you algorithm is:
1) Hold the distributed lock
2) Do the thing
3) Release the lock
And the node goes dark for a while between steps 1 and 2 (e.g. 100% CPU load), by the time it reaches 2 the lock may have already expired and another node is holding it, resulting in a race. Adding steps like "1.1 double/triple check the lock is still held" obviously doesn't help because the node can go dark right after these and resume operation at 2. The probability of these is not too high, but still: no guarantees. Furthermore at a certain scale you do actually start seeing rogue nodes deemed dead hours ago suddenly coming back to life and doing unpleasant things.
The rule of thumb usually is "keep locks within the same transaction space as the thing they protect", and often you don't even needs locks in that case, just transactions can be enough by themselves. If you're trying to protect something that inherently un-transactional then, well, good luck because these efforts are always probabilistic in nature.
A good use-case for a remote lock would be when it's not actually used to guarantee consistency or avoid races, but merely tries to prevent duplicate calculations for cost/performance considerations. For all other cases I outright recommend avoiding them.
Re: Distributed Locks with Redis (2014)
#8Earlier quoted context omitted.
Salvatore Sanfilippo (author of Redis and Redlock) wrote a response to Martin Kleppmann's analysis that is worth a read (though it is a bit dense and hard to follow at times): http://antirez.com/news/101 I think I agree with Kleppmann's analysis, though.
> The algorithm's goal was to move away people that were using a single Redis instance, or a master-slave setup with failover, in order to implement distributed locks, to something much more reliable and safe, but having a very low complexity and good performance. I think this is good perspective. More reliable + more safe + good performance - Fine, its not perfect, but I bet if you are currently using a single node…
Durable locks have a partitioning problem. If the lock holder gets hit by a tornado or catches on fire then there is no recovery method short of manual intervention.
I took a formal class on distributed systems back when dinosaurs roamed the earth and the implementation of Ethernet was still considered interesting. And even back then we talked about leases for locks.
Re: Distributed Locks with Redis (2014)
#9Martin Kleppmann has some interesting thoughts on Redlock: > I think the Redlock algorithm is a poor choice because it is “neither fish nor fowl”: it is unnecessarily heavyweight and expensive for efficiency-optimization locks, but it is not sufficiently safe for situations in which correctness depends on the lock. https://martin.kleppmann.com/2016/02/08/how-to-do-distribute...
"Those who don't understand ACID are doomed to reimplement it... poorly"
Re: Distributed Locks with Redis (2014)
#10Where's the Jepsen suite tests? Without it this is alphaware at best
It's like a 50's ad slogan. If it doesn't _____, then I won't _____.