4.秒杀模块-分布式加锁问题-基于Zookeeper解决redis和synchronized的加锁问题

并发处理:

1.加synchronized锁单线程处理、缺点： 

1.处理速度也会很慢  

2.只适合单点的情况
3.无法做到细粒度控制

2.redis分布式锁：

1.可以支撑每秒10多万的并发，

2.支持分布式，

3.可以更细粒的控制代码（多台机器上多个线程对一个数据进行操作的互斥）

SETNX key value

将key设置值为value,如果key不存在，这种情况下等同于SET命令，当key存在时，什么也不做

GETSET key value

自动将key对应到value并且返回原来key和对应的value,如果key存在但是对应的value不是字符串，就返回错误

 

还有Redis分布式锁其实是非公平的。

使用Zookeeper可以解决公平锁问题，客户端在ZK中创建的临时节点是有序的，每次锁被释放时，ZK可以通知最小节点来获取锁，保证了公平。

还有想到的可以用一个redis消息队列去存储（IO多路复用）应该也是可以的。

 

下面介绍一下，可以监听客户端连接，以及有公平锁的ZooKeeper：

 

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

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

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

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

自己也懒得写了，直接搜了个开源的模块  https://github.com/tinyogre/zklock 。

#创建锁

z = zklock.