<?xml version="1.0" encoding="UTF-8"?>
<!--
  Copyright 2002-2004 The Apache Software Foundation

  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
-->

<!DOCTYPE article PUBLIC "-//OASIS//DTD Simplified DocBook XML V1.0//EN"
"http://www.oasis-open.org/docbook/xml/simple/1.0/sdocbook.dtd">
<article id="bk_GettStartedGuide">
  <title>ZooKeeper Observers</title>

  <articleinfo>
    <legalnotice>
      <para>Licensed under the Apache License, Version 2.0 (the "License"); you
	may not use this file except in compliance with the License. You may
	obtain a copy of the License
	at <ulink url="http://www.apache.org/licenses/LICENSE-2.0">http://www.apache.org/licenses/LICENSE-2.0</ulink>.</para>
      
      <para>Unless required by applicable law or agreed to in writing, software
      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
      License for the specific language governing permissions and limitations
      under the License.</para>
    </legalnotice>

    <abstract>
      <para>This guide contains information about using non-voting servers, or
      observers in your ZooKeeper ensembles.</para>
    </abstract>
  </articleinfo>

  <section id="ch_Introduction">
    <title>Observers: Scaling ZooKeeper Without Hurting Write Performance
      </title>
    <para>
      Although ZooKeeper performs very well by having clients connect directly
      to voting members of the ensemble, this architecture makes it hard to
      scale out to huge numbers of clients. The problem is that as we add more
      voting members, the write performance drops. This is due to the fact that
      a write operation requires the agreement of (in general) at least half the
      nodes in an ensemble and therefore the cost of a vote can increase
      significantly as more voters are added.
    </para>
    <para>
      We have introduced a new type of ZooKeeper node called
      an <emphasis>Observer</emphasis> which helps address this problem and
      further improves ZooKeeper's scalability. Observers are non-voting members
      of an ensemble which only hear the results of votes, not the agreement
      protocol that leads up to them. Other than this simple distinction,
      Observers function exactly the same as Followers - clients may connect to
      them and send read and write requests to them. Observers forward these
      requests to the Leader like Followers do, but they then simply wait to
      hear the result of the vote. Because of this, we can increase the number
      of Observers as much as we like without harming the performance of votes.
    </para>
    <para>
      Observers have other advantages. Because they do not vote, they are not a
      critical part of the ZooKeeper ensemble. Therefore they can fail, or be
      disconnected from the cluster, without harming the availability of the
      ZooKeeper service. The benefit to the user is that Observers may connect
      over less reliable network links than Followers. In fact, Observers may be
      used to talk to a ZooKeeper server from another data center. Clients of
      the Observer will see fast reads, as all reads are served locally, and
      writes result in minimal network traffic as the number of messages
      required in the absence of the vote protocol is smaller.
    </para>
  </section>
  <section id="sc_UsingObservers">
    <title>How to use Observers</title>
    <para>Setting up a ZooKeeper ensemble that uses Observers is very simple,
    and requires just two changes to your config files. Firstly, in the config
    file of every node that is to be an Observer, you must place this line:
    </para>
    <programlisting>
      peerType=observer
    </programlisting>
    
    <para>
      This line tells ZooKeeper that the server is to be an Observer. Secondly,
      in every server config file, you must add :observer to the server
      definition line of each Observer. For example:
    </para>
    
    <programlisting>
      server.1:localhost:2181:3181:observer
    </programlisting>
    
    <para>
      This tells every other server that server.1 is an Observer, and that they
      should not expect it to vote. This is all the configuration you need to do
      to add an Observer to your ZooKeeper cluster. Now you can connect to it as
      though it were an ordinary Follower. Try it out, by running:</para>
    <programlisting>
      $ bin/zkCli.sh -server localhost:2181
    </programlisting>
    <para>
      where localhost:2181 is the hostname and port number of the Observer as
      specified in every config file. You should see a command line prompt
      through which you can issue commands like <emphasis>ls</emphasis> to query
      the ZooKeeper service.
    </para>
  </section>
  
  <section id="ch_UseCases">
    <title>Example use cases</title>
    <para>
      Two example use cases for Observers are listed below. In fact, wherever
      you wish to scale the numbe of clients of your ZooKeeper ensemble, or
      where you wish to insulate the critical part of an ensemble from the load
      of dealing with client requests, Observers are a good architectural
      choice.
    </para>
    <itemizedlist>
      <listitem>
	<para> As a datacenter bridge: Forming a ZK ensemble between two
	datacenters is a problematic endeavour as the high variance in latency
	between the datacenters could lead to false positive failure detection
	and partitioning. However if the ensemble runs entirely in one
	datacenter, and the second datacenter runs only Observers, partitions
	aren't problematic as the ensemble remains connected. Clients of the
	Observers may still see and issue proposals.</para>
      </listitem>
      <listitem>
	<para>As a link to a message bus: Some companies have expressed an
	interest in using ZK as a component of a persistent reliable message
	bus. Observers would give a natural integration point for this work: a
	plug-in mechanism could be used to attach the stream of proposals an
	Observer sees to a publish-subscribe system, again without loading the
	core ensemble.
	</para>
      </listitem>
    </itemizedlist>
  </section>
</article>
