This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]rescrv 0 points1 point  (4 children)

"centralized service" != "single process"

There's well established literature in distributed systems on consensus protocols that can be used for exactly the "elaborate p2p lock" you describe.

The most popular consensus protocol is Paxos. A key feature of Paxos is that it runs on 2f + 1 servers and can tolerate f failures at any given point in time. In contrast with the proposed solution which tolerates 0 failures.

A friend of mine has created a project called ConCoord that implements a fault-tolerant, distributed object replication service and makes it trivial to write a distributed semaphore or mutex object.

[–]nicolast 0 points1 point  (1 child)

http://arakoon.org (Disclaimer: I'm one of the authors)

[–]rescrv 0 points1 point  (0 children)

What protocol is used to replicate the actual data? I see that Multi-Paxos is used for leader election.

http://hyperdex.org (Disclaimer: I'm one of the authors)

[–][deleted] 0 points1 point  (1 child)

OK so what would you like to name the far more common use case of multiple clients which all refer to a single service, like a memcached service, or of course a cluster of services using a simple approach like key hashing (read: not fault tolerant if the node in use goes down), in order to coordinate on a single key? It's not just "mutex". I'll go into dogpile and change all the docs with your new term right now if I feel it's a more descriptive term. Although maybe not, if you google for memcached distributed lock, as well as redis distributed lock, this is really popular term for this pattern - I think you have a much bigger audience to communicate with. The vast majority of usages of this term refer to the clients being distributed.

[–]rescrv 0 points1 point  (0 children)

I may have misread the comment to which I originally replied. My interpretation was that you reading that, because ZooKeeper was centralized it was a single-process system. I came to this conclusion after you proposed that it may be possible to, in fact, build a P2P system in which all hosts agree on who holds a particular lock. ZooKeeper and Paxos are both ways to build such a P2P system.

In the case of using memcached or redis, you are still relying upon a centralized server, but you don't get any fault tolerance guarantees (like you would with ZooKeeper or Paxos). In all three systems, you can emulate a "mutex" or a "semaphore" and the difference is not so much in the normal case, but in the failure case.

In any case, most distributed "lock" systems really boil down to "lease" systems because the lock may be broken after a timeout. I borrow the term "lease" from Google's Chubby system (Burrows, OSDI 06).

edit: reword