Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB