对于 Redis 分布式锁的实现方式，网上讨论相关文章都基本都“烂大街”了。然而几乎所有相关介绍都是在单纯使用 setNX 命令的基础上进行一个简单封装。笔者之前也写了一篇《Redis分布式锁实现》,原理同样是基于 setNX 命令上的封装。阿里云专访 Redisson 作者 Rui Gu：构建开源企业级 Redis 客户端之路上 Redisson 的作者提出了这种方式的不足。
核心缺陷
1.不具备可重入性
在执行 setnx 命令时，通常采用业务上指定的名称作为 key 名，用时间或随机值作为 value 来实现。这样的实现方式不具备追踪请求线程的能力，同时也不具备统计重入次数的能力，甚至有些实现方式都不具备操作的原子性。当遇到业务上需要在多个地方用到同样一个锁的时候，很显然使用不具有可重入的锁会很容易发生死锁的现象。特别是在有递归逻辑的场景里，发生死锁的几率会更高。Java 并发工具包里的 Lock 对象和 sychronized 语块都具有可重入性，对于经常使用这些工具的人来说，往往会很容易忽略 setnx 的这个缺陷。
2.不支持续约
在分布式环境中，为了保证锁的活性和避免程序宕机造成的死锁现象，分布式锁往往会引入一个失效时间，超过这个时间则认为自动解锁。这样的设计前提是开发人员对这个自动解锁时间的粒度有一个很好的把握，太短了可能会出现任务没做完锁就失效了，而太长了在出现程序宕机或业务节点挂掉时，其它节点需要等很长时间才能恢复，而难以保证业务的 SLA。setnx 的设计缺乏一个延续有效期的续约机制，无法保证业务能够先工作做完再解锁，也不能确保在某个程序宕机或业务节点挂掉的时候，其它节点能够很快的恢复业务处理能力。
3.不具备阻塞的能力
平常大家多少都接触过的锁，由于加锁策略（Locking Strategy）的差别，使得每种锁都有各自不同的特性。但是在通常情况下这些锁都具备两个共性：一是互斥性，二是阻塞性。互斥性是指在任何时刻最多只能有一个线程获得通行的资格。阻塞性是指的在有竞争的情况下，未获取到资源的线程会停止继续操作，直到成功获取到资源或取消操作。很显然 setnx 命令只提供了互斥的特性，却没有提供阻塞的能力。虽然在业务代码里可以引入自旋机制来进行再次获取，但这仅仅是把原本应该在锁里实现的功能搬到了业务代码里，通过增加业务代码的复杂程度来简化锁的实现似乎显得有点南辕北辙。