I've been looking at Zookeeper recently and wondered whether anybody was using it currently and what they were specifically using it for storing.
The most common use case is for configuration information, but what kind of data and how much data are you storing?
Old question, but since this page comes up first on a google search for zookeeper use cases, I figured it would be best to give an updated listing
Storm uses Zookeeper to store all state so that it can recover from an outage in any of its (distributed) component services.
This allows the component services to be stateless and simply download or sync with the Zookeeper servers when configuration data is needed. If you have ever had to recover a production server you will know what a headache this can be!
Kafka queue consumers can use Zookeeper to store information (high water mark) on what has been consumed from the queue.
HBase uses Zookeeper for coordinating activities its "head node" was responsible for prior to the current version. The move to using Zookeeper means the central control is no longer a single point of failure.
Zookeeper is very versatile; here is an example of using it to build a distributed concurrent queue:
http://blog.cloudera.com/blog/2009/05/building-a-distributed-concurrent-queue-with-apache-zookeeper/
You can of course also use it to create resource locks, etc, in a distributed system.
Here's some detail on how HBase uses ZooKeeper, including information on how they intend to use it in future. Generally they use it for eliminating SPOF on the region servers via Leader election implemented using ZooKeeper.
Norbert is a good example from a scalable production system. I general, it integrates Netty, Protocol Buffers and Zookeeper into a lightweight framework for running clustered services. Protocol Buffers are used to specify your service API, Netty implements transport-layer abstractions and Zookeeper is essentially a fault-tolerant discovery service.
Every time a service instance is started Norbert registers it as available instance of a particular service type. From implementation perspective, it creates two Zookeeper trees:
The most important property for each node is the url to use to connect to the corresponding service instance. It enables client-side load balancing - a Norbert client finds the list of urls for a given service name and attempt to connect to one of them is some order (e.g. round-robin or random).
The Apache CXF implementation of DOSGi uses zookeeper for its service registration repository. Individual containers have a distributed software (dsw) bundle that listens for all service events and when a service status changes that has a property indicating distribution. The dsw talks to the discovery bundle which, in the reference implementation case, uses zookeeper to store service as ephemeral nodes. Other instances will look for changes to the node structure and register proxies on their local systems. The end result is you can code to plain OSGi and end up with transparent distribution.