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 Plain View
Zookeeper >> mail # user >> Use cases for ZooKeeper


+
Josh Stone 2012-01-05, 04:09
+
Inder Pall 2012-01-05, 05:15
+
Jordan Zimmerman 2012-01-05, 06:46
+
Josh Stone 2012-01-05, 08:04
+
Jordan Zimmerman 2012-01-05, 08:11
+
Ted Dunning 2012-01-05, 08:50
+
Jordan Zimmerman 2012-01-05, 08:55
+
Inder Pall 2012-01-05, 13:00
+
Jordan Zimmerman 2012-01-05, 17:41
+
Josh Stone 2012-01-05, 17:56
+
Jordan Zimmerman 2012-01-05, 18:02
+
Josh Stone 2012-01-05, 18:54
+
Jordan Zimmerman 2012-01-05, 18:59
Copy link to this message
-
Re: Use cases for ZooKeeper
This severely limits the throughput of this kind of approach.

The pro is that you get quite a bit of fine-grained resiliency.

The micro-sharding of traffic approach gives you very high throughput
(easily high enough, for instance, to handle all of twitter's traffic).

The con for micro-sharding is that there isn't any reliable delivery baked
in so the sender basically has to wait for an ACK and try again if no
delivery happens.  If you depend on a single sink for each key range shard,
then you will not be able to send until a new recipient for that shard is
designated.  This could take session-expiration-time plus epsilon so you
have to be able to handle that much back pressure in the message queue.

An alternative would be to designate multiple sinks for each key range
shard.  That loses some of the coherency that I think you were after, but
if you strictly prioritize you can convert the cost of node failure from
significant back-pressure to slightly degraded coherency.  For a clean node
failure, you would get fast cutover, but with a flapping node you might get
some strange effects.  If a node started losing messages, you would also
get some bad effects there where the backups would get random bits of
traffic rather than all of the traffic.

CAP applies as always with these things.
On Thu, Jan 5, 2012 at 10:59 AM, Jordan Zimmerman <[EMAIL PROTECTED]>wrote:

> They're stored in ZooKeeper, so both. ZooKeeper backs everything to disk
> but keeps the entire DB in memory for performance.
>
> -JZ
>
> On 1/5/12 10:54 AM, "Josh Stone" <[EMAIL PROTECTED]> wrote:
>
> >Are the distributed queue and locks written to disk or can they be held in
> >memory?
> >
> >josh
> >
> >On Thu, Jan 5, 2012 at 10:02 AM, Jordan Zimmerman
> ><[EMAIL PROTECTED]>wrote:
> >
> >> Curator's queue handles a node going down (when you use setLockPath()).
> >> Curator will hold a lock for each message that is being processed. You
> >>can
> >> see the implementation in the method processWithLockSafety() here:
> >>
> >>
> https://github.com/Netflix/curator/blob/master/curator-recipes/src/main/j
> >>av
> >> a/com/netflix/curator/framework/recipes/queue/DistributedQueue.java
> >>
> >> >Will a node going down still clear any distributed locks?
> >> Yes.
> >>
> >>
> >> -JZ
> >>
> >> On 1/5/12 9:56 AM, "Josh Stone" <[EMAIL PROTECTED]> wrote:
> >>
> >> >Yes, something like that with lock safety would satisfy my third use
> >>case.
> >> >
> >> >Some questions: Is the distributed queue effectively located by a
> >>single
> >> >z-node? What happens when that node goes down? Will a node going down
> >> >still
> >> >clear any distributed locks?
> >> >
> >> >Josh
> >> >
> >> >On Thu, Jan 5, 2012 at 9:41 AM, Jordan Zimmerman
> >> ><[EMAIL PROTECTED]>wrote:
> >> >
> >> >> FYI - Curator has a resilient message Queue:
> >> >> https://github.com/Netflix/curator/wiki/Distributed-Queue
> >> >>
> >> >> On 1/5/12 5:00 AM, "Inder Pall" <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> >Third use case: Fault tolerance. If we utilized ZooKeeper to
> >>distribute
> >> >> >messages to workers, can it be made to handle a node going down by
> >> >> >re-distributing the work to another node (perhaps messages that are
> >>not
> >> >> >ack'ed within a timeout are resent)?
> >> >>
> >> >>
> >>
> >>
>
>
+
Josh Stone 2012-01-05, 17:38
+
Jordan Zimmerman 2012-01-12, 17:52
+
Ted Dunning 2012-01-13, 02:18
+
Jordan Zimmerman 2012-01-13, 04:01
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