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 <[email protected]> > Subject: Re: Extracting Zab from Zookeeper > To: "[email protected]" <[email protected]> > Cc: "Ted Dunning" <[email protected]>, "[email protected]" > <[email protected]> > 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.
