Zookeeper Locks

Table of Contents

ZooKeeper distributed lock is based on Temporary Sequential Node. The basic features are consistent with persistent nodes. ZooKeeper automatically appends a monotonously increasing number suffix to its name as a new node name during the creation of the node.

To achieve a lock as a node on ZooKeeper.

When multiple clients acquire locks at the same time, several temporary sequential nodes are created sequentially. However, only the node with the first sequence number can acquire the locks successfully. Others monitor the changes of the previous node in order. When the listener releases the locks, the listener can acquire the locks immediately.

As shown above: two request want to acquire locks at the same time, so they all create a temporary node 1 and 2 under locks node, and the first one with the first ordinal number gets the lock successfully, while second one goes to awaiting state. When the lock of one node has released (the node is deleted), the second node becomes the node with the first ordinal number, so Second sequence gets the lock successfully.

Flow diagram

  1. API make AcquireLock and ReleaseLock calls towards LockService.
  2. LockService checks if Entity is already locked or not using ZooKeeper thread safe Lock API. If the entity is already locked by any other API thread (or call), then LockService will wait for configured amount of time. To avoid deadlock situation, synchronized block will be placed to take care of locking of multiple resource keys.
  3. Response (success / failure) will be given back from ZooKeeper Server to LockService.
  4. In case of either scenarios, the LockService can be configured to return appropriate data/responses.

How it works

  1. For the AcquireLock and ReleaseLock calls from the services will be handled by the common LockService module as the locking framework
  2. The Lock Service will be providing the overloaded methods of the ZooKeeper API as well as manage the persistent and ephemeral node creations.
  3. The in memory storage and connection configuration details referred by Lock Service need to be mentioned.
  4. Lock Service can manage:
    1. The node existence check(entity record already exists)
    2. If any children existence check and node creation deletion requests towards ZooKeeper server as part of AcquireLock and ReleaseLock process.
    3. Associates the Locking data details with the Znode (in this context, Znode represents in-memory storage of Locked Record) during the AcquireLock process.
    4. Provides the LockData details associated with Node
    5. Success/Error response.

TODO

  1. Using distributed lock mechanism with ZooKeeper in dependency injection: https://ahmadminoo.medium.com/using-distributed-lock-mechanism-with-zookeeper-in-dependency-injection-fa3a901cfb24
  2. Distributed Coordination With ZooKeeper Part 5: Building a Distributed Lock: https://nofluffjuststuff.com/blog/scott_leberknight/2013/07/distributed_coordination_with_zookeeper_part_5_building_a_distributed_lock
  3. Distributed Lock using Zookeeper: https://dzone.com/articles/distributed-lock-using
  4. Zookeeper Locks – Shared & Recoverable Shared Locks: https://data-flair.training/blogs/zookeeper-locks/

References

  1. https://www.linkedin.com/pulse/how-implement-zookeeper-locking-mechanism-minal-bagade/

Links to this note