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 Plain View
Zookeeper >> mail # user >> Problems about Zab protocol


+
daidong 2011-04-20, 09:37
Copy link to this message
-
RE: Problems about Zab protocol
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.
+
Benjamin Reed 2011-04-20, 20:26
+
André Oriani 2011-04-20, 23:20
+
daidong 2011-04-21, 06:33
+
daidong 2011-04-21, 06:35
+
Flavio Junqueira 2011-04-21, 07:48
+
daidong 2011-04-21, 06:30
+
Alexander Shraer 2011-04-21, 19:53
+
daidong 2011-04-23, 04:55
+
Flavio Junqueira 2011-04-25, 07:52
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