Distributed Locks with the DynamoDB Lock Client

  1. Distributed Locks with the DynamoDB Lock Client
  2. 1. Overview
  3. 2. Practical Example
    1. 2.1 Locking Protocol
  4. Reference

Distributed Locks with the DynamoDB Lock Client

1. Overview

  • DynamoDB Lock Client

    • enable you to solve distributed computing problems like leader election and distributed locking with client only code and a DDB table
  • Why we need it

    • Distributed Locking is complicated
      • you need to atomically ensure only one actor is modifying a stateful resource at any given time

2. Practical Example

  • Background
    • A retail bank that want to ensure at most one customer service representative change customer details at a time
    • solution
      • temporarily lock customer records during an update
      • suppose there are bunch different tables to contain all customer information, as the tables are independent, so we cannot just wrap the changes we need in a relational transaction
      • we need to lock customer id at a high level
      • You’d do so with a locking API action for a certain duration in your application before making any changes.

2.1 Locking Protocol

  • For a new lock, the lock clients store a lock item in the lock table
    • it stores
      • the host name of the owner
      • the lease duration in milliseconds
      • a UUID unique to the host
      • the host system clock time when the lock was initially created

Whole Workflow

  1. Host A acquires a lock on Moe by writing an item to the lock table on the condition that no item keyed at “Moe” exists yet. Host A
    acquires the lock with a revision version number (RVN) of UUID.
  2. Host B tries to get a lock on Moe with a RVN UUID.
  3. Host B checks to see if a lock already exists with a GetItem call.
  4. In this case, host B finds that host A holds a lock on Moe with a record version number (RVN) of UUID. The same application runs on hosts A and B. That being so, host B
    expects host A to heartbeat and renew the lock on Moe in less than 10 seconds, if host A intends to keep the lock on Moe. Host A heartbeats once, and uses a conditional update on the lock keyed at Moe to update the RVN of the lock to UUID.
  5. Host B checks 10 seconds after the first AcquireLock call to see if the RVN in A’s lock on Moe changed with a conditional UpdateItem call and a RVN of UUID.
  6. Host A successfully updates the lock. Thus, host B finds the new RVN equal to UUID and waited 10 more seconds. Host A died after the first heartbeat, so it never changes the RVN past UUID. When host B calls tries to acquire a lock on Moe for the third time, it finds that the RVN was still UUID, the same RVN retrieved on the second lock attempt.
  7. In this case, hosts A and B run the same application. Because host B expects host A to heartbeat if host A is healthy and intends to keep the lock, host B considers the lock on Moe expired. Host B’s conditional update to acquire the lock on Moe succeeds, and your application makes progress!


  1. https://aws.amazon.com/blogs/database/building-distributed-locks-with-the-dynamodb-lock-client/

转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 stone2paul@gmail.com

文章标题:Distributed Locks with the DynamoDB Lock Client


本文作者:Leilei Chen

发布时间:2021-01-15, 11:51:14

最后更新:2021-01-15, 11:53:09


版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。