Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> Problems about Zab protocol


Copy link to this message
-
Re: Problems about Zab protocol
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
<[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]]
>> Sent: Wednesday, April 20, 2011 2:38 AM
>> To: [EMAIL PROTECTED]
>> 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.
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB