Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
3.2.1
-
None
-
None
Description
Regarding http://eng.kaching.com/2010/01/actually-implementing-group-management.html Patrick Hunt asked for a more complete group membership recipe from the one listed at http://hadoop.apache.org/zookeeper/docs/r3.0.0/recipes.html#sc_outOfTheBox.
The relevant text from the blog post:
One type of group management system using ZooKeeper:
- A group contains some logical service. The meaning of belonging to a group is typically "the instance is available for use by clients over the network".
- Services can join and leave the group. The special case of a service crashing or a network outage needs to be handled as leaving the group.
- Joined services share metadata about how to communicate with it, i.e., its IP address, base URL, etc.
- Clients can ask what instances are in the group, i.e., available.
- Clients are notified when group membership changes so they can mutate their local state.
These map onto ZooKeeper as:
- A group is a (permanent) node in the ZooKeeper hierarchy. Clients and services must be told the path to this node.
- A services joins the group by creating an ephemeral node whose parent is the group node. By using an ephemeral node, if the service dies then the service is automatically removed from the group.
- The ephemeral node's data contains the service metadata in some format like JSON, XML, Avro, Protobufs, Thrift, etc. ZooKeeper has no equivalent of HTTP's "Content-Type" header to identify the metadata representation, so services and clients must agree upon the format in some manner.
- Clients can query for the children of the group node to identify the members of the group.
- Clients can place a watch on the group node to be notified if nodes have joined or left the group.