From user-return-6194-apmail-zookeeper-user-archive=zookeeper.apache.org@zookeeper.apache.org Fri Mar 1 20:36:01 2013 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 39032D663 for ; Fri, 1 Mar 2013 20:36:01 +0000 (UTC) Received: (qmail 99567 invoked by uid 500); 1 Mar 2013 20:36:00 -0000 Delivered-To: apmail-zookeeper-user-archive@zookeeper.apache.org Received: (qmail 99498 invoked by uid 500); 1 Mar 2013 20:36:00 -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 99488 invoked by uid 99); 1 Mar 2013 20:36:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Mar 2013 20:36:00 +0000 X-ASF-Spam-Status: No, hits=2.3 required=5.0 tests=FREEMAIL_REPLY,RCVD_IN_DNSWL_NONE,SPF_PASS,URI_HEX X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [77.238.189.213] (HELO nm3-vm0.bullet.mail.ird.yahoo.com) (77.238.189.213) by apache.org (qpsmtpd/0.29) with SMTP; Fri, 01 Mar 2013 20:35:54 +0000 Received: from [77.238.189.51] by nm3.bullet.mail.ird.yahoo.com with NNFMP; 01 Mar 2013 20:35:31 -0000 Received: from [46.228.39.34] by tm4.bullet.mail.ird.yahoo.com with NNFMP; 01 Mar 2013 20:35:31 -0000 Received: from [127.0.0.1] by smtp167.mail.ir2.yahoo.com with NNFMP; 01 Mar 2013 20:35:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1362170131; bh=Kj7kuG9NuROoLvVLyo6s3TMdsb138jGxDesksqBawHY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=wd0FGQ+1d+lJMnqyvOLMtgetK/knJZzK6/WkRCiCIaz1T5yEWtgsoCOu0hqAFwHT438gJT7S4AEl4Mu8vagLWXijWToVrW7+eBdURuw+GVixv2xldVheOgM4EXDQjdd3Z+6quB9fOZAcFEp+uGzL2aH4l4hdQF2+pFdCt6R2Yl4= X-Yahoo-Newman-Id: 103349.86659.bm@smtp167.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: QnWQY.YVM1k1tgH.c2FMPlbc37vBk71Le.aYRRq6MvtCU0U hUgnNZSJTcGMC6iy_YJ2zm1FhtBB.qTGrzEIKHFhtI.NJy5gtErk0veDXcOH eN0JVXKsbZMA4Vudkp8ea.VWAuaUC0zoaz_RE_HpfTxln7pH5718Pnep0F8e 96vUgVZ5yCai1mXBglicCE7I8Ct6nevGVTZbuZ_c15VeOlvS_mp6FNfpe82e wkTQ29aZghlGk02IAj5bhWIuHUFmQpAdWH504Anc_2yi.CK2klD6PtM3Pc80 5_93gPanP9DeGvOaMO8dy8G7lt9onI5qZZkuu97IoJ9Y5H_BybKZ2eWjSVgK WRXHtBV5Jb5J6.2...gBjxapohgUk2lts_vIzSHMqepYr6F7Xki2unmnyVXk d626SRqk0FuYAUVIu2VDFZxsciYyto0GCi14J3gIiN6cqE5j4Ztp5d5yZias 1GrVv2amTTyfqLNwHDKacFQdoIwGT_w8bg.BdfAZxNOYZbdIdka.IoDL_sis kFfQH1HU1vcN1pKJafb88OCJ3lHvJ.9hW8x214hlSmp8axjxy22h8xM.g6Xh U_gkBRACYdh9Thi6PDZdwKmWQqV3ukTUqyxWBMCh8dR3N1wKm0aQUpZ_S_Mr XFLknA4aPiaPWK4ioqCQBbLDMFEGb6agleQVzijlXWX.dAbJpXPWNgvU- X-Yahoo-SMTP: HT5UJDeswBACWJPOeualxAa.da..S.fl Received: from [192.168.1.34] (fpjunqueira@88.6.173.251 with plain) by smtp167.mail.ir2.yahoo.com with SMTP; 01 Mar 2013 20:35:31 +0000 UTC Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Consistency in zookeeper From: Flavio Junqueira In-Reply-To: Date: Fri, 1 Mar 2013 21:35:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1362094516049-7578531.post@n2.nabble.com> To: user@zookeeper.apache.org X-Mailer: Apple Mail (2.1499) X-Virus-Checked: Checked by ClamAV on apache.org Let me add a couple points to this thread. Yasin didn't ask about a = concrete use case, it sounds more like an exploration question rather = than a question about how to solve a particular problem. If there is a = use case behind the question, it would be great to hear about it. One reason we had to serve read requests locally comes from the = assumption that zookeeper traffic is dominated by reads. By processing = read requests locally, we can increase throughput capacity by adding = more servers.=20 The consistency guarantee that zookeeper provides is not eventual in the = sense I'm used to: replicas can diverge but they eventually converge. ZK = replica servers don't diverge but they can be arbitrarily behind on the = application of updates that have been decided upon. We can control to = some extent how far behind a follower can be by changing syncLimit. -Flavio=20 =20 On Mar 1, 2013, at 7:19 PM, Alexander Shraer wrote: > its possible, but what it gets you is that the read will see at least > the writes that completed before the sync started. > possibly later writes too. Actually, this is true only with some > timing assumption. As was previously discussed on the > list, in order to really guarantee this property even with leader > failures, the leader would have to broadcast sync commands just like > updates, > which it currently doesn't do for some reason. >=20 > Alex >=20 > On Fri, Mar 1, 2013 at 9:49 AM, kishore g wrote: >> Will sync and read really help to achieve what Yasin wants ? is it = not >> possible for value to change between sync and read? >>=20 >> Thanks >> Kishore G >>=20 >>=20 >> On Thu, Feb 28, 2013 at 9:32 PM, Rakesh R wrote: >>=20 >>> Hi Yasin, >>>=20 >>> Adding one more point, >>>=20 >>> ZooKeeper provides different ways of achieving data sync. Like Alex = & >>> Vladimir explained, sync() api is one way and it has the overhead of >>> performance. >>>=20 >>> Another approach is to define Watchers. This also will be helpful to = keep >>> in sync the data between the clients. Its internally using the = asynchronous >>> way of notifying different events. Also, its very light-weight and = here >>> user/client should define specific watchers to achieve the = synchronized >>> view of data. >>>=20 >>> ZK supports various events like NodeDataChanged, = NodeChildrenChanged. >>> Since it is asynchronous, there will be slight latency in recieving = the >>> events. >>>=20 >>> Reference: >>>=20 >>> = http://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#ch_zkWatch= es >>> Section: =95The data for which the watch was set >>>=20 >>>=20 >>> = http://zookeeper.apache.org/doc/r3.2.2/zookeeperTutorial.html#sc_producerC= onsumerQueues >>>=20 >>> -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 >>>=20 >>> Hi Yasin, >>>=20 >>> I assume you mean "linearizability" by "strict consistency". >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Alex >>>=20 >>> On Thu, Feb 28, 2013 at 3:35 PM, Yasin = wrote: >>>> Hello everyone, >>>>=20 >>>> =46rom 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_zkGuara= ntees >>> ) >>>> Have ever anyone considered to make zookeeper strictly consistent = at >>>> anytime. What I mean is that any time a value is updated in = zookeeper, >>> any >>>> 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? >>>>=20 >>>> Best >>>>=20 >>>> Yasin >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> View this message in context: >>> = http://zookeeper-user.578899.n2.nabble.com/Consistency-in-zookeeper-tp7578= 531.html >>>> Sent from the zookeeper-user mailing list archive at Nabble.com. >>>=20