Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> Consistency in zookeeper


Copy link to this message
-
Re: Consistency in zookeeper
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.
>
> -Flavio
>
>
> On Mar 1, 2013, at 7:19 PM, Alexander Shraer <[hidden email]<http://user/SendEmail.jtp?type=node&node=7578538&i=0>>
> 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.
> >
> > Alex
> >
> > On Fri, Mar 1, 2013 at 9:49 AM, kishore g <[hidden email]<http://user/SendEmail.jtp?type=node&node=7578538&i=1>>
> wrote:
> >> 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>>
> wrote:
> >>
> >>> 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
> 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.
> >>>
> >>> 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_zkWatches
> >>> Section: •The data for which the watch was set
> >>>
> >>>
> >>>
> http://zookeeper.apache.org/doc/r3.2.2/zookeeperTutorial.html#sc_producerConsumerQueues
> >>>
> >>> -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

Yasin Celik
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.