一、watch
在限量秒杀抢购的场景，一定会遇到抢购成功数超过限量的问题和高并发的情况影响系统性能
1、虽然能用数据库的锁避免，超过限量的问题。但是在大并发的情况下，大大影响数据库性能
2、为了避免并发操作数据库，我们可以使用队列来限制，但是并发量会让队列内存瞬间升高
3、我们又可以用悲观锁来实现，但是这样会造成用户等待，响应慢体验不好
利用Watch实现Redis乐观锁
乐观锁基于CAS（Compare And Swap）思想（比较并替换），是不具有互斥性，不会产生锁等待而消耗资源，但是需要反复的重试，但也是因为重试的机制，能比较快的响应。因此我们可以利用redis来实现乐观锁。具体思路如下：
1、利用redis的watch功能，监控这个redisKey的状态值
2、获取redisKey的值
3、创建redis事务
4、给这个key的值+1
5、然后去执行这个事务，如果key的值被修改过则回滚，key不加1
Redis乐观锁实现秒杀
通过watch去判断指定键值在本次事务中是否有被更改过，有更改的话本次事务就失效。以下代码循环1000次，在拥有20个线程的线程池中执行秒杀代码。当有线程对键值进行了更改后续的线程的更改就会无效，只有等待该线程操作完毕后，后续的线程才再进行有效的操作。这样就保证了每次只有一个线程能操作，也就是实现了锁的效果。但是可能存在一个问题，也就是后续线程在第一个线程执行完成之前都结束了，这样秒杀就只秒杀了一个。
public class Second {
public static void main(String[] arg) {
String redisKey = "lock";
ExecutorService executorService = Executors.newFixedThreadPool(20);
try {
Jedis jedis = new Jedis("127.0.0.1", 6378);
// 初始值
jedis.set(redisKey, "0");
jedis.close();
} catch (Exception e) {
e.printStackTrace();
}
for (int i = 0; i < 1000; i++) {
executorService.execute(() -> {
Jedis jedis1 = new Jedis("127.0.0.1", 6378);
try {
jedis1.watch(redisKey);
String redisValue = jedis1.get(redisKey);
int valInteger = Integer.valueOf(redisValue);
String userInfo = UUID.randomUUID().toString();
// 没有秒完
if (valInteger < 20) {
Transaction tx = jedis1.multi();
tx.incr(redisKey);
List list = tx.exec();
// 秒成功 失败返回空list而不是空
if (list != null && list.size() > 0) {
System.out.println("用户：" + userInfo + "，秒杀成功！当前成功人数：" + (valInteger + 1));
}
// 版本变化，被别人抢了。
else {
System.out.println("用户：" + userInfo + "，秒杀失败");
}
}
// 秒完了
else {
System.out.println("已经有20人秒杀成功，秒杀结束");
}
} catch (Exception e) {
e.printStackTrace();
} finally {
jedis1.close();
}
});
}
executorService.shutdown();
}
}
二、setnx
实现原理
共享资源互斥
共享资源串行化
单应用中使用锁：（单进程多线程）
synchronized、ReentrantLock
分布式应用中使用锁：（多进程多线程）
分布式锁是控制分布式系统之间同步访问共享资源的一种方式。
利用Redis的单线程特性对共享资源进行串行化处理
实现方式
获取锁
方式1（使用set命令实现）–推荐
/**
* 使用redis的set命令实现获取分布式锁
* @param lockKey 可以就是锁
* @param requestId 请求ID，保证同一性 uuid+threadID
* @param expireTime 过期时间，避免死锁
* @return
*/
public boolean getLock(String lockKey,String requestId,int expireTime) {
//NX:保证互斥性
// hset 原子性操作 只要lockKey有效 则说明有进程在使用分布式锁
String result = jedis.set(lockKey, requestId, "NX", "EX", expireTime);
if("OK".equals(result)) {
return true;
}
return false;
}
方式2（使用setnx命令实现） – 并发会产生问题
public boolean getLock(String lockKey,String requestId,int expireTime) {
Long result = jedis.setnx(lockKey, requestId);
if(result == 1) {
//成功设置 进程down 永久有效 别的进程就无法获得锁
jedis.expire(lockKey, expireTime);
return true;
}
return false;
}
释放锁
方式1（del命令实现） – 并发
/**
* 释放分布式锁
* @param lockKey
* @param requestId
*/
public static void releaseLock(String lockKey,String requestId) {
if (requestId.equals(jedis.get(lockKey))) {
jedis.del(lockKey);
}
}
问题在于如果调用jedis.del()方法的时候，这把锁已经不属于当前客户端的时候会解除他人加的锁。那么是否真的有这种场景？答案是肯定的，比如客户端A加锁，一段时间之后客户端A解锁，在执行jedis.del()之前，锁突然过期了，此时客户端B尝试加锁成功，然后客户端A再执行del()方法，则将客户端B的锁给解除了。
方式2（redis+lua脚本实现）–推荐
public static boolean releaseLock(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 (result.equals(1L)) {
return true;
}
return false;
}
三、存在问题
单机
无法保证高可用
主–从
无法保证数据的强一致性，在主机宕机时会造成锁的重复获得。
无法续租
超过expireTime后，不能继续使用
四、本质分析
CAP模型分析
在分布式环境下不可能满足三者共存，只能满足其中的两者共存，在分布式下P不能舍弃(舍弃P就是单机了)。
所以只能是CP（强一致性模型）和AP(高可用模型)。
分布式锁是CP模型，Redis集群是AP模型。 (base)
Redis集群不能保证数据的随时一致性，只能保证数据的最终一致性。
为什么还可以用Redis实现分布式锁？
与业务有关，当业务不需要数据强一致性时，比如：社交场景，就可以使用Redis实现分布式锁。
当业务必须要数据的强一致性，即不允许重复获得锁，比如金融场景（重复下单，重复转账）就不要使
用。可以使用CP模型实现，比如：zookeeper和etcd。
五、Redission分布式锁的使用
Redisson是架设在Redis基础上的一个Java驻内存数据网格（In-Memory Data Grid）。
Redisson在基于NIO的Netty框架上，生产环境使用分布式锁。
Redisson分布式锁的实现原理
六、Zookeeper分布式锁的对比
基于Redis的set实现分布式锁
基于zookeeper临时节点的分布式锁
基于etcd实现
三者的对比，如下表