分布式锁

JVM的锁

ReentrantLock
synchronized

基于数据库悲观锁

for update 仅适用于InnoDB，并且必须开启事务，在begin与commit之间才生效。

SELECT .. FOR UPDATE 加锁后其他线程不能加锁也不能修改 只能读取

基于Redis的setnx

利用setnx的原子性保证多个线程并发只有1个线程可以设置key成功

1.获取锁 
set resource_name random_value NX PX 30000
- resource_name 资源名称 根据业务区分不同的锁
- random_value  随机数 每个线程不一样 用于释放锁校验 
- NX            key不存在则设置成功反正失败 原子性
- PX 30000      自动失效时间出现异常自动释放锁
2.释放锁
del命令 需要校验之前设置的随机数释放相同 防止A线程释放B线程的锁 需要使用Lua脚本 因为del没有提供值校验
if redis.call("get",KEYS[1]) == ARGV[1] then
  return redis.call("del",KEYS[1])
else
  return 0
end

基于Zookeeper的瞬时节点

Zookeeper基本概念

Zookeeper 节点类型可以分为三大类：持久性节点（Persistent）、临时性节点（Ephemeral）、顺序性节点（Sequential）。现实开发中在创建节点的时候通过组合可以生成以下四种节点类型：持久节点、持久顺序节点、临时节点、临时顺序节点。

• 持久节点就是节点被创建后会一直存在服务器，直到删除操作主动清除，这种节点也是最常见的类型。
• 持久顺序节点就是有顺序的持久节点，节点特性和持久节点是一样的，只是额外特性表现在顺序上。顺序特性实质是在创建节点的时候，会在节点名后面加上一个数字后缀，来表示其顺序。
• 临时节点就是会被自动清理掉的节点，它的生命周期和客户端会话绑在一起，客户端会话结束，节点会被删除掉。与持久性节点不同的是，临时节点不能创建子节点。
• 临时顺序节点就是有顺序的临时节点，和持久顺序节点相同，在其创建的时候会在名字后面加上数字后缀。

观察器：Zookeeper可以设置观察器监控节点变换，发送到客户端

实现分布式锁原理

1. 利用Zookeeper瞬时节点有序的特性，多线程并发创建瞬时节点会得到有序的序列
2. 序号最小的线程获取锁
3. 其他线程则监听自己序号的前一个序号的节点
4. 前一个线程执行完毕，删除自己序号的节点
5. 下一个序号的线程得到通知，继续执行
6. 以此类推，创建节点的时候，已经确定了线程执行顺序

实际生产使用类库 Curator/Redisson(续期看门狗策略)

• http://curator.apache.org/getting-started.html
• https://github.com/redisson/redisson/