------------------------------------------------------------------------------------------------------慢慢来，一切都来得及
前言
分布式应用中经常会遇到并发问题，比如商品减库存操作，需要先读库存，然后再写库存。如果同时进行，就会出现并发问题，这是因为读和写不是在一个原子性操作的，这时就要采用分布式锁来控制了。
分布式锁的特点
为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：
1、互斥性：任意时刻，只能有一个客户端获取锁，不能同时有两个客户端获取到锁。
2、安全性：锁只能被持有该锁的客户端删除，不能由其它客户端删除。
3、不发生死锁：即使获取锁的客户端因为某些原因（如down机等）而未能释放锁，也要保证其它客户端能获取到锁。
4、容错：当部分节点（redis节点等）down机时，客户端仍然能够获取锁和释放锁。
分布式锁实现方案
- 基于数据库实现
- 基于数据库实现分布式锁，主要使用InnoDB下的for update（如使用行级锁，需加唯一索引）
- 基于Zookeeper实现
- 在指定节点的目录下，创建一个唯一的瞬时有序节点。可以使用Curator去实现。
- 基于缓存实现（redis）
- 主要使用set（setnx用法有缺陷且过时）
从2.6.12版本后, 就可以使用set来获取锁, Lua 脚本来释放锁。set命令nx,xx等参数, 是为了实现 setnx 的功能。
加锁
public class RedisTool {
private static final String LOCK_SUCCESS = "OK";
private static final String SET_IF_NOT_EXIST = "NX";
private static final String SET_WITH_EXPIRE_TIME = "PX";
/**
* 尝试获取分布式锁
* @param jedis Redis客户端
* @param lockKey 锁
* @param requestId 请求标识
* @param expireTime 超期时间
* @return 是否获取成功
*/
public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {
String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
if (LOCK_SUCCESS.equals(result)) {
return true;
}
return false;
}
}String set(String key, String value, String nxxx, String expx, long time);
该方法是： 存储数据到缓存中，并制定过期时间和当Key存在时是否覆盖。
nxxx： 只能取NX或者XX，如果取NX，则只有当key不存在是才进行set，如果取XX，则只有当key已经存在时才进行set
expx： 只能取EX或者PX，代表数据过期时间的单位，EX代表秒，PX代表毫秒。
time： 过期时间，单位是expx所代表的单位。
解锁
public class RedisTool {
private static final Long RELEASE_SUCCESS = 1L;
/**
* 释放分布式锁
* @param jedis Redis客户端
* @param lockKey 锁
* @param requestId 请求标识
* @return 是否释放成功
*/
public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));
if (RELEASE_SUCCESS.equals(result)) {
return true;
}
return false;
}
}除此之外，也可以使用Redission(Redis 的客户端)集成进来实现分布式锁
超时问题
Redis 的分布式锁不能解决超时问题，如果在加锁和释放锁之间的逻辑执行的太长，以至于超出了锁的超时限制，就会出现问题。因为这时候锁过期了，第二个线程重新持有了这把锁， 但是紧接着第一个线程执行完了业务逻辑，就把锁给释放了，第三个线程就会在第二个线程逻辑执行完之间拿到了锁。 为了避免这个问题，Redis 分布式锁不要用于较长时间的任务。如果真的偶尔出现了，数据出现的小波错乱可能需要人工介入解决。
有一个更加安全的方案是为 set 指令的 value 参数设置为一个随机数，释放锁时先匹配 随机数是否一致，然后再删除 key。但是匹配 value 和删除 key 不是一个原子操作，Redis 也 没有提供类似于 delifequals 这样的指令，这就需要使用 Lua 脚本来处理了，因为 Lua 脚本可以保证连续多个指令的原子性执行（上面的解锁即用的Lua脚本）。
