使用redis构建可靠分布式锁

关于分布式锁的概念,具体实现方式,直接参阅下面两个帖子,这里就不多介绍了。

分布式锁的多种实现方式

分布式锁总结

对于分布式锁的几种实现方式的优劣,这里再列举下

1. 数据库实现方式

优点:易理解

缺点:操作数据库消耗较大,性能较低。为了处理一些异常,会使得整个方案越来越复杂

2. 缓存实现方式

优点:性能好,实现起来较为方便。

缺点:通过超时时间来控制锁的失效时间并不是十分的靠谱。

3 zookeeper实现

优点:有效的解决单点问题,不可重入问题,非阻塞问题以及锁无法释放的问题。

缺点:性能上不如使用缓存实现分布式锁

第二篇帖子中,谈到redis实现分布式锁时,提了一些建议

"redis如果能像ZooKeeper一样,实现了和客户端绑定的临时key,一旦redis客户端挂了,临时key删除,通知watchkey的其他客户端(感觉这个是一个不错的需求,不知redis未来是否要实现),就可以消除锁超时,再使用Redlock实现的分布式锁,这时候可靠性就更高了。"

 

就性能而言,redis比zookeeper具有天然优势,而它的缺点也可以通过一些机制来另外改进。所以就尝试着修改了redis的源码,看能否解决上述问题。

修改点一:增加一条命令settp

settp(tp 可以理解为temporary的缩写),故名思议,就是一个临时的key。

命令格式:settp key value

首先使用这条命令,必须保证key是不存在的,即这个命令具有setnx命令的属性,然后在添加完key之后,将这个key加入到执行这条命令client的一个list里面。这个list专门用来保存临时键。那么在redis客户端挂了,或者意外断开连接时,在调用freeclient()函数时,便可以将临时键清理掉。就不会影响其他client再次获取锁

 

修改点二:增加命令watchex

命令格式:watchex key

返回:redisReply是一个字符串类型

        如果key存在,则str内容为"EXIST"

        如果key不存在,则str内容为"NOEXIST"

        如果key被添加,返回"ADD";key被删除时,返回"DEL"

watchex,ex可以认为是exist的缩写,也是为了区别redis本身带有的watch命令。自带的watch命令,是为了在执行事务时,保证事务执行过程中键不被修改的一种乐观锁机制。而我们要实现的watchex命令,是为了监视某个键是否存在。在执行命令时,立即会返回一个结果,表示这个键是否存在。然后在运行过程中,如果这个键被创建,或者被删除,也会通知到watchex该key的所有客户端。

示例如下:

首先运行hiredis-example-ae,对应的源文件是example-ae.c

在另一个窗口中执行如下命令

可以看到在删除或者添加某个key时,在第一个窗口中都会收到通知

如果不想再watchex某个key,执行unwatchex key命令即可。

这个命令的实现原理其实有点类似redis 自身的pubsub机制,但是pubsub有一个局限就是,执行了该命令之后,就不能执行其他命令,只能等待channel上的信息。这种方式显然不适用于我们的场景。

我们的实现方式是,首先需要在client中保存一个所有watchex的list,然后在系统增加一个dict,用于保存每个被watchex的key。这个dict的键就是被watchex的key,值就是所有watchex这个key的client组成的一个链表。

无论在添加或者是删除某个key时,都去检查一下这个dict里面,有没有这个key。如果有,取出所有的client,发一份通知消息。

由于这个watchex这个命令,是一个典型的异步通知。所以在客户端调用这个命令时,要使用redis的异步执行命令接口redisAsyncCommand。具体调用方式,可以参考example-ae.c文件。

当然在客户端解析请求时,也要做一些变化。在async.c这个文件中,redisProcessCallbacks()这个函数专门解析服务器发回来的相应。每次从读缓冲区组装出一个redisreply结构,然后从redisCallbackList 里面取出头结点,其实就是一个回调函数,将redisreply传入到这个回调函数。这就是一次正常的调用过程。但是对于watchex命令,它是一个永久命令,故而不能回调函数不能插到redisCallbackList里面,所以另外建了一个dict用于保存watchex命令的回调函数,键是watchex命令的key,值即是回调函数。这样每次客户端解析出一个redisreply,首先判断这个reply是不是一个watchex命令的返回,如果是就从dict里面获取相应的回调函数,否则执行原有的解析流程。

整个过程即是如此,那么下面我们说一下在此基础上实现分布式锁的过程

首先,调用settp key "value"命令,如果返回成功,则说明获取锁成功;否则调用watchex key命令。由于这两步操作不是原子的,所以有可能调用watchex命令之后,返回noexist ,那么这时可以再尝试调用settp命令。如果还返回失败,说明锁已经被其他人占有,调用者可以等待或者干别的事。 当占有锁的人,用完释放之后,所有watchex这个key的client都会收到通知,这时所有client都会调用settp命令去抢锁,只会有一个人成功,其余的则继续等待,直到能抢占到锁为止。

从这个过程中,可以看出,这种实现方式会有“惊群”的问题,即通知了所有人,只有一个人能抢到锁,就会导致很多的无效操作。当然,也可以选择在key被释放时,只通知某一个client。但是由于redis的回复消息是没有确认机制的,如果这个通知消息丢失了,就可能导致其他所有的client一直等待下去。目前,还没有更好的解决方法,暂时先选择通知所有的client,如果大家有更好的方案,欢迎留言讨论。

 

文章中所讨论的实现,基于redis3.2.5版本,已经开源在github,地址是https://github.com/myd620/redis-dislock

posted @ 2017-01-03 22:05  myd620  阅读(1349)  评论(0编辑  收藏  举报