hadoop-zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Reed <br...@yahoo-inc.com>
Subject Re: ZAB kick Paxos butt?
Date Wed, 20 Jan 2010 18:15:51 GMT
hi Qing,

i'm glad you like the page and Zab.

yes, we are very familiar with Paxos. that page is meant to show a 
weakness of Paxos and a design point for Zab. it is not to say Paxos is 
not useful. Paxos is used in the real world in production systems. 
sometimes there are not order dependencies between messages, so Paxos is 
fine.

in cases where order is important, multiple messages are batched into a 
single operation and only one operation is outstanding at a time. (i 
believe that this is what Chubby does, for example.) this is the 
solution you allude to: wait for 27 to commit before 28 is issued.

for ZooKeeper we do have order dependencies and we wanted to have 
multiple operations in progress at various stages of the pipeline to 
allow us to lower latencies as well as increase our bandwidth 
utilization, which led us to Zab.

ben

Qing Yan wrote:
> Hello,
>     Anyone familer with Paxos protocol here?
>     I was doing some comparision of ZAB vs Paxos... first of all, ZAB's FIFO
> based protocol is really cool!
>
>  http://wiki.apache.org/hadoop/ZooKeeper/PaxosRun mentioned the
> inconsistency case for Paxos("the state change B depends upon A, but A was
> not committed").
>  In the "Paxos made simple" paper, author suggests fill the GAP (lost state
> machine changes) with "NO OP" opeartion.
>
>   Now I have some serious doubts how could Paxos be any useful in the real
> world. yeah you do reach the consesus - albeit the content
> is inconsistent/corrupted !?
>
>   E.g. on the wiki page, why the Paxos state machine allow fire off 27,28
> concurrently where there is actually depedency? Shouldn't you wait instance
> 27 to be committed before start 28?
>   Did I miss something?
>
>   Thanks for the enlight!
>
>    Cheers
>
>     Qing
>   


Mime
View raw message