Mailing-List: contact dev-help@kafka.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@kafka.apache.org
Received-SPF: pass (athena.apache.org: domain of junrao@gmail.com designates
 209.85.219.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAOeJiJg=XhRW8qrawu3_8dA8K9Rn3UG__FxV_YgqGm72JMp05Q@mail.gmail.com>
References: 
 <CAOeJiJg=XhRW8qrawu3_8dA8K9Rn3UG__FxV_YgqGm72JMp05Q@mail.gmail.com>
Date: Sun, 14 Apr 2013 21:42:42 -0700
Message-ID: 
 <CAFbh0Q1kYBtER7s1ksRMfJFcjqJjaZaubhYt27qtfUhTfaeRBw@mail.gmail.com>
Subject: Re: interesting paper on log replication
From: Jun Rao <junrao@gmail.com>
To: "dev@kafka.apache.org" <dev@kafka.apache.org>
Content-Type: multipart/alternative; boundary=089e011776eb23030c04da5ee221

--089e011776eb23030c04da5ee221
Content-Type: text/plain; charset=ISO-8859-1

Thanks for the link. This paper provides an alternative, but similar
implementation to that in Zookeeper. The key difference seems to be that
the former supports membership reconfiguration.

Kafka replication is simpler because it separates the leader election part
from log replication. Such separation has a few benefits: (1) the leader
election part is easier to implement by leveraging a consensus system (e.g.
Zookeeper); (2) the log format is simpler since the log itself is not used
for leader election; (3) the replication factor for the log is decoupled
from the number of parties required for leader election (e.g., in Kafka we
can choose a replication factor of 2 for the log while using an ensemble of
5 for a Zookeeper cluster).

Both Rafe and Zookeeper are solving a harder problem than Kafka replication
because they have no consensus service to rely upon for their own leader
election since they are implementing a consensus service.

Thanks,

Jun


On Tue, Apr 9, 2013 at 10:34 PM, Jay Kreps <jay.kreps@gmail.com> wrote:

> Very similar in design to kafka replication
> https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf
>
> -Jay
>

--089e011776eb23030c04da5ee221--