分布式锁

分布式锁

解决分布式锁的核心思路

• 在多台服务器集群中，只能够保证一个jvm/进程进行操作。

基于数据库

• 不建议 性能不好

基于redis

• 多个客户端，使用setnx命令方式，同时在redis上创建相同的一个key，因为rediskey不能够允许重复，谁能创建key成功，返回1，谁就能够获取到锁。没有创建key成功，就返回0，jvm就会进行等待。
• 两个超时时间
  • 在获取锁之前的超时时间---在尝试获取锁的时候，如果在规定的时间内还没有获取锁成功，直接放弃。
  • 在获取锁之后的超时时间---在尝试获取锁成功后，对应的key有对应的有效期，在对应的时间内shi

基于zookeeper

• zookeeper是一个分布式协调工具，在分布式解决方案中，多个客户端，同事在zk上创建相同的临时节点，因为临时节点路径是保证唯一的，只要谁能够创建节点成功，谁就能够获取到锁，没有创建节点成功的，就会进行等待，到锁释放的时候，采用事件通知给客户端从而充当新去获取锁资源。

基于redis和基于zookeeper的异同

• 不同点
  • rdis是基于缓存，zookeeper是基于分布式协调能力。
  • zookeeper更适合于分布式环境。
• 核心不同点总结
  • 获取锁
    • zookeeper:多个客户端（jvm），会在Zookeeper上创建同一个临时节点，因为Zookeeper节点命名路径保证唯一，不允许出现重复，只要谁能够先创建成功，谁能够获取到锁。
    • Zookeeper:多个客户端（jvm），会在Zookeeper上创建同一个临时节点，因为Zookeeper节点命名路径保证唯一，不允许出现重复，只要谁能够先创建成功，谁能够获取到锁。
  • 释放锁
    • Zookeeper:使用直接关闭临时节点session会话连接，因为临时节点生命周期与session会话绑定在一块，如果session会话连接关闭的话，该临时节点也会被删除。这时候客户端使用事件监听，如果该临时节点被删除的话，重新进入获取锁的步骤
    • Redis在释放锁的时候，为了确保是锁的一致性问题，在删除的redis 的key时候，需要判断同一个锁的id，才可以删除。
  • 死锁问题
    • Zookeeper使用会话有效期方式解决死锁现象。
      Redis 是对key设置有效期解决死锁现象

总结

• redis的性能比zookeeper的性能高。因为redis毕竟是基于nosql的操作。
• Zookeeper可靠性比Redis更好。因为Redis有效期不是很好控制，可能会产生有效期延迟，Zookeeper就不一样，因为Zookeeper临时节点先天性可控的有效期，所以相对来说Zookeeper比Redis更好