redis 实现分布式锁

        在单机系统中可以将锁的标识放入应用内存中。但分布式系统中需要将锁的标识放入共享存储系统中，如果不要求强一致性可以使用redis作为共享存储系统。

 

单节点分布式锁

        单节点分布式锁指应用在设置标识时只操作单节点redis，如果对可靠性要求不高可以使用单节点实现分布式锁。其实现也比较简单。主要利用redis单线程处理请求模式设置锁标识。

        流程如下图:

        1.线程A，B两个请求，A先进入redis对flag进行setnx操作（setnx key 当key不存在时添加，存在则直接返回）。

        2.线程A直接完，线程B对flag进行setnx操作，发现相应key已经存在，返回设置失败。

        3.线程A执行完业务代码删除刚才设置的flag。

         大致流程如上图所示，不过在加锁与解锁过程中需要注意两个点。

        1.设置flag对应过期时间防止线程A执行业务代码期间发生异常，没有释放锁。

        2.删除flag时需要使用原子操作判断该flag是否是当前客户端设置，如果是则进行删除。

实现代码如下

设置flag，其中client_unique_id为客户端唯一id， px 5000表示5秒过期
set flag client_unique_id nx px 5000


删除flag ，其中1 flag client_unique_id分别表示1个key，keys[1]对应flag，ARGV[1]对应client_unique_id

eval "if redis.call("get",KEYS[1]) == ARGV[1] then redis.call("del",KEYS[1]) return 200 else return 500 end" 1 flag client_unique_id

格式化一下
eval "
if redis.call("get",KEYS[1]) == ARGV[1] then
   redis.call("del",KEYS[1]) 
   return 200 
else 
   return 500 
end
" 1 flag client_unique_id

多节点分布式锁

        针对单节点宕机的情况，antirez 提出了多节点分布式锁算法 redlock，算法主要思路是判断加锁成功的节点数是否超过总结点数/2+1。其主要流程如下

        1.客户端获取当前时间。

        2.各线程依次向每个节点设置带有过期时间的flag进行加锁。并且设置线程超时时间，防止线程占用过多时间，导致超过flag设置的超时时间。

        3.各客户端加锁完成后计算加锁耗时，判断剩余时间=flag超时时间-加锁耗费的时间是否够执行业务代码，判断加锁成功节点数是否超过总结点数/2+1。

        4.满足3中的条件则加锁成功执行业务代码，不满足则依次删除flag释放锁。

        使用redlock算法可最大程度保证可靠性，但部署成本高，而且还有一些细节问题，比较常见的一些业务处理时间过长，超过了锁设置的时间，这种情况可使用延迟队列对锁续命。其他可参考How to do distributed locking。