We continue discussing the ZooKeeper. It is a co-ordination service with elements from group messaging, shared registers and distributed lock services. It provides a interface that guarantees wait-free property and FIFO execution of requests from each client. Requests across all clients are also linearized.
We now look at some examples of primitives that are possible with ZooKeeper. These primitives exist only on the client side.
ConfigurationManagement - ZooKeeper can be used to implement dynamic configuration in a distributed application. This is one of the basic schemes where each configuration is stored in the form of ZNode. Processes wake up with the fullname of ZNode and set a watch on it. If the configuration is updated, the processes are notified and they apply the updates.
Rendezvous Node. Sometimes a configuration change is dependent others. For example, host and port may be known only afterwards. In this case clients can co-ordinate with a rendezvous node.
The node is filled in with details as and when they become available. The workers set a watch on this node before they begin their changes.
GroipMembership is another common co-ordination requirement. This primitive is implemented using ephemeral nodes. A node is designated to represent the group and is created at the start of the session. When a process member of the group starts, it creates an ephemeral child node under this group node. This child node keeps information for the process that creates it. If the process fails or exits, the node is automatically removed. Group membership can simply be enumerated by listing these child nodes.
Simple Locks: ZooKeeper can also be used to implement locks. Applications implement locks using lock files represented by a ZNode. To acquire a lock, the client tries to create the designated node with the ephemeral flag. If the create succeeds, the client holds the lock otherwise the client watches the node in case the leader dies. Whenever the znode is deleted, other clients may try to acquire the lock. There are two side-effects of this locking mechanism: First, there is a herd effect when all clients vie for a lock even though only one acquires it. Second, it only implements exclusive locking.
Locks can also be created without herd effect. A node is designated as the lock node. Each of the clients do the following:
Create an ephemeral or sequential node as a child node under the lock node.
Enumerate the children under the lock node.
If the created node is the lowest sequential among the children, the client has acquired the lock and exits
If there is a node preceding the created node, a watch is set on it
The process is repeated by enumerating the children under the lock node.
To release the lock, the node may merely be deleted.
This completes the locking primitive implemented by ZooKeeper.
We now look at some examples of primitives that are possible with ZooKeeper. These primitives exist only on the client side.
ConfigurationManagement - ZooKeeper can be used to implement dynamic configuration in a distributed application. This is one of the basic schemes where each configuration is stored in the form of ZNode. Processes wake up with the fullname of ZNode and set a watch on it. If the configuration is updated, the processes are notified and they apply the updates.
Rendezvous Node. Sometimes a configuration change is dependent others. For example, host and port may be known only afterwards. In this case clients can co-ordinate with a rendezvous node.
The node is filled in with details as and when they become available. The workers set a watch on this node before they begin their changes.
GroipMembership is another common co-ordination requirement. This primitive is implemented using ephemeral nodes. A node is designated to represent the group and is created at the start of the session. When a process member of the group starts, it creates an ephemeral child node under this group node. This child node keeps information for the process that creates it. If the process fails or exits, the node is automatically removed. Group membership can simply be enumerated by listing these child nodes.
Simple Locks: ZooKeeper can also be used to implement locks. Applications implement locks using lock files represented by a ZNode. To acquire a lock, the client tries to create the designated node with the ephemeral flag. If the create succeeds, the client holds the lock otherwise the client watches the node in case the leader dies. Whenever the znode is deleted, other clients may try to acquire the lock. There are two side-effects of this locking mechanism: First, there is a herd effect when all clients vie for a lock even though only one acquires it. Second, it only implements exclusive locking.
Locks can also be created without herd effect. A node is designated as the lock node. Each of the clients do the following:
Create an ephemeral or sequential node as a child node under the lock node.
Enumerate the children under the lock node.
If the created node is the lowest sequential among the children, the client has acquired the lock and exits
If there is a node preceding the created node, a watch is set on it
The process is repeated by enumerating the children under the lock node.
To release the lock, the node may merely be deleted.
This completes the locking primitive implemented by ZooKeeper.
No comments:
Post a Comment