zookeeper-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r925272 - in /websites/staging/zookeeper/trunk/content: ./ bookkeeper/index.html
Date Fri, 10 Oct 2014 14:03:50 GMT
Author: buildbot
Date: Fri Oct 10 14:03:50 2014
New Revision: 925272

Staging update by buildbot for zookeeper

    websites/staging/zookeeper/trunk/content/   (props changed)

Propchange: websites/staging/zookeeper/trunk/content/
--- cms:source-revision (original)
+++ cms:source-revision Fri Oct 10 14:03:50 2014
@@ -1 +1 @@

Modified: websites/staging/zookeeper/trunk/content/bookkeeper/index.html
--- websites/staging/zookeeper/trunk/content/bookkeeper/index.html (original)
+++ websites/staging/zookeeper/trunk/content/bookkeeper/index.html Fri Oct 10 14:03:50 2014
@@ -57,7 +57,48 @@
 <p>The Apache BookKeeper subproject of ZooKeeper is made up of a distributed logging
service called BookKeeper and a distributed publish/subscribe system built on top of BookKeeper
called Hedwig.</p>
-<h2>What is BookKeeper?</h2>
+<h2>What is Bookkeeper?</h2>
+<p>Bookkeeper is a replicated log service which can be used to build<br />
+[http://en.wikipedia.org/wiki/State_machine_replication replicated state machines]. A log
contains a sequence of events which can<br />
+be applied to a [http://en.wikipedia.org/wiki/Finite-state_machine state machine]. Bookkeeper
guarantees that each replica<br />
+state machine will see all the same entries, in the same order.</p>
+<h2>Eh? What good is that to me?</h2>
+<p>Imagine for example that you have a database that you want to be able<br />
+access even if the database server goes down. You'll need to replicate<br />
+it to multiple servers. You need to ensure that if one database sees an<br />
+update, all databases see the update. But what happens if one database<br />
+server is cut off from the network for a time? Or if two clients try to<br />
+update the same field at exactly the same instance? This is where a<br />
+replicated log comes in.</p>
+<p>A database can be seen as a state machine. It is the sum of all the<br />
+updates which is has applied since its initial state. Therefore, if you<br />
+consider your replicated database as a replicated statemachine, you can<br />
+do the replication using a replicated log service. If all updates are<br />
+written to the log replication service before being applied to the<br />
+database, then the database will continue to be available and consistent<br />
+even if some of the replicas fail.</p>
+<p>This approach can be applied to many types of distributed systems, such<br />
+as messaging systems, coordination systems, filesystems, etc.</p>
+<h2>What bookkeeper is not?</h2>
+<p>Bookkeeper has nothing to do with application/error/trace logging. There<br />
+are already many projects (link to log4j, slf4j, logback) dedicated to<br />
+that problem.</p>
+<p>Bookkeeper does not provide leader election. You'll need to use something like [http://zookeeper.apache.org
Zookeeper] for that.</p>
+<h2>How about Hedwig?</h2>
+<p>Hedwig is a distributed publish and subscribe system, which uses<br />
+bookkeeper to replicate its messages.</p>
+<h2>More information</h2>
 <p>Learn more about BookKeeper on the <a href="https://cwiki.apache.org/confluence/display/BOOKKEEPER/BookKeeper">BookKeeper
Wiki</a>.<br />
 Learn more about Hedwig on the <a href="https://cwiki.apache.org/confluence/display/BOOKKEEPER/HedWig">Hedwig

View raw message