Go At Heroku (Doozer)(blog.golang.org) |
Go At Heroku (Doozer)(blog.golang.org) |
I've been talking with Keith and Blake since before christmas and their thinking is solid. If you are interested in running a consistent store this is probably one of your best bets, unless you happen to work at Google and have access to chubby (I'm an ex-Googler).
Without some way of knowing if a process fails, it's hard to do leader election, locks, other synchronisation patterns. It would be a reasonable design choice to do failure detection completely out of band with the sequentially consistent store, but I'd like to understand their architecture better.
http://the-paper-trail.org/blog/?p=173
and http://the-paper-trail.org/blog/?p=190
for some tutorials I wrote on the subject.
You're correct that failure detection and consensus are very deeply related, in that a strong failure detector is 'sufficient' for consensus.
But my point is about client failure detection, not failure detection between servers (which must have some kind of timeout system; that's ok - you just sacrifice liveness in a few pathological cases rather than sacrificing correctness). If I am to implement leader election with Doozer, does Doozer provide any tools to help us with deciding when to elect a new leader? There's no reason it should, but ZooKeeper, for example, does have that in its arsenal.
Doozer doesn't, AFAIK, expose consensus as a primitive; that's not its model. So the fact that it uses Paxos, or ZAB, or 2PC or whatever doesn't make a difference to its clients.