一、redis客户端实现

应用

1.利用set nx命令实现分布式锁

    Jedis jedis = new Jedis("127.0.0.1", 6309);public boolean getLock(String lockKey, String requestId, int expireTime) {//NX:保证互斥性//hset 原子性操作 只要lockKey有效 则说明有进程在使用分布式锁// key:lockKey  value:requestId NX:仅在键不存在时设置键 EX:设置指定的到期时间(以秒为单位)String result = jedis.set(lockKey, requestId, "NX", "EX", expireTime);if ("OK".equals(result)) {return true;}return false;}/*** 释放分布式锁* @param lockKey* @param requestId*/public void releaseLock(String lockKey,String requestId) {if (requestId.equals(jedis.get(lockKey))) {jedis.del(lockKey);}}

2.利用分布式锁命令 setnx

    public static boolean getLock2(Jedis jedis, String lockKey, String requestId, int expireTime) {Long result = jedis.setnx(lockKey, requestId);//成功设置 进程down 永久有效 别的进程就无法获得锁if(result == 1) {jedis.expire(lockKey, expireTime);return true;}return false;}public static boolean releaseLock2(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 (result.equals(1L)) {return true;}return false;}public static void main(String[] args) {String redisLock = "my_lock";ExecutorService executorService = Executors.newFixedThreadPool(10);for (int i = 0; i <100; i++){executorService.execute(() -> {Jedis jedis = new Jedis("127.0.0.1", 6379);UUID uuid = UUID.randomUUID();System.out.println(uuid.toString() + "用户进来");boolean isLock = getLock2(jedis, redisLock, uuid.toString(), 30000);if (isLock){System.out.println(uuid.toString() + "用户尝试获得锁成功!");releaseLock2(jedis, redisLock, uuid.toString());System.out.println(uuid.toString() + "用户释放锁");}else{System.out.println(uuid.toString() + "用户获得锁失败");}});}}

问题

1.为什么不直接调用jedis.del(key)方法而采用redis+lua实现？

由于jedis.del(key)方法是删除当前key不会区别当前是哪个客户端，而采用redis+lua方式只有当前获得锁的客户端才有资格删除。例如，线程A获得分布式锁，线程B调用jedis.del(key)方法会把线程A的锁删除掉。

2.上述两种方式存在的问题？

1. 单机，无法保证高可用
2. 主从，无法保证数据强一致性，会去从库重复获得锁
   
3. 无法续租，超过expireTime后，不能继续使用

3.根本原因分析

CAP(Consistent一致性、Available可用性、Partition分区)原则，三者只能选其二，因此在分布式场景下p不能舍弃，那么只能是AP、CP原则。

二、分布式场景Redission分布式锁的使用

Redisson是架设在Redis基础上的一个java驻内存数据网格。
Redission在基于NIO的Netty框架上，生成环境使用分布式锁。

数据网格：是将空间上不均匀分布的数据，按一定方法（如滑动平均法、克里格法或其他适当的数值推算方法）归算成规则网格中的代表值（趋势值）的过程

Redis集群至少需要3个master节点，所以现在总共有6个节点，就只能是1master对应1slave这种方式，1master-2slave，redis集群需要9个节点，以此类推。

配置代码：

package com.learn.cache;import org.redisson.Redisson;
import org.redisson.config.Config;public class RedissonManager {private static Config config = new Config();private static Redisson redisson = null;static {config.useClusterServers()//集群状态扫描间隔时间，单位是毫秒.setScanInterval(2000).addNodeAddress("redis://127.0.0.1:7001").addNodeAddress("redis://127.0.0.1:7002").addNodeAddress("redis://127.0.0.1:7003").addNodeAddress("redis://127.0.0.1:7004").addNodeAddress("redis://127.0.0.1:7005").addNodeAddress("redis://127.0.0.1:7006");redisson = (Redisson) Redisson.create(config);}public static Redisson getRedisson() {return redisson;}}

使用demo：

package com.learn.cache;import org.redisson.Redisson;
import org.redisson.api.RLock;import java.util.UUID;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;import static java.util.concurrent.TimeUnit.SECONDS;public class DistributedRedisLock {private static final String LOCK_TITLE = "redisLock_";//从配置类中获取redisson对象private static Redisson redisson = RedissonManager.getRedisson();//加锁public static boolean acquire(String lockName) {//声明key对象String key = LOCK_TITLE + lockName;//获取锁对象RLock mylock = redisson.getLock(key);//加锁，并且设置锁过期时间3秒，防止死锁的产生 uuid+threadIdmylock.lock(3, SECONDS);//加锁成功return true;}//锁的释放public static void release(String lockName) {//必须是和加锁时的同一个keyString key = LOCK_TITLE + lockName;//获取所对象RLock mylock = redisson.getLock(key);//释放锁（解锁）mylock.unlock();}public static void main(String[] args) {String key = "lock001";ExecutorService executorService = Executors.newFixedThreadPool(20);for (int i = 0; i < 100; i++){executorService.execute(() -> {//加锁boolean acquire = acquire(key);String uuid = UUID.randomUUID().toString();if (acquire){System.out.println(uuid + "用户获得锁成功");release(key);System.out.println(uuid + "用户释放锁");}else{System.out.println(uuid + "用户获得锁失败");}});}}}

1.分布式锁的特性

1. 互斥性：任意时刻保持只能有一个客户端获得锁
2. 同一性：锁只能被同一个客户端删除，不能被其他客户端删除，同上jedis.setnx(key)不能利用jedis.del(key)删除
3. 可重入性：持有该锁的客户端可重复获得锁
4. 容错性：锁对象由于服务挂掉，会自动释放锁，防止死锁

2.分布式锁的应用场景

1. 抢红包、秒杀下单场景等，由于红包、库存的数量是确定的，如果此时同时有多个用户抢红包、下订单，此时如果不利用分布式锁处理的话，那么会出现并发问题。
2. 详细应用场景可参考： 文章

三、zookeeper分布式锁和redis分布式的区别

彻底讲清楚ZooKeeper分布式锁的实现原理

zk分布式锁的使用案例

1.对于 Redis 的分布式锁而言，它有以下缺点：

1. 它获取锁的方式简单粗暴，获取不到锁直接不断尝试获取锁，比较消耗性能。
2. 另外来说的话，Redis的设计定位决定了它的数据并不是强一致性的，在某些极端情况下，可能会出现问题。锁的模型不够健壮。 即便使用 Redlock算法来实现，在某些复杂场景下，也无法保证其实现 100% 没有问题，关于 Redlock 的讨论可以看 How to do distributed locking。

但是另一方面使用 Redis 实现分布式锁在很多企业中非常常见，而且大部分情况下都不会遇到所谓的“极端复杂场景”。

所以使用 Redis 作为分布式锁也不失为一种好的方案，最重要的一点是 Redis 的性能很高，可以支撑高并发的获取、释放锁操作。

2.对于 ZK 分布式锁而言:

ZK 天生设计定位就是分布式协调，强一致性。锁的模型健壮、简单易用、适合做分布式锁。
如果获取不到锁，只需要添加一个监听器就可以了，不用一直轮询，性能消耗较小。

但是 ZK 也有其缺点：如果有较多的客户端频繁的申请加锁、释放锁，对于 ZK 集群的压力会比较大。

3.使用建议

就个人而言的话，我比较推崇 ZK 实现的锁：因为 Redis 是有可能存在隐患的，可能会导致数据不对的情况。但是，怎么选用要看具体在公司的场景了。

如果有 ZK 集群条件，优先选用 ZK 实现，但是如果说公司里面只有 Redis 集群，没有条件搭建 ZK 集群。

那么其实用 Redis 来实现也可以，另外还可能是系统设计者考虑到了系统已经有 Redis，但是又不希望再次引入一些外部依赖的情况下，可以选用 Redis。这个是要系统设计者基于架构来考虑了。

4.参数对比

一个ap模型不适合强一致的场景 一个cp虽然适合，但是每次节点交互携带的数据会限制节点的数量。

zk写都在leader，不适合做高并发的分布式锁。

数据库实现分布式锁，性能太差。

具体采用何种，还需要根据自身业务场景去选择 ！！！