分布式锁到底用Redis和Zookeeper那个好用

redis 实现分布式锁:
首先redis是单线程的,即一个线程处理所有网络请求,其他模块仍用了多个线程.
1,第一种就是在set完key之后,直接设置key的有效期 ,为key设置一个超时时间,单位为second,超过这个时间锁会自动释放,避免死锁.
这种方式相当于,把锁持有的有效期,交给了redis去控制.如果时间到了,那redis就直接给你删了,其他服务器就可以继续去setnx获取锁.
2,第二种方式,就是把删除key权利交给其他的服务器,那这个时候就需要用到value值了,
比如服务器1,设置了value 也就是 timeout 为 当前时间+1 秒 ,这个时候服务器2 通过get 发现时间已经超过系统当前时间了,那就说明服务器1没有释放锁,服务器1可能出问题了,服务器2就开始执行删除key操作,并且继续执行setnx 操作.

ZooKeeper 实现分布式锁:
zk可以创建节点类型
1,持久性节点
2,持久性顺序节点
3,临时性节点
4,临时性顺序节点
持久性节点和临时性节点的区别,持久性节点表示只要你创建了这个节点,那不管你ZooKeeper的客户端是否断开连接,ZooKeeper的服务端都会记录这个节点.
临时性节点刚好相反,一旦你ZooKeeper客户端断开了连接,那ZooKeeper服务端就不再保存这个节点.
顺序性节点是指,在创建节点的时候,ZooKeeper会自动给节点编号比如0000001 ,0000002 这种的.

zk的锁可以用临时性节点:
临时性节点的特点是客户端一旦断开,就会丢失,也就是当服务器1创建了节点后,如果挂了.那这个节点会自动被删除,这样后续的其他服务器,就可以继续去创建节点,获取锁了.
但是我们可能还需要注意到一点,就是惊群效应：举一个很简单的例子,当你往一群鸽子中间扔一块食物,虽然最终只有一个鸽子抢到食物,但所有鸽子都会被惊动来争夺,没有抢到…就是当服务器1节点有变化,会通知其余的99个服务器,但是最终只有1个服务器会创建成功,这样98还是需要等待监听,那么为了处理这种情况,就需要用到临时顺序性节点
当001节点处理完毕,删除节点后,002收到通知,去获取锁,开始执行,执行完毕,删除节点,通知003~以此类推