分布式【分布式锁】
一、简介
满足分布式系统或者集群模式下多进程课件并且互斥的锁。
二、说明
【可见性】：多个线程都能看到相同的结果，注意：这个地方说的可见性并不是并发编程中指的内存可见 性，只是说多个进程之间都能感知到变化的意思。
【互斥】：互斥是分布式锁的最基本的条件，使得程序串行执行。
【高可用】：程序不易崩溃，时时刻刻都保证较高的可用性。
【高性能】：由于加锁本身就让性能降低，所有对于分布式锁本身需要他就较高的加锁性能和释放锁性能。
【安全性】：安全也是程序中必不可少的一环。
三、3种实践
1、Mysql：mysql本身带有锁机制，但是由于Mysql性能本身一般，所以采用分布式锁的情况下，其实使用Mysql作为分布式锁比较少见。
2、Redis：redis作为分布式锁是非常常见的一种使用方式，现在企业级开发中基本都是使用Redis或者zookeeper作为分布式锁，利用setnx这个方法，如果插入key成功，则表示获得了锁，如果有人插入成功，其他人插入失败则表示无法获得锁，利用该逻辑来实现的分布式锁。
3、Zookeeper：Zookepper也是企业级开发中较好的一个实现分布式锁的方案。
四、Redis实现分布式锁
1、获取锁
a、互斥：确保只能有一个线程获取锁
b、非阻塞：尝试一次，成功返回true，失败返回false
2、释放锁
a、手动释放
b、超时释放：获取锁时添加一个超时时间
3、核心思路
利用Rredis的setNX方法，当有多个线程进入时，利用该方法，第一个线程进入时，redis 中就有这个key 了，返回了1，如果结果是1，则表示他抢到了锁，那么他去执行业务，然后再删除锁，退出锁逻辑，没有抢到锁的线程，等待一定时间后重试即可。
4、实践
4.1、锁的基本接口
4.2、代码示例
public interface ILock { /** * 尝试获取锁 * @param timeOutSec 锁持有的超时时间，过期后自动释放 * @return true 代表获取锁成功；false代表获取锁失败 * */ boolean tryLock(long timeOutSec); /** * 释放锁 * */ void unlock(); }
public class RedisLock implements ILock { /** * 锁的前缀 */ private static final String KEY_PREFIX = "lock"; //锁的key，业务的名称 private String name; private StringRedisTemplate stringRedisTemplate; public RedisLock(String name, StringRedisTemplate stringRedisTemplate) { this.name = name; this.stringRedisTemplate = stringRedisTemplate; } @Override public boolean tryLock(long timeOutSec) { String threadId = String.valueOf(Thread.currentThread().getId()); Boolean sucess = stringRedisTemplate.opsForValue().setIfAbsent(KEY_PREFIX + name, threadId, timeOutSec, TimeUnit.SECONDS); return Boolean.TRUE.equals(sucess); } @Override public void unlock() { //通过del删除锁 stringRedisTemplate.delete(KEY_PREFIX + name); } }
修改业务逻辑:
@Override @Transactional public Result seckillVoucher(Long voucherId, Long userId) { // 1.查询优惠券 SeckillVoucher voucher = seckillVoucherService.getById(voucherId); // 2.判断秒杀是否开始 if (voucher.getBeginTime().isAfter(LocalDateTime.now())) { // 尚未开始 return Result.fail("秒杀尚未开始！"); } // 3.判断秒杀是否已经结束 if (voucher.getEndTime().isBefore(LocalDateTime.now())) { // 尚未开始 return Result.fail("秒杀已经结束！"); } // 4.判断库存是否充足 if (voucher.getStock() < 1) { // 库存不足 return Result.fail("库存不足！"); } //锁的范围是用户，所以name拼接上userId String name = "order:" + userId; //创建锁对象(新增代码) RedisLock lock = new RedisLock(name, stringRedisTemplate); //获取锁对象 boolean isLock = lock.tryLock(1200); //加锁失败 if (!isLock) { return Result.fail("不允许重复下单"); } try { //获取代理对象(事务) IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy(); return proxy.createVoucherOrder(voucherId, userId); } finally { //释放锁 lock.unlock(); } }
常用的思路如下图：
五、Zookepper实现分布式锁
zookeeper是基于树形数据结构实现分布式锁，以用来解决我们分布式环境下对于共享资源的数据一致性问题。其中，zookeeper树形结构有四种节点：
- 持久节点。这是zookeeper的默认节点类型，一直存在。
- 持久顺序节点。创建的节点，zookeeper会依据时间的顺序对创建的节点进行排序。
- 临时节点，就是在zookeeper中临时创建的节点，zookeeper客户端与服务端断开或者是故障，就会删除临时节点。
- 临时顺序节点，和持久顺序节点类似，只不过就是临时的。
5.1、实现分布式流程
1、首先假如第一个客户端来获取共享资源也就是获取锁时，zookeeper客户端会创建持久根节点/locks。
2、这个时候，客户端Client1就会查询/locks节点下面所有子节点，然后判断自己的节点是不是排序最小的那个，此时，如果是最小的则会获得锁，就能够对共享资源进行操作。
3、如果，这个时候又来个个客户端Client2也来尝试获取锁，那么它也会在zookeeper的/locks节点下创建一个节点。
4、Client2同样也会查询zookeeper中/locks节点下所有节点，判断自己编号是不是最小的，此时，发现自己并不是最小的，所以获取锁失败，然后就像它的前面一位节点0001注册Watcher事件来监控0001节点是否存在。
5、此时，又来一个客户端Client3来尝试获取锁，就会在/locks下创建自己的节点。
6、同样，客户端Client3查询/locks下所有节点，判断自己是不是编号最小的节点，此时，发现自己并不是最小的，就会获取所失败，接着就会像它前面一位0002的节点注册Watcher事件，来监听0002节点是否存在。
所以，我们现在能发现获得锁的是客户端Client1，客户端Client2则监听着Client1的锁啥时候释放，而Client3就监听着Client2的锁释放。
5.2、释放锁流程
1、当客户端Client1业务完成之后，或者客户端故障，就会删除节点0001，主动释放锁。
2、0001节点被删除，此时Client2就会立马监听到锁被释放，就会去获取锁。
3、客户端Client2获得锁后，完成了业务操作，就会删掉0002编号节点。
4、最后Client3监听到0002被删除了，则自己就会去获取锁和释放锁。
六、分布式锁误删
6.1、误删除情况说明
持有锁的线程在锁的内部出现了阻塞，导致他的锁自动释放，这时其他线程，线程2来尝试获得锁，就拿到了这把锁，然后线程2在持有锁执行过程中，线程1反应过来，继续执行，而线程1执行过程中，走到了删除锁逻辑，此时就会把本应该属于线程2的锁进行删除，这就是误删别人锁的情况说明。
【解决方案】
在每个线程释放锁的时候，去判断一下当前这把锁是否属于自己，如果属于自己，则不进行锁的删除，假设还是上边的情况，线程1卡顿，锁自动释放，线程2进入到锁的内部执行逻辑，此时线程1反应过来，然后删除锁，但是线程1，一看当前这把锁不是属于自己，于是不进行删除锁逻辑，当线程2走到删除锁逻辑时，如果没有卡过自动释放锁的时间点，则判断当前这把锁是属于自己的，于是删除这把锁。
在获取锁时存入线程标识：比如可以用UUID表示
/**---------------------------------解决Redis分布式锁误删问题-------------------------------------------------*/ private static final String ID_PREFIX = UUID.randomUUID().toString(true) + "-"; @Override public boolean tryLock(long timeOutSec) { //获取线程标识 String threadId = ID_PREFIX +Thread.currentThread().getId(); //获取锁 Boolean sucess = stringRedisTemplate.opsForValue().setIfAbsent(KEY_PREFIX + name, threadId, timeOutSec, TimeUnit.SECONDS); return Boolean.TRUE.equals(sucess); } @Override public void unlock() { //获取线程标识 String threadId = ID_PREFIX +Thread.currentThread().getId(); //获取锁中的标识 String id = stringRedisTemplate.opsForValue().get(KEY_PREFIX + name); //判断是否一致 if (threadId.equals(id)) { //通过del删除锁 stringRedisTemplate.delete(KEY_PREFIX + name); } }
七、分布式锁原子性问题
线程1现在持有锁之后，在执行业务逻辑过程中，他正准备删除锁，而且已经走到了条件判断的过程中，比如他已经拿到了当前这把锁确实是属于他自己的，正准备删除锁，但是此时他的锁到期了，那么此时线程2进来，但是线程1他会接着往后执行，当他卡顿结束后，他直接就会执行删除锁那行代码，相当于条件判断并没有起到作用，这就是删锁时的原子性问题，之所以有这个问题，是因为线程1的拿锁，比锁，删锁，实际上并不是原子性的，我们要防止刚才的情况发生
7.2、Lua脚本解决多条命令原子性问题
Redis提供了Lua脚本功能，在一个脚本中编写多条Redis命令，确保多条命令执行时的原子性。Lua是一种编程语言，它的基本语法大家可以参考网站；这里重点介绍Redis提供的调用函数，我们可以使用lua去操作redis，又能保证他的原子性，这样就可以实现拿锁比锁删锁是一个原子性动作了，作为Java程序员这一块并不作一个简单要求，并不需要大家过于精通，只需要知道他有什么作用即可。
这里重点介绍Redis提供的调用函数，语法如下
redis.call('命令名称', 'key', '其它参数', ...)
例如，我们要执行set name jack，则脚本是这样：
# 执行 set name jack redis.call('set', 'name', 'jack')
例如，我们要先执行set name Rose，再执行get name，则脚本如下：
# 先执行 set name jack redis.call('set', 'name', 'Rose') # 再执行 get name local name = redis.call('get', 'name') # 返回 return name
写好脚本以后，需要用Redis命令来调用脚本，调用脚本的常见命令如下：
如果脚本中的key、value不想写死，可以作为参数传递。key类型参数会放入KEYS数组，其它参数会放入ARGV数组，在脚本中可以从KEYS和ARGV数组获取这些参数：
接下来我们来回一下我们释放锁的逻辑：
释放锁的业务流程是这样的
1、获取锁中的线程标示
2、判断是否与指定的标示（当前线程标示）一致
3、如果一致则释放锁（删除）
4、如果不一致则什么都不做
如果用Lua脚本来表示则是这样的：
最终我们操作redis的拿锁比锁删锁的lua脚本就会变成这样
-- 这里的 KEYS[1] 就是锁的key，这里的ARGV[1] 就是当前线程标示 -- 获取锁中的标示，判断是否与当前线程标示一致 if (redis.call('GET', KEYS[1]) == ARGV[1]) then -- 一致，则删除锁 return redis.call('DEL', KEYS[1]) end -- 不一致，则直接返回 return 0
