Yasin 2013-02-28, 23:35
Alexander Shraer 2013-02-28, 23:49
Rakesh R 2013-03-01, 05:32
kishore g 2013-03-01, 17:49
Alexander Shraer 2013-03-01, 18:19
Flavio Junqueira 2013-03-01, 20:35
I am trying to build a system that is always consistent to any client. For
example a client sends a write request to update x from x=4 to x=5 to
zookeeper and zookeeper leader sends this write request to the followers.
In the meantime, the same client wants to read x, and it gets the old value
(x=4) from some follower which has not updated the x value. I understand
client will get x=5 if it sync before read. This is the consistency model
that zookeeper provides. In this case the performance will decrease.
On Fri, Mar 1, 2013 at 3:36 PM, Flavio Junqueira-2 [via zookeeper-user] <
ml-node+[EMAIL PROTECTED]> wrote:
> 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.
> 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.
> On Mar 1, 2013, at 7:19 PM, Alexander Shraer <[hidden email]<http://user/SendEmail.jtp?type=node&node=7578538&i=0>>
> > 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.
> > Alex
> > On Fri, Mar 1, 2013 at 9:49 AM, kishore g <[hidden email]<http://user/SendEmail.jtp?type=node&node=7578538&i=1>>
> >> Will sync and read really help to achieve what Yasin wants ? is it not
> >> possible for value to change between sync and read?
> >> Thanks
> >> Kishore G
> >> On Thu, Feb 28, 2013 at 9:32 PM, Rakesh R <[hidden email]<http://user/SendEmail.jtp?type=node&node=7578538&i=2>>
> >>> Hi Yasin,
> >>> Adding one more point,
> >>> ZooKeeper provides different ways of achieving data sync. Like Alex &
> >>> Vladimir 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
> >>> in sync the data between the clients. Its internally using the
> >>> way of notifying different events. Also, its very light-weight and
> >>> user/client should define specific watchers to achieve the
> >>> view of data.
> >>> ZK supports various events like NodeDataChanged, NodeChildrenChanged.
> >>> Since it is asynchronous, there will be slight latency in recieving
> >>> events.
> >>> Reference:
> >>> Section: •The data for which the watch was set
> >>> -Rakesh
> >>> ________________________________________
> >>> From: Alexander Shraer [[hidden email]<http://user/SendEmail.jtp?type=node&node=7578538&i=3>]
> >>> Sent: Friday, March 01, 2013 5:19 AM
> >>> To: [hidden email]<http://user/SendEmail.jtp?type=node&node=7578538&i=4>
> >>> Cc: [hidden email]<http://user/SendEmail.jtp?type=node&node=7578538&i=5>
> >>> Subject: Re: Consistency in zookeeper
View this message in context: http://zookeeper-user.578899.n2.nabble.com/Consistency-in-zookeeper-tp7578531p7578539.html
Sent from the zookeeper-user mailing list archive at Nabble.com.
Yasin 2013-03-01, 20:50
kishore g 2013-03-01, 21:17
Yasin 2013-03-01, 21:38
Martin Kou 2013-03-01, 21:50
Jordan Zimmerman 2013-03-01, 22:01
Ted Dunning 2013-03-02, 02:03
Rakesh R 2013-03-03, 09:51
Ted Dunning 2013-03-02, 02:00