在分布式系统中，锁是控制资源访问的重要机制。Redis和ZooKeeper作为两种主流的分布式锁实现方案，各有优劣。本文将从原理、性能、代码实现三个维度进行硬核对比，助你做出最佳技术选型。

一、原理对比：设计哲学的根本差异

Redis分布式锁核心机制

# 基于SETNX的加锁逻辑
def acquire_lock(conn, lockname, acquire_timeout=10):
    identifier = str(uuid.uuid4())
    lock_key = f"lock:{lockname}"
    
    end = time.time() + acquire_timeout
    while time.time() < end:
        if conn.setnx(lock_key, identifier):
            conn.expire(lock_key, lock_timeout)
            return identifier
        elif not conn.ttl(lock_key):
            conn.expire(lock_key, lock_timeout)
        
        time.sleep(0.001)
    
    return False

核心特点：

• 基于内存操作，响应快
• SETNX保证原子性
• 需要额外处理过期时间
• 无等待队列，依赖重试机制

ZooKeeper分布式锁实现原理

// 基于临时顺序节点的加锁逻辑
public void lock() {
    path = zk.create(
        "/locks/resource-", 
        new byte[0],
        ZooDefs.Ids.OPEN_ACL_UNSAFE,
        CreateMode.EPHEMERAL_SEQUENTIAL
    );
    
    while(true) {
        List<String> nodes = zk.getChildren("/locks", false);
        Collections.sort(nodes);
        
        if (path.endsWith(nodes.get(0))) {
            return; // 获得锁
        } else {
            // 监听前一个节点
            String prevNode = "/locks/" + nodes.get(
                Collections.binarySearch(nodes, path)-1);
            CountDownLatch latch = new CountDownLatch(1);
            zk.exists(prevNode, event -> latch.countDown());
            latch.await();
        }
    }
}

核心特点：

• 基于ZooKeeper的临时顺序节点
• 天然具备等待队列
• 会话断开自动释放锁
• Watch机制实现阻塞等待

二、性能对决：TPS与延迟的硬指标

基准测试数据对比（单节点）

关键结论：

• Redis在低延迟、高吞吐场景完胜
• ZooKeeper在强一致性需求场景更可靠

三、代码实战：两种锁的Spring Boot集成

Redis锁集成（Spring Data Redis）

@Configuration
public class RedisLockConfig {
    
    @Bean
    public RedisTemplate<String, String> redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate<String, String> template = new RedisTemplate<>();
        template.setConnectionFactory(factory);
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new StringRedisSerializer());
        return template;
    }
    
    @Bean
    public RedisLockRegistry redisLockRegistry(RedisTemplate<String, String> redisTemplate) {
        return new RedisLockRegistry(redisTemplate, "lock:", 30_000);
    }
}

// 使用示例
@Service
public class PaymentService {
    
    @Autowired 
    private RedisLockRegistry lockRegistry;
    
    public void processPayment(String orderId) {
        Lock lock = lockRegistry.obtain(orderId);
        try {
            if (lock.tryLock(3, TimeUnit.SECONDS)) {
                // 业务逻辑
            }
        } finally {
            lock.unlock();
        }
    }
}

ZooKeeper锁集成（Curator框架）

@Configuration
public class ZkLockConfig {
    
    @Bean
    public CuratorFramework curatorFramework() {
        RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3);
        CuratorFramework client = CuratorFrameworkFactory
            .newClient("zk-host:2181", retryPolicy);
        client.start();
        return client;
    }
    
    @Bean
    public InterProcessMutex interProcessMutex(CuratorFramework client) {
        return new InterProcessMutex(client, "/locks");
    }
}

// 使用示例
@Service
public class InventoryService {
    
    @Autowired
    private InterProcessMutex lock;
    
    public void deductStock(String productId) {
        try {
            if (lock.acquire(3, TimeUnit.SECONDS)) {
                // 业务逻辑
            }
        } finally {
            lock.release();
        }
    }
}

四、生死抉择：六大场景选型指南

1. 秒杀系统 → Redis锁

• 需要极高TPS
• 允许极少数超时问题

1. 资金交易 → ZooKeeper锁

• 强一致性要求
• 不允许脏数据

1. 配置中心 → ZooKeeper锁

• 天然协调服务
• 需要Watcher机制

1. 缓存预热 → Redis锁

• 同一服务内协调
• 短期锁需求

1. 分布式任务调度 → ZooKeeper锁

• 长事务处理
• 需要故障转移

1. 实时排行榜 → Redis锁

• 高频更新
• 允许最终一致

五、高级技巧：生产环境避坑指南

Redis锁优化方案

-- 原子化解锁脚本
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

关键改进点：

• 使用Lua脚本保证原子性
• 红锁(Redlock)应对单点故障
• 锁续约机制防止处理超时

ZooKeeper锁优化方向

// 锁重试策略优化
RetryPolicy retryPolicy = new RetryNTimes(
    3, 
    ThreadLocalRandom.current().nextInt(100, 500)
);

关键改进点：

• 合理设置会话超时
• 优化重试策略
• 避免羊群效应（使用有序节点）

终极对决结果

选择Redis锁当：

• 你的系统需要 >5,000 TPS
• 允许极小概率的锁失效
• 已经部署Redis基础设施

选择ZooKeeper锁当：

• 业务需要100%可靠的锁
• 可以接受 <3,000 TPS
• 需要天然等待队列机制

技术选型没有银弹，只有最适合。理解两者的本质差异，根据你的业务场景做出理性选择，才是架构师的真正智慧。