Redis分布式锁架构设计

setnx命令

仅当一个key不存在时，才设置成功，返回1，否则设置失败，返回0

防止死锁

设置过期时间，redis2.8以前需要通过lua脚本保证setnx命令和expire命令的原子性，2.8以后可以直接通过setnx ex|px命令

执行时间过长导致锁已经释放

可能获取锁成功的线程执行业务比较久，比如只锁了3s，但是业务执行了4s，解决方案有两种，第一：评估加锁代码块执行时间，设置锁的时间；第二：watchdog思想，异步线程定期给锁续约；

释放锁

通过del命令实现，但是需要判断锁是否是自己设置的，其实这个是有必要的，因为redis本身的问题，比如设置key成功了，但是还没持久化到磁盘redis就宕机了，重启的时候就没有这个key，高并发下其他线程就有可能获取锁成功，就算有了watchdog也还是可能会存在这个问题

没有获取锁成功的线程怎么办

两种方案，第一：自旋重试获取锁，特别消耗cpu，不可取；第二：阻塞-唤醒思想，没有获取锁，就阻塞一段时间再重试，获取锁成功的线程可以释放锁的同时往队列发一个消息，然后其他线程消费这个消息，去唤醒本地的线程；

总结思考

因为redis本身持久化导致，无论怎么样，实现分布式锁都是不安全的，单机/哨兵/集群，或者说什么红锁。拿单机来说，设置key成功了但还没持久化，redis就挂了，重启的时候就没有这个key，高并发下其他线程就可能成功获取锁。其他比较可靠的方案有zk/etcd。