深入解析分布式锁：Redis与ZooKeeper实现对比-CSDN博客

本文链接：https://blog.csdn.net/gitblog_00754/article/details/148323523

深入解析分布式锁：Redis与ZooKeeper实现对比

advanced-java 😮 Core Interview Questions & Answers For Experienced Java(Backend) Developers | 互联网 Java 工程师进阶知识完全扫盲：涵盖高并发、分布式、高可用、微服务、海量数据处理等领域知识项目地址: https://gitcode.com/gh_mirrors/ad/advanced-java

分布式锁概述

在分布式系统中，当多个进程或线程需要访问共享资源时，分布式锁是一种常用的协调机制。它能够保证在同一时间只有一个客户端可以访问特定资源，从而避免数据不一致的问题。

Redis实现分布式锁

基础实现方式

Redis实现分布式锁最基础的方式是使用SET命令配合NX和EX/PX参数：

SET resource_name my_random_value PX 30000 NX

这个命令包含几个关键参数：

NX：仅当key不存在时才设置成功
PX 30000：设置30秒的过期时间（毫秒级）
my_random_value：随机值，用于安全释放锁

释放锁时需要配合Lua脚本确保原子性操作：

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

RedLock算法

针对单点故障问题，Redis官方提出了RedLock算法，其核心思想是：

获取当前时间戳
依次向多个Redis实例尝试获取锁
计算获取锁花费的总时间
检查是否在大多数节点上成功获取锁
如果获取失败，则释放所有已获得的锁

Redis分布式锁的优缺点

优点：

性能高，响应快
实现相对简单
支持设置自动过期时间

缺点：

单实例存在单点故障风险
主从架构下可能出现锁丢失
需要客户端不断重试获取锁
锁超时时间设置需要谨慎

ZooKeeper实现分布式锁

基础实现方式

ZooKeeper通过临时节点实现分布式锁的基本原理：

客户端尝试创建临时节点
创建成功则获取锁
其他客户端注册监听器
锁释放时通知等待的客户端

顺序临时节点实现

更高级的实现方式是使用临时顺序节点：

每个客户端创建一个带顺序号的临时节点
判断自己是否是最小序号的节点
如果不是，则监听前一个节点
当前一个节点释放时获得通知

ZooKeeper分布式锁的优缺点

优点：

可靠性高，基于ZooKeeper的强一致性
无需设置超时时间，客户端断开连接自动释放
实现模型清晰简单
支持公平锁实现

缺点：

性能相比Redis较低
需要处理会话超时问题
长时间GC可能导致锁意外释放

Redis与ZooKeeper对比

| 特性 | Redis分布式锁 | ZooKeeper分布式锁 | |------|-------------|------------------| | 实现复杂度 | 中等 | 简单 | | 性能 | 高 | 中等 | | 可靠性 | 依赖部署方式 | 高 | | 锁释放机制 | 超时释放 | 连接断开释放 | | 锁等待机制 | 客户端轮询 | 事件通知 | | 适用场景 | 高性能要求 | 高可靠性要求 |