Live data from Hacker News

How to do distributed locking

martin.kleppmann.com

71–73 of 73 posts

Re: How to do distributed locking

#71
post #66

Earlier quoted context omitted.

Nope, zookeeper nodes have ids that always increment and can be used for fencing, compare-and-set and more...

I was talking about consul and etcd.

In the linked consul documentation, we see a `LockIndex` field in the lock state; https://www.consul.io/docs/agent/http/kv.html confirms that "LockIndex is the number of times this key has successfully been acquired in a lock. If the lock is held, the Session key provides the session that owns the lock."

So you can do fencing with consul.

Re: How to do distributed locking

#72
post #66

Earlier quoted context omitted.

Nope, zookeeper nodes have ids that always increment and can be used for fencing, compare-and-set and more...

I was talking about consul and etcd.

For etcd: https://coreos.com/etcd/docs/0.4.7/etcd-api/

node.modifiedIndex appears sensible for fencing.

Re: How to do distributed locking

#73

Interesting stuff. In all my distributed systems work so far, I've assumed that a distributed lock is a thing to avoid. I really should take another look at them, just as a tool to have at my disposal.

If you assume that your distributed lock gives you transactional guarantees that you are the only lock holder then you are making a mistake. If, however, you can tolerate small overlaps in lock holders you are fine and this helps with numerous distributed algorithms. Further, using other facilities such as fences can make it even more secure. Another feature of ZooKeeper is write-with-version. You could obtain a lock…

BTW - I wrote a Curator Tech Note about this a while ago: https://cwiki.apache.org/confluence/display/CURATOR/TN10
Post reply on HN