Return-Path: X-Original-To: apmail-zookeeper-user-archive@www.apache.org Delivered-To: apmail-zookeeper-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 85CB0E9AA for ; Fri, 1 Mar 2013 05:33:06 +0000 (UTC) Received: (qmail 67003 invoked by uid 500); 1 Mar 2013 05:33:05 -0000 Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org Received: (qmail 66737 invoked by uid 500); 1 Mar 2013 05:33:04 -0000 Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@zookeeper.apache.org Delivered-To: mailing list user@zookeeper.apache.org Received: (qmail 66707 invoked by uid 500); 1 Mar 2013 05:33:04 -0000 Delivered-To: apmail-hadoop-zookeeper-user@hadoop.apache.org Received: (qmail 66699 invoked by uid 99); 1 Mar 2013 05:33:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Mar 2013 05:33:04 +0000 X-ASF-Spam-Status: No, hits=1.3 required=5.0 tests=SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of rakeshr@huawei.com designates 119.145.14.65 as permitted sender) Received: from [119.145.14.65] (HELO szxga02-in.huawei.com) (119.145.14.65) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Mar 2013 05:32:57 +0000 Received: from 172.24.2.119 (EHLO szxeml214-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.3.4-GA FastPath queued) with ESMTP id AXW06280; Fri, 01 Mar 2013 13:32:34 +0800 (CST) Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 1 Mar 2013 13:32:29 +0800 Received: from szxeml561-mbx.china.huawei.com ([169.254.5.88]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 1 Mar 2013 13:32:32 +0800 From: Rakesh R To: "user@zookeeper.apache.org" CC: "zookeeper-user@hadoop.apache.org" Subject: RE: Consistency in zookeeper Thread-Topic: Consistency in zookeeper Thread-Index: AQHOFgxX9791ebmg4k+PxAzFSvapjZiPai2AgADfG2c= Date: Fri, 1 Mar 2013 05:32:31 +0000 Message-ID: References: <1362094516049-7578531.post@n2.nabble.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.96.96] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Virus-Checked: Checked by ClamAV on apache.org Hi Yasin, Adding one more point, ZooKeeper provides different ways of achieving data sync. Like Alex & Vladi= mir explained, sync() api is one way and it has the overhead of performance= . Another approach is to define Watchers. This also will be helpful to keep i= n sync the data between the clients. Its internally using the asynchronous = way of notifying different events. Also, its very light-weight and here use= r/client should define specific watchers to achieve the synchronized view o= f data. ZK supports various events like NodeDataChanged, NodeChildrenChanged. Since= it is asynchronous, there will be slight latency in recieving the events. Reference: http://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#ch_zkWatche= s Section: =95The data for which the watch was set=20 http://zookeeper.apache.org/doc/r3.2.2/zookeeperTutorial.html#sc_producerCo= nsumerQueues -Rakesh ________________________________________ From: Alexander Shraer [shralex@gmail.com] Sent: Friday, March 01, 2013 5:19 AM To: user@zookeeper.apache.org Cc: zookeeper-user@hadoop.apache.org Subject: Re: Consistency in zookeeper Hi Yasin, I assume you mean "linearizability" by "strict consistency". ZooKeeper provides "sequential consistency". This is weaker than linearizability but is still very strong, much stronger than "eventual consistency". In addition, all update operations are linearizable as they are sequenced by the leader. With sequential consistency, a reader never "goes back in time" even if you read from a different follower every time, you'll never see version 3 of the data after seeing version 4. ZooKeeper also provides a sync command. If you invoke a sync command and then a read, the read is guaranteed to see at least the last write that completed before the sync started. So if you always do "sync + read" instead of just "read", you get linearizability. But you pay in performance since these reads will no longer be executed locally on the follower to which you're connected - they sync is sent to the leader. That's why ZooKeeper gives you the option of doing a fast read that is consistent but may retrieve a slightly old version, or a sync+read that is more consistent but slower. Alex On Thu, Feb 28, 2013 at 3:35 PM, Yasin wrote: > Hello everyone, > > From the zookeeper website I understand that zookeeper does not provide > strict consistency in every instance in time. > (http://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#ch_zkGua= rantees) > Have ever anyone considered to make zookeeper strictly consistent at > anytime. What I mean is that any time a value is updated in zookeeper, an= y > client that retrieves the value from any follower should get consistent > result. Is it feasible to improve the zookeeper core so that zookeeper > delivers strict consistency not the eventual consistency? > > Best > > Yasin > > > > -- > View this message in context: http://zookeeper-user.578899.n2.nabble.com/= Consistency-in-zookeeper-tp7578531.html > Sent from the zookeeper-user mailing list archive at Nabble.com.=