分布式锁是一个复杂的挑战，因为你需要以原子方式确保在任何给定时间内只有一个参与者在修改某个有状态的资源。例如，假设你有一个数据库，它作为你的应用程序的中央事实来源。为了确保数据始终准确，你需要确保在你的应用服务器集群中，只有一个应用服务器在修改数据库中的某条特定记录。
AWS DynamoDB 分布式锁原理
-
主机 A 通过向锁表写入一个键为 "Moe" 的条目来获取锁，前提是锁表中尚不存在键为 "Moe" 的条目。主机 A 使用版本号（RVN）为 UUID1 获取了锁。
-
主机 B 尝试获取 "Moe" 的锁，并使用版本号（RVN）为 UUID2。
-
主机 B 首先通过 GetItem 调用检查是否已经存在一个锁。
-
在这种情况下，主机 B 发现主机 A 持有 "Moe" 的锁，其记录版本号（RVN）为 UUID1。由于主机 A 和主机 B 运行的是相同的应用程序，因此主机 B 期望，如果主机 A 想继续持有 "Moe" 的锁，它会在 10 秒内发送心跳并续约锁。主机 A 发送了一次心跳，并通过对键为 "Moe" 的锁进行条件更新，将锁的 RVN 更新为 UUID3。
-
主机 B 在第一次尝试获取锁后的 10 秒后，通过条件 UpdateItem 调用检查锁的 RVN 是否已更改，并使用 RVN 为 UUID4 进行检查。
-
主机 A 成功更新了锁。因此，主机 B 发现新的 RVN 等于 UUID3，并再等待了 10 秒。主机 A 在第一次心跳后崩溃，因此它没有将 RVN 从 UUID3 再次更改。当主机 B 第三次尝试获取 "Moe" 的锁时，它发现 RVN 仍然是 UUID3，与第二次尝试获取锁时检索到的 RVN 相同。
-
在这种情况下，由于主机 A 和主机 B 运行的是相同的应用程序，主机 B 期望，如果主机 A 健康并打算继续持有锁，它会发送心跳。因此，主机 B 认为 "Moe" 的锁已过期。主机 B 的条件更新成功获取了 "Moe" 的锁，应用程序得以继续运行！