etcd 分布式锁 和 数据库乐观锁

以下是 etcd 分布式锁 和 数据库乐观锁 的实现原理、适用场景及对比分析：

---

一、etcd 分布式锁

1. 实现原理

etcd 基于 Raft 一致性协议 提供强一致性，其分布式锁机制通常通过以下步骤实现：

1. 租约（Lease）创建：客户端创建一个带 TTL 的租约，确保锁自动释放。
2. 事务竞争锁：

• 使用事务（TXN）尝试在指定前缀（如 /locks/resource/）下创建唯一键。
• 若键不存在，则创建并绑定租约；否则监听前一个键的删除事件。

3. 锁续期：客户端定期刷新租约（KeepAlive），防止业务未完成时锁过期。

2. 代码示例（使用 etcd 客户端）

client, _ := clientv3.New(clientv3.Config{Endpoints: []string{"localhost:2379"}})
defer client.Close()

// 创建租约（TTL 为 10 秒）
lease := clientv3.NewLease(client)
leaseGrant, _ := lease.Grant(context.TODO(), 10)
leaseID := leaseGrant.ID

// 尝试获取锁（事务操作）
key := "/locks/resource"
txn := client.Txn(context.TODO())
txn.If(clientv3.Compare(clientv3.CreateRevision(key), "=", 0)).
    Then(clientv3.OpPut(key, "locked", clientv3.WithLease(leaseID))).
    Else(clientv3.OpGet(key))
txnResp, _ := txn.Commit()

if txnResp.Succeeded {
    // 获取锁成功，定期续约
    keepAlive, _ := lease.KeepAlive(context.TODO(), leaseID)
    defer lease.Revoke(context.TODO(), leaseID)
    // 执行业务逻辑...
} else {
    // 监听前一个锁的释放
    watcher := client.Watch(context.TODO(), key)
    for wresp := range watcher {
        for _, ev := range wresp.Events {
            if ev.Type == clientv3.EventTypeDelete {
                // 重新尝试获取锁
            }
        }
    }
}

3. 优点

• 强一致性：基于 Raft 协议，数据一致性强。
• 自动释放：租约机制防止死锁。
• 高可用：适合云原生环境（如 Kubernetes 服务发现）。

4. 缺点

• 性能中等：吞吐量低于 Redis，但高于 ZooKeeper。
• 复杂度高：需处理租约续期、事务冲突等逻辑。

5. 适用场景

• Kubernetes 生态：如服务协调、配置同步。
• 强一致性要求：分布式选主、集群管理。

---

二、数据库乐观锁

1. 实现原理

乐观锁假设并发冲突概率低，通过 版本号（Version） 或 条件更新（CAS） 实现：

1. 读取数据：获取当前版本号（如 version=1）。
2. 更新数据：提交更新时检查版本号是否未变，若变化则重试或放弃。

2. 代码示例（MySQL）

-- 1. 查询当前版本
SELECT version FROM products WHERE id = 1;

-- 2. 更新时校验版本
UPDATE products SET stock = stock - 1, version = version + 1 
WHERE id = 1 AND version = 1;  -- 假设查询时 version=1

-- 检查 affected rows，若为 0 则重试或报错

3. 优点

• 无额外依赖：仅需数据库支持。
• 简单轻量：适合简单业务场景。

4. 缺点

• 高并发性能差：冲突时需频繁重试，增加数据库压力。
• 无自动回滚：需业务层处理重试逻辑。

5. 适用场景

• 低并发操作：如后台管理系统、配置更新。
• 短事务：可快速完成，减少冲突概率。

---

三、方案对比

维度	etcd 分布式锁	数据库乐观锁
一致性	强一致性（CP 系统）	最终一致性（依赖数据库事务）
性能	中（1k~5k QPS）	低（高并发下重试开销大）
复杂度	高（需处理租约、事务）	低（仅版本号校验）
适用场景	分布式协调、强一致性锁	简单并发控制、无中间件依赖的场景

---

四、选型建议

1. 选择 etcd 分布式锁：

• 需要强一致性且已使用 etcd（如 Kubernetes 环境）。
• 复杂协调场景（如分布式任务调度、选主）。

2. 选择数据库乐观锁：

• 简单业务逻辑，无需引入分布式中间件。
• 低并发场景，冲突概率低。

3. 组合使用：

• 核心业务用 etcd 锁保证一致性。
• 非核心业务用乐观锁减少复杂度。

---

五、避坑指南

1. etcd 锁注意事项

• 租约管理：确保及时续期，避免业务未完成锁已释放。
• 连接超时：处理网络分区时的客户端重连逻辑。

2. 乐观锁注意事项

• 重试策略：设置最大重试次数，避免无限循环。
• 版本号更新：确保每次更新都递增版本号。

3. 通用建议

• 监控锁竞争：通过 Prometheus 监控 etcd 锁等待时间或数据库更新冲突率。
• 压力测试：在高并发下验证锁机制的性能和稳定性。

---

六、总结

• etcd 锁：适合云原生强一致场景，需容忍一定复杂度。
• 乐观锁：轻量级解决方案，适合简单低并发需求。
• 综合选型：根据业务规模、一致性要求和团队技术栈选择最适方案。