分布式锁Redlock算法与高并发场景实战深度解析

五、ZooKeeper分布式锁实现

5.1 ZooKeeper顺序节点方案

ZooKeeper利用其顺序临时节点（Ephemeral Sequential）特性实现分布式锁，天生解决了锁的自动释放问题：

type ZKLock struct {
    zkConn      *zk.Conn
    lockPath    string
    seqNode     string  // 当前客户端创建的节点路径
}

func (l *ZKLock) Lock() error {
    // 1. 在锁目录下创建顺序临时节点
    path, err := l.zkConn.Create(l.lockPath+"/request-", nil,
        zk.FlagEphemeral|zk.FlagSequence, zk.WorldACL(zk.PermAll))
    if err != nil {
        return err
    }
    l.seqNode = path

    for {
        // 2. 获取锁目录下所有子节点并排序
        children, _, err := l.zkConn.Children(l.lockPath)
        if err != nil {
            return err
        }
        sort.Strings(children)

        // 3. 判断当前节点是否是序号最小的
        mySeq := filepath.Base(l.seqNode)
        if mySeq == children[0] {
            return nil // 获得锁
        }

        // 4. 找到前一个节点，设置监听
        prevNode := findPrevNode(children, mySeq)
        exists, _, events, err := l.zkConn.ExistsW(l.lockPath + "/" + prevNode)

        if !exists {
            continue // 前一个节点已消失，重新检查
        }

        // 5. 等待前一个节点事件触发后重新抢锁
        <-events
    }
}

func (l *ZKLock) Unlock() error {
    return l.zkConn.Delete(l.seqNode, -1)
}

5.2 ZK vs Redis对比

六、etcd分布式锁与选主实现

6.1 etcd租约（Lease）机制

etcd基于Raft共识算法，提供强一致性的分布式协调服务。其Lease机制非常适合实现分布式锁：

import clientv3 "go.etcd.io/etcd/client/v3"

func (s *EtcdLock) Acquire(resource string, ttl int) (*EtcdLock, error) {
    ctx := context.Background()

    // 1. 创建租约（自动过期时间）
    leaseResp, err := s.client.Grant(ctx, int64(ttl))
    if err != nil {
        return nil, err
    }

    // 2. 使用事务（Tx）实现原子性比较-and-设定
    // 如果resource的revision为0（不存在），则写入
    key := fmt.Sprintf("/locks/%s", resource)
    txn := s.client.Txn(ctx).
        If(clientv3.Compare(clientv3.Revision(key), "=", 0)).
        Then(clientv3.OpPut(key, s.myID, clientv3.WithLease(leaseResp.ID))).
        Else(clientv3.OpGet(key))

    txnResp, err := txn.Commit()
    if err != nil {
        return nil, err
    }

    if !txnResp.Succeeded {
        return nil, ErrLockAlreadyHeld
    }

    // 3. 定时续约
    keepAliveChan, _ := s.client.KeepAlive(ctx, leaseResp.ID)

    return &EtcdLock{
        client:      s.client,
        leaseID:     leaseResp.ID,
        key:         key,
        keepAlive:   keepAliveChan,
    }, nil
}

func (s *EtcdLock) Release() error {
    _, err := s.client.Delete(context.Background(), s.key)
    s.client.Revoke(context.Background(), s.leaseID)
    return err
}

6.2 etcd选主（Leader Election）

etcd的ElectionAPI封装了完整的选主逻辑，适用于主从架构的服务选主：

import "go.etcd.io/etcd/client/v3/concurrency"

func Campaign(nodeID string) {
    sess, _ := concurrency.NewSession(client, concurrency.WithTTL(10))
    elect := concurrency.NewElection(sess, "/leader-election/app-cluster")

    // 尝试竞选Leader（阻塞直到竞选成功）
    if err := elect.Campaign(context.Background(), nodeID); err != nil {
        log.Fatal("竞选失败:", err)
    }

    log.Printf(" 当前节点成为Leader: %s", nodeID)

    // 执行Leader职责...

    // 退位时主动释放
    elect.Resign(context.Background())
}

七、生产环境实战：电商库存扣减

7.1 业务场景分析

电商秒杀场景中，库存扣减需要满足：

• 超卖防护：并发请求不能导致库存为负
• 幂等性：同一用户重复请求只扣减一次
• 高吞吐：支撑10W+QPS的峰值流量
• 公平性：先到先得，避免插队

7.2 多层防护架构实现

type SeckillService struct {
    redis  *redis.Client
    etcd   *clientv3.Client
    db     *sql.DB
}

// 库存扣减的多层防护
func (s *SeckillService) DeductStock(ctx context.Context, skuID string, userID string) (*Result, error) {
    // === Level 1: 用户维度风控（前置拦截）===
    if s.isBlacklisted(userID) {
        return nil, ErrRiskControl
    }

    // === Level 2: Redis 库存预扣（过滤99%的请求）===
    // 使用 DECR 原子递减，判断返回值
    remain, err := s.redis.Decr(ctx, fmt.Sprintf("stock:%s", skuID)).Result()
    if err != nil || remain < 0 xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed xss=removed> 0 AND version = ?",
        skuID, expectedVersion,
    )

    affected, _ := result.RowsAffected()
    if affected == 0 {
        err = ErrConcurrentConflict
        return nil, err
    }

    // 写入审计日志
    tx.Exec("INSERT INTO stock_audit_log (sku_id, user_id, action, time) VALUES (?, ?, 'deduct', NOW())",
        skuID, userID)

    return &Result{Success: true, OrderNo: generateOrderNo()}, nil
}

7.3 压测指标

该方案在实际环境中的生产压测数据：

• 单节点etcd支撑锁QPS：5000+
• Redis预扣层QPS：10W+
• 端到端P99延迟：28ms
• 零超卖事件（生产环境运行6个月）
• Redis层拦截率：99.3%（仅0.7%请求进入核心锁逻辑）

八、分布式锁的八条核心原则

综合Redlock、ZK、etcd三种方案的实践经验，总结如下核心原则：

1. 互斥优先：同一时刻仅允许一个持有者，这是锁的最低保证
2. 防死锁设计：必须设置TTL，避免崩溃导致的永久死锁
3. 原子性保证：加锁、解锁、检查必须是原子操作（Lua脚本或事务）
4. 唯一标识：锁的值必须全局唯一，防止误释放他人锁
5. 多数派确认：使用Redlock等多实例方案时，必须获得多数派确认
6. 故障容错：允许不超过半数的实例故障仍能提供服务
7. Fencing Token：对强一致场景，配合存储层的fencing token防御GC停顿
8. 优雅降级：锁服务不可用时，业务应有降级策略（熔断、限流、队列）

九、常见误区与避坑指南

十、总结与选型建议

方案选型矩阵：

• 电商秒杀/缓存更新 → Redis SET NX EX + Watchdog（性能优先，容忍极小概率冲突）
• 强一致配置/服务注册 → ZooKeeper顺序临时节点（ZK原生Watcher，实现最优雅）
• 容器编排/微服务协调 → etcd Lease + Txn（与Kubernetes生态天然集成）
• 金融交易/账务处理 → Redlock + Fencing Token + DB乐观锁（多层防护，零容忍不一致）
• 轻量级任务调度 → 数据库乐观锁/version字段（最简单，无额外依赖）

分布式锁不是银弹，也没有万能方案。理解每种方案的一致性边界、失效场景和性能特征，根据业务的实际需求（一致性要求、性能要求、复杂度容忍度）做出合适的选择，才是分布式系统设计的核心能力。