实现源码：

https://github.com/huangzhenshi/DistributeLearning/tree/master/DistributeLearning-master

参考

飞神RedLock
https://www.jianshu.com/p/7e47a4503b87

官网文档RedLock
https://redis.io/topics/distlock

概述

本文Redis的乐观锁实现、悲观锁实现、Redlock的原理、Redisson框架的实现。

乐观锁在秒杀场景下是最佳的选择，编程简洁，安全性好，并发度高。
基于Redis的秒杀场景和其它传统业务不同。即使在高度竞争的业务场景下，乐观锁的性能也优于悲观锁，因为悲观锁也是不停的retry，而不是排队，另外悲观锁无法并行执行业务。

乐观锁特点：简洁、安全、并发度高

1. 代码简洁
2. 抢锁就是尝试Swap，成功就可以并行的执行各自的业务。Swap失败，循环往复直到库存为负。
3. Swap成功就代表：抢锁成功、释放锁成功、扣减库存成功。其实并没有一个标准锁的动作，只是一个swap的操作，即使当前线程后面执行异常，也不会影响其它线程的执行。

悲观锁特点：并发度差、使用不好会不安全

• 悲观锁是一个标准的锁的方式，有抢锁，抢锁成功后执行校验和业务操作，最后再释放锁的过程
• 悲观锁抢锁成功时，必须要有timeout释放锁的动作，否则当前未释放锁线程出现异常，整个业务停摆，全部阻塞
• 悲观锁抢锁和设置超时时间最佳是一起执行的，而不是先抢锁，再设置expire，因为如果程序在expire异常时，整个服务阻塞不可用
• 悲观锁过程：抢锁成功占用锁，doubleCheck库存，扣减库存，修改抢锁标志位，释放锁，抢锁成功不一定抢单成功，整个过程加了锁，业务无法并发执行。

核心代码

乐观锁：如果修改成功，result不为空，则抢锁成功，快速感知结果

    transaction.set(key, String.valueOf(prdNum - 1));
    List<Object> result = transaction.exec();
    if (result == null || result.isEmpty()) {
            System.out.println("悲剧了，顾客:" + clientName + "没有抢到商品");// 可能是watch-key被外部修改，或者是数据操作被驳回
    } else {
            jedis.sadd(clientList, clientName);// 抢到商品记录一下
            System.out.println("好高兴，顾客:" + clientName + "抢到商品");
            break;
    }

悲观锁：while重试setnx抢锁，特点是一个key只有1个坑位, jedis.del(lockKey);释放锁

jedis.set(String key, String value, String nxxx, String expx, int time)

这个set()方法一共有五个形参：

1. 第一个为key，我们使用key来当锁，因为key是唯一的
2. 第二个为value，我们传的是requestId，很多童鞋可能不明白，有key作为锁不就够了吗，为什么还要用到value？原因就是我们在上面讲到可靠性时，分布式锁要满足第四个条件解铃还须系铃人，通过给value赋值为requestId，我们就知道这把锁是哪个请求加的了，在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成
3. 第三个为nxxx，这个参数我们填的是NX，意思是SET IF NOT EXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作
4. 第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期的设置，具体时间由第五个参数决定
5. 第五个为time，与第四个参数相呼应，代表key的过期时间

乐观锁实现原理：

• 自循环读取库存，库存为正数，就尝试扣减，扣减失败则下一个循环

public void run() {
        while (true) {
            System.out.println("顾客:" + clientName + "开始抢商品");
            jedis = RedisUtil.getInstance().getJedis();
            try {
                jedis.watch(key);
                int prdNum = Integer.parseInt(jedis.get(key));// 当前商品个数
                if (prdNum > 0) {
                    Transaction transaction = jedis.multi();
                    transaction.set(key, String.valueOf(prdNum - 1));
                    List<Object> result = transaction.exec();
                    if (result == null || result.isEmpty()) {
                        System.out.println("悲剧了，顾客:" + clientName + "没有抢到商品");// 可能是watch-key被外部修改，或者是数据操作被驳回
                    } else {
                        jedis.sadd(clientList, clientName);// 抢到商品记录一下
                        System.out.println("好高兴，顾客:" + clientName + "抢到商品");
                        System.out.println("account is: "+ prdNum);
                        break;
                    }
                } else {
                    System.out.println("悲剧了，库存为0，顾客:" + clientName + "没有抢到商品");
                    break;
                }
            } catch (Exception e) {
                e.printStackTrace();
            } finally {
                jedis.unwatch();
                RedisUtil.returnResource(jedis);
            }

        }
    }

悲观锁的实现

通过redis的set (key,value, px ,milliseconds, nx)方法，多个线程对同一个key操作，一次只有一个线程会成功，来实现锁操作，解锁通过jedis.del(lockKey)。

• 类似于Zookeeper的实现原理，需要一个辅助类RedisBasedDistributedLock来实现 tryLock和lock、unlock等操作
• 但是这里的逻辑是非公平锁的形式去抢锁，每个用户循环操作，先读取存量，如果大于0就有3s的时间去抢锁，抢锁失败然后进入下一个循环，这样设计防止库存为0了，其它未抢到锁的线程还不知道。
• 抢锁成功的话，再校验一次存货，仍然大于0，就消费一个库存，添加消费者，最后释放锁，结束循环
• 引入了锁超时机制，即使当前线程出现异常，未成功释放锁，也不会让当前业务永远停摆
• 抢锁的过程也为在超时时限内循环抢锁

RedLock

https://www.jianshu.com/p/7e47a4503b87
https://redis.io/topics/distlock

1. Redlock不是针对秒杀场景而研发的，redlock实现严格的分布式悲观锁。

因为在秒杀业务场景下，即使ClientA和ClientB同时拥有了锁，即使两个人都做扣减，大部分的情况下也不会出岔子，只有在库存只有1的时候，ClientA 和ClientB同时Double Check库存为1，同时进行扣减，最终会有一个Client会让库存为 -1的。其它业务场景下，比如库存充足时，即使有多个节点同时获取到锁，也不会超卖。实际上为了预防这种极端情况，可以添加第三次check即可，没必要在秒杀时引入Redlock。
而且秒杀的业务场景下，乐观锁的性能和安全性都是更好的。不太确认，乐观锁在集群环境下，会不会因为重新选举导致扣减的丢失。需要研究Redis的一致性算法。

2. Redlock的代价是引入了新的jar包，额外引入至少2个MasterNode（2N+1)

3. Redlock解决的问题：Redis集群环境下，主从数据的同步是异步的，Master宕机时如果锁信息未同步的话，slave成为new master时，锁会丢失（概率有点低）

4. Redlock只是提高了分布式锁系统的容错性，但是如果过半节点都宕机的话，整个功能仍然不可用。

RedLock的三大特性:安全性、不会死锁（程序异常、集群网络分区）、具备一定的容错性

1. Safety property: Mutual exclusion. At any given moment, only one client can hold a lock.
2. Liveness property A: Deadlock free. Eventually it is always possible to acquire a lock, even if the client that locked a resource crashes or gets partitioned.
3. Liveness property B: Fault tolerance. As long as the majority of Redis nodes are up, clients are able to acquire and release locks

极端情况，会导致ClientA 和ClientB同时拥有锁

1. Client A acquires the lock in the master.
2. The master crashes before the write to the key is transmitted to the slave.
3. The slave gets promoted to master.
4. Client B acquires the lock to the same resource A already holds a lock for. SAFETY VIOLATION!

Redlock算法：（3个Master节点情况,只有在规定时间里，超过2个节点加锁成功，才算成功争抢到锁)
引入的参数变量：锁过期时间、响应超时时间

1. 先获取currentTime
2. 挨个尝试获取锁（悲观锁），如果在响应时间内抢锁失败，则认定该节点抢锁失败，最终如果过半节点加锁成功，就是加锁成功
3. 如果抢锁失败，则会在成功获得锁的Master上释放锁

该算法提升了系统的容错性，如果3个Master的环境，挂了一个Master，其它两个Master正常，那么Client也无法重复获取锁。
而且真正工作的Master可以是一个集群。例如：集群A是工作集群（Node1（masterA) Node2 Node3）， Master B ， MasterC，这种模式下，既可以保证工作集群的高可用，也可以保证不会出现极端情况下的双锁的问题。

Redisson

具体的使用细节，查看飞神的博客
https://www.jianshu.com/p/f302aa345ca8

Redis官方封装了一套基于悲观锁策略的锁框架。
非常灵活：分别支持单Master、哨兵模式、Cluster模式