Skip to content

Distributed Lock

A lock to protect a resource accessed by distributed machines

Approaches

Single lock service ❌

  • Single point of failure

Lock DB with async replication ❌

  • Eventual consistency leading to multiple clients with lock at the same time

Lock DB with sync replication ❌

  • Not fault tolerant
  • If leader needs to replicate to all followers, if 1 follower is down, can't proceed

Lock DB with Quorum Consensus using Fencing Token ❌

  • A little more fault tolerant but not linearizable (not in order)
  • Might update 1 replicate, and other replicate is down (need Two Phase Commit (2pc) to fix that)
  • Quorum Consensus helps with fault tolerance but is not linearizable
  • Quorum Consensus is not linearizable since
  • What if some client finds a max Fencing Token (from > n/2 replicas) and needs to update, but the client fails to update because it went down
    • Then another client can read from > n/2 outdated replicas

Lock DB with Distributed Consensus using Fencing Token ✅

  • Fault tolerant and linearizable
  • Distributed Consensus majority must accept (Two Phase Commit (2pc))
  • Example: RAFT
  • If leader fails, a up to date follower will be elected to leader (max Fencing Key)
  • Use this to guarantee who has the Lock with:
    • Fault Tolerance
    • Fencing Key used if somehow two clients have the Lock
      • two clients can get the Lock accidentally if a client has some process pause (ex: Garbage Collector) and hits TTL of Lock service and Lock is released
      • In this case the Fencing Key can be used to break the tie