4. 乐观并发控制：resourceVersion 机制、冲突检测、重试策略

在分布式系统中，多个客户端可能同时尝试修改同一个资源对象。Kubernetes 采用乐观并发控制（Optimistic Concurrency Control, OCC）策略，而非悲观锁。其核心思想是：允许并发操作提交，但在写入存储（etcd）时通过版本号检测冲突，若发现数据已被其他客户端修改，则拒绝当前写入并返回冲突错误。

4.1 resourceVersion：乐观锁的基石

每个 Kubernetes 资源对象在创建时都会被分配一个全局递增的版本号，存储在 metadata.resourceVersion 字段中。该字段是 etcd 中 mod_revision 的映射，用于标识对象在存储中的修改顺序。

4.2 冲突检测机制：CAS 操作

Kubernetes API Server 在处理更新请求时，执行比较并交换（Compare-And-Swap, CAS）操作。客户端在提交更新时，必须携带从 GET 响应中获取的 resourceVersion。API Server 将该值与 etcd 中当前存储的版本号进行比较：

• 版本匹配（乐观情况）：允许写入，更新对象并递增版本号。
• 版本不匹配（冲突情况）：拒绝写入，返回 HTTP 409 Conflict 状态码。

4.3 重试策略：从冲突中恢复

当客户端收到 409 Conflict 响应时，不能简单重试原请求，因为携带的 resourceVersion 已经过期。正确的重试策略包含以下步骤：

1. 重新获取最新对象：发起 GET 请求，获取当前最新版本的对象及其 resourceVersion。
2. 重新应用变更：基于新获取的对象状态，重新计算期望的修改内容。
3. 提交更新：使用新的 resourceVersion 发起 PUT 或 PATCH 请求。
4. 循环检测：若再次冲突，重复上述步骤，直到成功或达到最大重试次数。

4.4 重试策略对比与最佳实践

func UpdateResource(client *Client, name string, mutate func(*Resource)) error {
    maxRetries := 5
    for i := 0; i < maxRetries; i++ {
        // 1. 获取最新对象
        obj, err := client.Get(name)
        if err != nil {
            return err
        }
        // 2. 应用变更
        mutate(obj)
        // 3. 提交更新（携带最新 resourceVersion）
        _, err = client.Update(obj)
        if err == nil {
            return nil // 成功
        }
        if !IsConflictError(err) {
            return err // 非冲突错误，直接返回
        }
        // 4. 冲突，等待后重试
        time.Sleep(backoff(i)) // 指数退避
    }
    return fmt.Errorf("max retries exceeded")
}

4.5 特殊场景：LIST 与 WATCH 中的 resourceVersion

resourceVersion 不仅用于写入冲突检测，还在读取操作中发挥重要作用：

• LIST 操作：可通过 resourceVersion=0 或 resourceVersion="" 获取最新数据；通过指定具体版本号实现一致性读取。
• WATCH 操作：客户端从 LIST 响应中获取 resourceVersion，然后基于该版本号建立 WATCH 连接，确保不会遗漏事件。
• Bookmark 机制：WATCH 连接中，API Server 定期发送 BOOKMARK 事件，携带当前 resourceVersion，帮助客户端在断连后快速恢复。

4.6 常见陷阱与避坑指南

• 忽略 resourceVersion：在更新请求中不携带 resourceVersion，API Server 会拒绝请求（返回 400 Bad Request）。
• 使用过期版本：重试时直接使用旧版本号 +1，而不是重新 GET，导致冲突检测失效。
• 无限重试：未设置最大重试次数，在持续冲突场景下导致客户端资源耗尽。
• 忽略非冲突错误：将 409 与其他错误（如 403 Forbidden）混淆，导致重试逻辑异常。
• PATCH 操作中的版本问题：Strategic Merge Patch 和 JSON Patch 同样需要携带 resourceVersion，否则可能覆盖其他并发修改。