FWIW, we have this crazy idea of using something like an extracted ZAB for maintaining quorum-cliques
in a modified HBase cluster: https://issues.apache.org/jira/browse/HBASE-2357
- Andy
> From: Benjamin Reed <breed@yahoo-inc.com>
> Subject: Re: Extracting Zab from Zookeeper
> To: "dev@zookeeper.apache.org" <dev@zookeeper.apache.org>
> Cc: "Ted Dunning" <ted.dunning@gmail.com>, "user@zookeeper.apache.org" <user@zookeeper.apache.org>
> Date: Friday, January 28, 2011, 10:27 AM
> flavio and ted are correct. zab and
> zookeeper are tightly coupled, and
> as flavio points out, zab provides a bit more than just
> atomic broadcast.
>
> i think it would be a good thing to do for three reasons:
>
> 1) it would make testing, benchmarking, and fixing that layer
> (especially for ZOOKEEPER-22) much easier.
> 2) we could try different backends easier. (i'd love to try
> using bookkeeper for example.)
> 3) although the zab interface must be richer than normal
> atomic broadcast (access to past transactions, for example), i
> think in practice applications that do primary/backup can benefit
> from this richer interface.
>
> ben
>
> On 01/28/2011 07:03 AM, Ted Dunning wrote:
> > I think that what Flavio was saying is that it is like
> > pulling a string on a sweater. Almost any application that
> > wants ZAB is probably going to need the broadcast and they the
> > broadcast, they will want to have logging. And transactions.
> > And so on.
> >
> > Moreover, some of these features are not necessarily
> > encoded in ZK in a way that you can point to. Instead they are
> > enabled by the way that several functional units are glued
> > together.
|