分布式锁-多种实现方式
一． 基于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等
五.比较好的文章推荐
（有基于消息实现的分布式事务）
后续会用代码实现每种分布式锁，并做相应的对比分析
水平有限，若有问题希望大家指正，谢谢！