3. DynamoDB 锁表设计：表结构、主键设计、TTL 与租约、锁冲突处理

Terraform 使用 DynamoDB 作为分布式锁的后端存储，其核心是一个精心设计的锁表。理解这张表的结构、主键策略、租约机制以及冲突处理方式，是排查 SLI 相关锁问题的基础。本章将深入剖析 DynamoDB 锁表的每一个设计细节。

3.1 锁表结构概览

一个标准的 Terraform 状态锁表通常包含以下字段。该表结构由 Terraform 后端配置自动创建，或由运维人员通过 Terraform 脚本预置。

3.2 主键设计与锁冲突

DynamoDB 锁表使用 单一分区键（Partition Key），即 LockID。这种设计直接决定了锁的粒度与冲突检测方式。

• 锁粒度： 每个 LockID 对应一个独立的状态文件。这意味着对 terraform.tfstate 的锁定不会影响 networking/terraform.tfstate 的锁定。
• 冲突检测： 当两个 Terraform 进程尝试对同一个 LockID 执行 PutItem 时，DynamoDB 的 条件写入（Conditional Write） 机制会拒绝第二个写入请求，并返回 ConditionalCheckFailedException。Terraform 客户端捕获此异常，判定锁冲突。

3.3 TTL 与租约机制

锁不能永久持有。Terraform 通过 TTL（Time To Live） 和 租约（Lease） 机制确保锁的自动释放，防止死锁。

租约机制的工作流程如下：

1. 获取锁： Terraform 进程在 PutItem 时，会计算一个未来的时间戳（例如当前时间 + 30 秒），写入 TTL 字段。
2. 持有锁： 在锁有效期内，Terraform 进程定期（例如每 10 秒）执行 UpdateItem 操作，刷新 TTL 字段，延长租约。
3. 释放锁： 操作完成后，Terraform 进程主动执行 DeleteItem 删除锁记录。
4. 自动过期： 如果进程崩溃或网络中断，DynamoDB 的 TTL 功能会在 TTL 时间戳到达后，自动删除该记录。其他进程即可获取锁。

# 获取锁时的 PutItem 请求示例（伪代码）
{
  "TableName": "terraform-locks",
  "Item": {
    "LockID": {"S": "myproject/terraform.tfstate"},
    "Info": {"S": "{\"ID\":\"abc123\",\"Operation\":\"apply\",\"Who\":\"user@host\"}"},
    "TTL": {"N": "1742558430"}  # 当前时间 + 30 秒
  },
  "ConditionExpression": "attribute_not_exists(LockID)"  # 关键：仅当锁不存在时写入
}

3.4 锁冲突处理策略

当锁冲突发生时，Terraform 客户端不会立即失败，而是采用 指数退避（Exponential Backoff） 策略进行重试。这是保障系统稳定性的关键设计。

冲突处理流程如下：

1. 检测冲突： Terraform 收到 ConditionalCheckFailedException。
2. 读取锁信息： 通过 GetItem 读取 Info 字段，获取当前锁持有者的身份和操作。
3. 等待并重试： 等待一个随机时间（初始约 1 秒），然后重试 PutItem。每次重试的等待时间指数增长（例如 1s, 2s, 4s, 8s...），直到达到最大重试次数或超时。
4. 最终失败： 如果重试耗尽，Terraform 返回错误，提示用户锁无法获取。

3.5 锁表设计总结

下表总结了 DynamoDB 锁表各设计要素与 SLI 排查的对应关系：