zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Oriani <ra078...@students.ic.unicamp.br>
Subject Re: Problems about Zab protocol
Date Wed, 20 Apr 2011 23:20:15 GMT
If you wanna go deep on Zab http://research.yahoo.com/files/YL-2010-007.pdf


On Wed, Apr 20, 2011 at 17:26, Benjamin Reed <breed@apache.org> wrote:
> just to add a bit to alex's reponse: we do a simplified 2pc since we
> do not have aborts. we also differ from 2pc during recovery which is
> made up of two sub phases.
> ben
> On Wed, Apr 20, 2011 at 11:29 AM, Alexander Shraer
> <shralex@yahoo-inc.com> wrote:
>> Hi,
>> Regarding your first question - ZAB has two parts - the broadcast protocol you mention,
>> which is executed by a leader, and the leader election protocol, which recovers from
a leader failure.
>> This is similar to the way other state-machine replication algorithms work, where
you have
>> a fast normal mode and a slower recovery mode (you don't need to execute both all
the time - only when the leader fails).
>> See Paxos state-machine replication for example (section 3): http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html#paxos-simple
>> Regarding your second question - Zookeeper basically guarantees so called "sequential
consistency" semantics.
>> This guarantees that the real execution looks to clients like some sequential execution
in which
>> the operations of every client appear in the order they were submitted. It does not
guarantee that a read of one client
>> returns the latest value written by another client. This allows reads to be executed
locally.  If you need to return the latest
>> state, you can use the sync() call which flushes the pending updates between the
leader and a follower.
>> See also the "consistency guarantees" section here:
>> http://hadoop.apache.org/zookeeper/docs/r3.3.1/zookeeperProgrammers.html
>> Alex
>>> -----Original Message-----
>>> From: daidong [mailto:daidongly@gmail.com]
>>> Sent: Wednesday, April 20, 2011 2:38 AM
>>> To: zookeeper-user@hadoop.apache.org
>>> Subject: Problems about Zab protocol
>>> Hi, everyone.
>>> Recently, i read the paper "a simple total ordered broadcast protocol"
>>> and
>>> there are some problems i can not figure out. Hope anyone can help
>>> me... :P
>>> The paper describes the Zab protocol as a 2 phase commit protocol when
>>> system is under broadcast mode. However some paper(Skeen 82, "A Quorum
>>> Based
>>> Commit Protocol") has mentioned if we want to extend an 2PC to adapt a
>>> quorum based commit protocol we must introduce a three phase commit
>>> protocol(In fact, i haven't quit understood this, :( ). However
>>> according
>>> Zab paper, this still can be done. Why and how to do this?
>>> Secondly, even Zookeeper can guarantee that status in different
>>> followers
>>> are consistent. However, this consistency only works among a quorum of
>>> followers that has acked the COMMIT. As the client can connect to any
>>> followers when perform reading action, so what happens if the client
>>> happens
>>> to connect with the follower that has not acked the COMMIT? I can not
>>> find
>>> the information in this paper...
>>> If i ask some naive question, Hope anybody can tell me where i can find
>>> the
>>> answer or some suggestions, thanks :)
>>> --
>>> View this message in context: http://zookeeper-
>>> user.578899.n2.nabble.com/Problems-about-Zab-protocol-
>>> tp6290102p6290102.html
>>> Sent from the zookeeper-user mailing list archive at Nabble.com.

View raw message