文章目录
- 一、redis客户端实现
- 应用
- 1.利用set nx命令实现分布式锁
- 2.利用分布式锁命令 setnx
- 问题
- 1.为什么不直接调用jedis.del(key)方法而采用redis+lua实现？
- 2.上述两种方式存在的问题？
- 3.根本原因分析
- 二、分布式场景Redission分布式锁的使用
- 1.分布式锁的特性
- 2.分布式锁的应用场景
- 三、zookeeper分布式锁和redis分布式的区别
- 1.对于 Redis 的分布式锁而言，它有以下缺点：
- 2.对于 ZK 分布式锁而言:
- 3.使用建议
- 4.参数对比
一、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.上述两种方式存在的问题？
- 单机，无法保证高可用
- 主从，无法保证数据强一致性，会去从库重复获得锁
- 无法续租，超过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+threadId
mylock.lock(3, SECONDS);
//加锁成功
return true;
}
//锁的释放
public static void release(String lockName) {
//必须是和加锁时的同一个key
String 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.分布式锁的特性
- 互斥性：任意时刻保持只能有一个客户端获得锁
- 同一性：锁只能被同一个客户端删除，不能被其他客户端删除，同上jedis.setnx(key)不能利用jedis.del(key)删除
- 可重入性：持有该锁的客户端可重复获得锁
- 容错性：锁对象由于服务挂掉，会自动释放锁，防止死锁
2.分布式锁的应用场景
- 抢红包、秒杀下单场景等，由于红包、库存的数量是确定的，如果此时同时有多个用户抢红包、下订单，此时如果不利用分布式锁处理的话，那么会出现并发问题。
- 详细应用场景可参考： 文章
三、zookeeper分布式锁和redis分布式的区别
彻底讲清楚ZooKeeper分布式锁的实现原理
zk分布式锁的使用案例
1.对于 Redis 的分布式锁而言，它有以下缺点：
- 它获取锁的方式简单粗暴，获取不到锁直接不断尝试获取锁，比较消耗性能。
- 另外来说的话，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，不适合做高并发的分布式锁。
数据库实现分布式锁，性能太差。
具体采用何种，还需要根据自身业务场景去选择 ！！！
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
