分布式锁-多种实现方式

分布式锁-多种实现方式

一． 基于Redis实现的分布式锁

不同进程之间需要互斥访问共享资源，分布式锁是一种非常有用的手段。

1. 基于setnx(), expire(), delete()实现，实现简单，但是setnx()操作是一个非常耗时的操作，就算redis百万QPS，在高并发的场景下也是有问题的
      实现步骤：
         • 获取锁，在redis设置一个键值，并设置一个超时时间
         • 释放锁，删除redis中的这个健值
      缺陷：存在单点故障，一旦redis宕机，则客户端无法获取，释放锁，如果使用集群增加master，slave，当master宕机切换到slave，由于redis复制是异步进行，明显  存在竟态条件，因此不建议使用故障切换的方式。

      注意:在单实例实现分布式锁时，一定要设置key的唯一标志，例如，随机生成一个UUID.randomUUID().toString()，在高并发场景下不推荐使用

     Jedis实现

2. Redis官方网站推荐基于RedLock算法的分布式锁
　　相对网上其他的基于redis的分布式锁，Redis官方提供的更加安全，稳定，可靠，具体如下：
　　　　• 安全属性：互斥，任何时候只有一个客户端持有同一个锁
　　　　• 效率属性A：不会死锁，即使在客户端宕机或者发生网络分区
　　　　• 效率属性B：容错，只要大多数节点工作正常，客户端都能获取、释放锁
　　实现步骤：
　　• 获取锁
　　　　i. 获取当前时间(单位是毫秒)
　　　　ii. 轮流使用相同的key和随机值在N个节点上请求锁，客户端会有请求超时时间和锁释放时间（释放<超时）
　　　　iii. 计算请求获取锁的时间，只有当客户端在大多数master节点上成功获取锁，并且总的消耗时间小于锁的释放时间成功
　　　　iv. 获取锁成功，自动释放锁的时间=锁释放时间-获取锁消耗的时间
　　　　v. 获取锁失败，获取成功锁不超过一半或者总消耗时间大于锁的释放时间，

　　Redission(java实现)

二． 基于Zookeeper实现分布锁

1. 基于zookeeper临时顺序节点实现
　　临时顺序节点特性

•  节点的生命周期与客户端会话绑定，即当创建该节点的会话结束，则该节点会立即删除
•  每个父节点都会维护其子节点的创建顺序，创建节点时父节点会自动分配一个整形数字，以后缀加入节点名字

    实现逻辑：

•  客户端调用create()方法创建名为“_locknode_/lock_”节点，这里需要注意创建节点类型(一定为临时顺序节点)
•  客户端调用getChild(_locknode_)方法获取所有已经创建的子节点，同时在这个子节点注册子节点变更的watcher通知
• 客户端获取所有的子节点path之后，如果发现path路径中序号在所有创建子节点中是最小的，则该客户端获得锁
• 如果发现path中后缀序号不是最小的，则获取锁失败并等待，直到下次子节点变更通知，在进行子节点获取，判断是否获取到锁

    注意：此种实现方式会有惊群效益，大量对这个节点的删除动作有订阅Watcher的线程会进行回调，这对Zk集群是十分不利的。所以需要避免这种现象的发生
释放锁：释放锁非常简单，直接删除节点

2. 改进版本，在第二步放弃订阅一个节点的策略

　　每个节点只需要关注比自己小的节点，并在其上注册节点变更的watcher通知即可

3. 使用Curator，其封装了Zookeeper

三． 基于数据库实现分布式锁

使用数据库的乐观锁实现
　　t_resource , 其中有6个字段id, resoource,  state, add_time, update_time, version,分别表示表主键、资源、分配状态(1未分配  2已分配)、资源创建时间、资源更新时间、资源数据版本号

四． 其他技术　　

tair，chubby，memeched等

五.比较好的文章推荐

http://zhaojiandong.github.io/zookeeperlock/

http://blog.csdn.net/zdy0_2004/article/details/53070209

http://www.cnblogs.com/xybaby/p/7465816.html （有基于消息实现的分布式事务）

 

 后续会用代码实现每种分布式锁，并做相应的对比分析

水平有限，若有问题希望大家指正，谢谢！

 

转载于:https://www.cnblogs.com/blogsf/p/7765179.html