python zookeeper解决redis做分布式锁带来的坑

我自己写了一个redis分布式锁的模块,已经推到pypi里面了。 但是带来了一个问题是,如果客户端自己因为内存泄露被系统内核给oom干掉了。

在分布式的架构下,一堆的节点去获取锁是徒劳的,只能等我们先前redis的TTL自动消逝….当然我自己也扩展了一个追加时间戳的方式,来判断他的进程在不在,但是可能会遇到的问题是,他因为hbase的堵塞,会消耗不少的时间…我不能及时的,实时的推送我的任务时间戳….

我想大家就算是在正常的情况下,也是会遇到任务堵塞的情况,又因为你的程序不健全,没有做好timeout超时的释放机制,单纯的用expire做ttl的控制不是那么的合理。 如果应用在我们项目下,会遇到任务正在干着,但是因为某个原因堵塞了,但是自动解锁的时间马上就要到了…  这算是个悲催的场景了….

文章的原文是引用在我的博客…. 

http://xiaorui.cc

http://xiaorui.cc

http://xiaorui.cc

其实我们可以监听客户端的链接的状态….   我们这里可以采用zookeeper来解决这类的问题,zookeeper会自动长连接的,如果客户端中断了连接,不管是你主动还是被动,我都会在我的注册列表里卖弄,干掉你,并且解锁

自己也懒得写了,直接搜了个开源的模块  https://github.com/tinyogre/zklock  在pypi里面,也有不少类似的模块. 

#创建锁
z = zklock.Lock('nima')

 try:
 	#查询是否已经锁定了
     if z.acquire():
         print "zklocktest: Lock acquired"
         time.sleep(20)
         # 解锁
         z.release()
 except:
     z.release()

with zklock.ScopedLock("scoped_lock_test", block=False) as z:
    if z.acquired:
        print "Locked!"
        time.sleep(20)
    else:
        print "Could not obtain lock!"
print "zklocktest: Exiting"

zk节点(znode)可以分为如下四类:

PERSISTENT:持续的,相比于EPHEMERAL,不会随着client session的close/expire而消失
PERSISTENT_SEQUENTIAL:顺序的,会自动在节点名后面添加一个自增计数,格式为%010d
EPHEMERAL:临时节点,生命周期依赖于client session,对应session close/expire后其znode也会消失,临时节点不能有子节点

(我们这里采用的就是 临时节点,因为他有个session的概念….当客户端出现异常后,其他的客户端可以watch监听到的)
EPHEMERAL_SEQUENTIAL
该方法可能触发如下异常:
NodeExistsError:当要创建的节点已经存在时
NoNodeError:当makepath为False且祖先节点不存在时
NoChildrenForEphemeralsError:父节点为临时节点,在一个临时节点下面创建子节点会报该异常
ZookeeperError:节点值太大,zk默认节点值限制为1M
ZookeeperError:服务器返回一个非0状态码




大家觉得文章对你有些作用! 如果想赏钱,可以用微信扫描下面的二维码,感谢!
另外再次标注博客原地址  xiaorui.cc

发表评论

邮箱地址不会被公开。 必填项已用*标注