redis分布式锁的常见坑包括锁的误删除和过期时间设置不合理。针对锁的误删除，解决方法是将锁的value设为客户端唯一标识，并通过lua脚本原子性判断后再释放锁；针对过期时间问题，可采用“看门狗”机制自动续期。此外，常见的5种实现方式各有优劣：1.setnx+expire非原子操作易导致死锁，仅适用于学习；2.setnx+lua脚本解决原子性和误删问题，但需维护脚本；3.set命令扩展参数（nx/ex）推荐使用，简洁高效且原子性强；4.redlock算法提高可用性但复杂度高，适用于高要求场景；5.redisson框架封装完善、功能丰富，适合java项目使用。选择实现方式应根据业务需求权衡可靠性、可用性和系统复杂度。
Redis 实现分布式锁，核心在于利用其单线程特性和原子操作，确保在分布式环境下只有一个客户端能获得锁。对比多种实现方式，我们需要关注性能、可靠性、复杂度和容错性等因素。
Redis 实现分布式锁，通常会使用 SETNX（SET if Not eXists）命令，它只有在 key 不存在时才设置 key 的值。拿到锁的客户端可以执行业务逻辑，完成后释放锁（通常使用 DEL 命令）。但简单的 SETNX + DEL 存在很多问题，需要进一步完善。
Redis 分布式锁有哪些常见的坑？如何避免？
最常见的坑就是锁的误删除。客户端 A 获得了锁，执行业务逻辑的时间超过了锁的过期时间，Redis 自动释放了锁。此时，客户端 B 获得了锁。随后，客户端 A 完成了业务逻辑，执行 DEL 命令，却把客户端 B 的锁给释放了。
为了避免这种情况，可以在设置锁的时候，将 value 设置为客户端的唯一标识（比如 UUID）。释放锁的时候，先判断锁的 value 是否是自己的标识，如果是才执行 DEL 命令。这个判断和 DEL 命令需要是原子性的，可以使用 Lua 脚本来实现。
另外一个坑是锁的过期时间设置不合理。如果过期时间设置太短，可能导致锁提前释放，引发并发问题；如果过期时间设置太长，可能导致锁无法及时释放，影响系统的可用性。
解决这个问题，可以采用“看门狗”机制。客户端在获得锁之后，启动一个后台线程，定期检查锁是否快要过期。如果快要过期，就自动续期。Redisson 框架就实现了这种机制。
Redis 分布式锁的 5 种实现方式对比
-
SETNX + EXPIRE (最基础的实现)
-
实现: 使用
SETNX获取锁，EXPIRE设置过期时间。 - 优点: 简单易懂。
-
缺点: 非原子操作，
SETNX成功后，EXPIRE失败会导致死锁。 - 适用场景: 学习和演示，生产环境不推荐。
-
实现: 使用
-
SETNX + Lua 脚本
-
实现: 使用
SETNX获取锁，通过 Lua 脚本原子性地设置过期时间。释放锁时，也通过 Lua 脚本判断锁的持有者是否是自己，防止误删。 -
优点: 解决了
SETNX+EXPIRE的非原子性问题，以及锁的误删除问题。 - 缺点: 需要编写和维护 Lua 脚本。
- 适用场景: 对可靠性有一定要求的场景。
-
实现: 使用
-
SET 命令扩展参数 (SET key value [EX seconds] [PX milliseconds] [NX|XX])
-
实现: Redis 2.6.12 之后，
SET命令增加了NX(不存在才设置),XX(存在才设置),EX(秒级过期),PX(毫秒级过期) 等参数，可以原子性地完成SETNX+EXPIRE的功能。 - 优点: 原子性操作，代码简洁。
- 缺点: 需要 Redis 版本支持。
- 适用场景: 推荐使用，简单高效。
SET lock_key unique_id NX EX 10
-
实现: Redis 2.6.12 之后，
-
Redlock 算法
- 实现: 尝试从 N 个独立的 Redis 实例获取锁，只有超过半数成功才认为获取锁成功。释放锁时，需要释放所有 Redis 实例上的锁。
- 优点: 提高了锁的可用性，即使部分 Redis 实例宕机，锁仍然可以正常工作。
- 缺点: 实现复杂，性能较低，需要维护多个 Redis 实例，存在争议。
- 适用场景: 对可用性要求极高的场景，例如金融支付。
-
Redisson 框架
- 实现: Redisson 是一个 Redis 的 Java 客户端，提供了分布式锁的实现，包括可重入锁、公平锁、联锁、红锁等。它实现了看门狗机制，自动续期，解决了锁的过期时间问题。
- 优点: 封装了分布式锁的各种细节，使用简单，功能强大。
- 缺点: 引入了额外的依赖，增加了系统的复杂度。
- 适用场景: Java 项目，需要使用分布式锁，但不想自己实现。
如何选择合适的 Redis 分布式锁实现方式？
选择哪种实现方式，需要根据具体的业务场景和需求来决定。
- 如果只是学习和演示，或者对可靠性要求不高，可以使用
SETNX + EXPIRE。 - 如果对可靠性有一定要求，可以使用
SETNX + Lua 脚本或SET 命令扩展参数。 - 如果对可用性要求极高，可以使用 Redlock 算法。
- 如果是 Java 项目，并且不想自己实现分布式锁，可以使用 Redisson 框架。
需要注意的是，即使使用了分布式锁，也无法保证绝对的安全性。在设计系统时，还需要考虑其他的并发控制手段，例如乐观锁、悲观锁等。同时，要做好监控和报警，及时发现和处理问题。另外，不要过度依赖分布式锁，尽量减少锁的竞争，提高系统的性能。
