1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

-- KEYS[1]: 锁名称
-- ARGV[1]: 过期时间
-- ARGV[2]: 线程唯一标识

-- 第一步：判断锁是否存在
if (redis.call('exists', KEYS[1]) == 0) then
    -- 锁不存在，创建 Hash，设置 Field(线程ID) 和 Value(计数1)，并设置过期时间
    redis.call('hset', KEYS[1], ARGV[2], 1);
    redis.call('pexpire', KEYS[1], ARGV[1]);
    return nil;
end;

-- 第二步：锁存在，判断是否是当前线程持有
if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then
    -- 是自己持有的，重入次数 +1，并刷新过期时间
    redis.call('hincrby', KEYS[1], ARGV[2], 1);
    redis.call('pexpire', KEYS[1], ARGV[1]);
    return nil;
end;

-- 第三步：锁存在，但被别人持有，返回剩余过期时间
return redis.call('pttl', KEYS[1]);

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// ============ Redis分布式锁（单节点实现） ============
// 获取锁（原子操作）
SET resource_name my_random_value NX PX 30000  // NX: 不存在才设置，PX: 过期时间30秒

// 释放锁（Lua脚本保证原子性）
if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
else
    return 0
end

// ============ ZooKeeper分布式锁（临时顺序节点） ============
// 1. 创建临时顺序节点
String lockPath = zk.create("/locks/lock-", data, 
    ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);

// 2. 获取所有子节点
List<String> children = zk.getChildren("/locks", false);
Collections.sort(children);

// 3. 判断是否是最小节点
int index = children.indexOf(lockPath.substring(lockPath.lastIndexOf('/') + 1));
if (index == 0) {
    // 获得锁
} else {
    // 监听前一个节点
    String prevPath = "/locks/" + children.get(index - 1);
    zk.exists(prevPath, true);  // 注册Watcher
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

/**
 * 优缺点对比表
 */
// ============ Redis分布式锁 ============
// 优点：
// - 性能极高（基于内存，QPS可达10万+）
// - 实现简单，API友好
// - 支持自动过期，避免死锁
// - Redlock算法可提供更高可靠性

// 缺点：
// - 主从异步复制可能导致锁丢失（主宕机，从未同步）
// - 需自行处理锁续期（Watchdog机制）
// - 非公平锁，可能产生饥饿
// - 依赖时钟同步假设

// Redis锁丢失场景演示
// 1. 客户端A在主节点获取锁
// 2. 主节点宕机，锁数据未同步到从节点
// 3. 从节点升级为主节点
// 4. 客户端B也能获取同一把锁 → 锁失效！

// ============ ZooKeeper分布式锁 ============
// 优点：
// - 强一致性（ZAB协议保证）
// - 临时节点自动清理，无需设置过期时间
// - 天然公平锁（按节点序号顺序）
// - Watch机制避免惊群效应
// - 客户端断开连接自动释放锁

// 缺点：
// - 性能较低（磁盘写操作，QPS约几千）
// - 部署维护复杂（需要独立集群）
// - 可能存在"羊群效应"（需优化为监听前一个节点）
// - 会话超时时间难权衡

// ZooKeeper锁改进实现（避免惊群）
public class ZooKeeperLock {
    private String currentPath;
    private String prevPath;
    
    public void lock() throws Exception {
        currentPath = zk.create("/locks/lock-", null, 
            ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);
        
        List<String> children = zk.getChildren("/locks", false);
        Collections.sort(children);
        
        if (currentPath.equals("/locks/" + children.get(0))) {
            return;  // 获得锁
        }
        
        // 只监听前一个节点，而非所有节点
        int i = Collections.binarySearch(children, 
            currentPath.substring(currentPath.lastIndexOf('/') + 1));
        prevPath = "/locks/" + children.get(i - 1);
        zk.exists(prevPath, true);  // 注册Watcher
        
        synchronized (this) {
            wait();  // 等待前一个节点释放
        }
    }
}

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

// ============ Redlock算法（Redis官方推荐） ============
public class Redlock {
    private static final int N = 5;  // 5个独立Redis节点
    private List<RedisClient> clients;
    
    public boolean tryLock(String key, String value, int ttl) {
        int successCount = 0;
        long start = System.currentTimeMillis();
        
        // 1. 向所有节点尝试获取锁
        for (RedisClient client : clients) {
            if (client.setnxex(key, value, ttl)) {
                successCount++;
            }
        }
        
        // 2. 检查是否超过半数且耗时小于TTL
        long cost = System.currentTimeMillis() - start;
        if (successCount >= N/2 + 1 && cost < ttl) {
            return true;  // 获得锁
        }
        
        // 3. 失败则释放所有节点锁
        for (RedisClient client : clients) {
            client.del(key);
        }
        return false;
    }
}

// ============ Curator（ZooKeeper客户端封装） ============
public class CuratorLockDemo {
    private CuratorFramework client;
    private InterProcessLock lock;
    
    public void init() {
        client = CuratorFrameworkFactory.newClient(
            "zk1:2181,zk2:2181,zk3:2181",
            new ExponentialBackoffRetry(1000, 3));
        client.start();
        
        // 创建可重入分布式锁
        lock = new InterProcessMutex(client, "/locks/my_lock");
    }
    
    public void doWithLock() {
        try {
            if (lock.acquire(10, TimeUnit.SECONDS)) {
                try {
                    // 业务逻辑
                } finally {
                    lock.release();
                }
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106

/**
 * Redis vs ZooKeeper 分布式锁完整指南
 */
public class DistributedLockGuide {
    
    /**
     * 1. 详细对比表
     */
    public class ComparisonTable {
        // 维度            Redis锁                        ZooKeeper锁
        // 一致性          最终一致性                     强一致性（ZAB）
        // 性能           极高（10万+ QPS）               中等（几千 QPS）
        // 可靠性          主从切换可能丢锁                无丢锁风险
        // 公平性          非公平锁                       公平锁（节点顺序）
        // 自动释放        过期时间                        临时节点自动删除
        // 阻塞机制        自旋重试                         Watch通知
        // 实现复杂度      简单                            复杂
        // 部署成本       轻量级                          独立集群
        // 高级特性        Redlock                        可重入锁、读写锁
    }
    
    /**
     * 2. 选型决策树
     */
    public class DecisionTree {
        // 1. 对性能要求是否极高（>1万 QPS）？
        //    ├─ 是 → Redis（单节点或Redlock）
        //    └─ 否 → 转到2
        
        // 2. 是否要求绝对可靠（金融交易）？
        //    ├─ 是 → ZooKeeper（强一致性）
        //    └─ 否 → 转到3
        
        // 3. 是否需要公平锁？
        //    ├─ 是 → ZooKeeper
        //    └─ 否 → Redis
        
        // 4. 现有基础设施？
        //    ├─ 已有Redis集群 → Redis
        //    └─ 已有ZooKeeper → ZooKeeper
    }
    
    /**
     * 3. 适用场景示例
     */
    public class RealScenarios {
        
        // 场景1：秒杀库存扣减（选Redis）
        // 原因：10万QPS，允许极小概率的锁失效
        
        // 场景2：分布式定时任务调度（选ZooKeeper）
        // 原因：需要严格保证只有一个节点执行
        
        // 场景3：配置中心主节点选举（选ZooKeeper）
        // 原因：强一致性保证，避免脑裂
        
        // 场景4：分布式限流计数器（选Redis）
        // 原因：高性能，Lua脚本原子操作
        
        // 场景5：跨行转账防重（选ZooKeeper）
        // 原因：资金操作必须绝对可靠
    }
    
    /**
     * 4. 面试必备
     */
    public class InterviewQA {
        
        // Q: Redis锁如何避免锁被其他客户端释放？
        // A: 使用随机value+Lua脚本，只删除自己设置的锁
        
        // Q: ZooKeeper锁的"惊群效应"如何解决？
        // A: 每个节点只监听前一个节点，而非所有节点
        
        // Q: Redlock算法靠谱吗？
        // A: 学术界有争议，但工业界广泛应用
        
        // Q: 锁超时时间设置多少合适？
        // A: 略大于最大业务执行时间 + 缓冲
    }
}

/**
 * 总结表
 * 
 * 方案          性能       可靠性      公平性      适用场景
 * Redis单节点    极高       中          低         缓存、计数器、非核心
 * Redis Redlock 高        较高         低         跨机房、高可用要求
 * ZooKeeper     中        极高         高         交易、选举、核心业务
 * 
 * 最佳实践：
 * 1. 业务核心选ZK，性能核心选Redis
 * 2. Redis锁一定要用Lua脚本释放
 * 3. ZooKeeper锁要用Curator框架
 * 4. 始终设置合理的超时时间
 */

// 面试金句
// "Redis和ZooKeeper分布式锁就像'赛车'和'装甲车'：
//  Redis是'赛车'——速度极快（性能），
//  但发生事故时可能翻车（主从切换丢锁）；
//  ZooKeeper是'装甲车'——稳重可靠（强一致），
//  但开不快（性能较低），油耗也高（部署复杂）。
//  在秒杀系统中我开'赛车'，因为要的就是快；
//  在资金结算中我开'装甲车'，因为绝对安全比速度更重要。
//  理解这个区别，才能在业务和技术之间做出正确权衡。"