【分布式锁02 Redisson配置和使用】2大缺陷：主挂未同步，性能慢。双写不一致：延迟双删，内存队列，超时时间。读写锁源码。多级缓存：map redis 尝试上锁 在走缓存 读写锁。

最新推荐文章于 2024-09-03 04:09:08 发布
最新推荐文章于 2024-09-03 04:09:08 发布
阅读量930 收藏 1
点赞数 1
分类专栏： redis 文章标签： redis 缓存 分布式 读写不一致 读写锁
原文链接：https://www.bilibili.com/video/BV1xA411G7wY?p=4&spm_id_from=pageDriver&vd_source=b63e9afd510deaf9d2a1b680368b9935
版权
  • 教程网址：

https://www.bilibili.com/video/BV1xA411G7wY?p=4&spm_id_from=pageDriver&vd_source=b63e9afd510deaf9d2a1b680368b9935

1. Redisson配置和使用

redis + son redis的儿子

  • 导入pom包
        <dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson</artifactId>
            <version>3.13.4</version>
        </dependency>
  • 配置
单机 集群 主从 复制 哨兵
@Configuration
public class RedissonConfig {

    @Bean
    public Redisson redisson() {
        Config config = new Config();

        config.useSingleServer().setAddress("redis://localhost:6379").setDatabase(0);

        return (Redisson) Redisson.create(config);
    }
}


        //集群
        config.useClusterServers();
        //哨兵
        config.useSentinelServers();
        //主从
        config.useMasterSlaveServers();
        //复制
        config.useReplicatedServers();
  • 使用
    @Autowired
    private Redisson redisson;
    
    //controller
	
	//封装了 如下
	//redisTemplate.opsForValue().setIfAbsent("lock", uuid, 3, TimeUnit.SECONDS);
    RLock lock = redisson.getLock(REDIS_LOCK);
        lock.lock();
        lock.unlock();

案例 RLock 和 Redisson

        RLock lock = redisson.getLock(REDIS_LOCK);
        lock.lock();
        
        try {
            String result = redis.opsForValue().get("goods:001");
            //如果为null，就为0，否则 转成 int
            int goodsNumber = result == null ? 0 : Integer.parseInt(result);

            if (goodsNumber > 0) {
                //售卖了一个，还是这么多
                int realNumber = goodsNumber - 1;

                redis.opsForValue().set("goods:001", String.valueOf(realNumber));

                String r = "成功买到商品，还剩：" + realNumber + "\t 服务端口为：" + serverPort;
                System.out.println(r);

                return r;
            } else {
                System.out.println("意外情况，已经售空等" + serverPort);
            }
            return "fail";
        } finally {
            //如果是被锁定的
            if (lock.isLocked()) {
                //如果是 当前线程持有的话
                if (lock.isHeldByCurrentThread()) {
                    //才进行解锁
                    lock.unlock();
                }
            }
        }

2. 两大缺点：主未同步挂，排队性能差

  • 拿到 主节点的锁，主节点 还没同步到 子节点，就挂了。
  • 分布式锁，把 线程进行排队，性能差。

问题1 主节点挂了未同步

  1. 使用 zookeeper，AP的，强一致性，最低半数以上 都写成功了，才加锁成功
    1. zookeeper也是 key value，也能实现分布式锁。
    2. 是树形结构的目录。主节点叫 lead，从节点叫 follow
    3. C一致性，A可用性，P是分区容错性。
    4. lead挂了，一定是 同步成功key的节点，成为 新的 lead
  2. 如果能容忍，这种情况，用 redis
Redlock 解决 主节点挂了

  • 还没同步到 子节点

  • 对应 类为：RedissonLock

  • 超过半数redis节点加锁成功才算加锁成功

    • 对等的 3个 redis节点，半数以上 setNx加锁成功了，才是成功。

  • 旧版本是这样，使用 3个 客户端接口。

  • 新版本的构造为：public RedissonLock(CommandAsyncExecutor commandExecutor, String name)

        //创建配置
		Config config1 = new Config();
		//单机 服务端
        config1.useSingleServer().setAddress("redis://127.0.0.1:6379");
		//创建 RedissonClient
        RedissonClient redissonClient1 = Redisson.create(config1);
		//获取一个 锁
        RLock lock1 = redissonClient1.getLock("LOCK_KEY");
		
		//多个锁 组成 红锁 RedissonReadLock
        RedissonReadLock redLock = new RedissonReadLock(lock1, lock2, lock3);

        boolean isLock = false;
        try {
            //尝试 加锁
            isLock = redLock.tryLock(500, 1000, TimeUnit.MILLISECONDS);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }finally {
            redLock.unlock();
        }

问题2 高并发和线程安全

  • ConcurrentHashMap 分段锁
  • 200 个产品，段位1 20个，段位2 20个，可以分10个段位
    • 分10段，并发 提升10倍
    • 段位 不够减去（一下买好多个），合并 其他段位。

3. Redis 缓存和数据库 双写不一致

案例1：值还未写入redis，值已经被改变

线程1：

写数据库stock=10
更新缓存stock=10，这里还未执行，被线程2 插队，插入完毕。

  • 更新缓存stock=10 开始执行，造成 不一致。

线程2：

写数据库stock=6
更新缓存stock=6

案例2：部分线程在 数据库更新后 才更新旧值

更新数据库，删除缓存。

查询数据库，加载缓存。

线程1：

  • 写数据库stock=10
    更新缓存stock=10

线程3：

  • 查缓存 空

  • 查数据库 stock = 10

  • 更新缓存 （被 线程2 抢先执行完毕），更新为 10

线程2：

  • 写数据库stock=20
  • 删除缓存

线程3：

  • 此时才更新缓存，更新为 10

解决

1. 延迟双删 无用

1、延迟双删：删除缓存后，睡X毫秒，再去删除

  • 如果 更新缓存 （被 线程2 抢先执行完毕），更新为 10。在这之后 执行，
  • 依然 无法解决
  • 并且 写的吞吐量 会降低。
2. 内存队列 无用

内存队列：所有对 redis的操作 放入 内存队列

  • 没用，降低 吞吐量
3. 加分布式锁
  • 加 分布式锁，
  • 写数据库stock=10 删除缓存，这样的操作 加锁。
配置 Redisson
        <dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson</artifactId>
            <version>3.6.5</version>
        </dependency>

@Configuration
public class RedissonConfig {

    @Bean
    public Redisson redisson() {
        Config config = new Config();
        config.useSingleServer().setAddress("redis://localhost:6379").setDatabase(0);
        return (Redisson) Redisson.create(config);
    }
}
3.1 加读写锁 RReadWriteLock
        String productId = "1";
        //使用 读写锁。
        RReadWriteLock readWriteLock = redisson.getReadWriteLock(REDIS_LOCK + productId);
        
		//读锁
		RLock rLock = readWriteLock.readLock();
        rLock.lock();
        rLock.unlock();//这是 读的情况。

        //写锁
        RLock wLock = readWriteLock.writeLock();
3.2 加DCL 双重锁
  • 是 JVM 加锁，部署多个项目的话，没用。
//检查缓存，如果存在，直接返回

synchronized(this){
	//先获取缓存，如果有 直接返回
	
	//查询数据
	
	//放入到缓存
}
4. 设置超时时间

设置 Redis 的超时时间

  • 商品 详情也 的库存，不是真实的 库存。

4. 分布式读写锁源码

  • 如果 都是 .readLock() 过来，第一 设置 setNx key，标志为 read模式，第二个会判断，是 read模式，

    • 当前是 读锁，就 +1
    • 锁释放 -1，知道 减到0 为止，锁删除。

  • 如果 是 readLock() 已经执行了，模式为 read 模式，

    • 一个 .writeLock() 过来，也会set 但是会失败，进入自旋。

  • 如果先执行 writeLock()，模式设置为了 write，其他的 读锁 和 写锁，也会进入 自旋。

读锁

源码
@Override
    <T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
        internalLockLeaseTime = unit.toMillis(leaseTime);

        return commandExecutor.evalWriteAsync(
            getName(), 
            LongCodec.INSTANCE, command,
            "local mode = redis.call('hget', KEYS[1], 'mode'); ",     
            Arrays.<Object>asList(getName(), 
            getReadWriteTimeoutNamePrefix(threadId)), 
            
            internalLockLeaseTime, 
            getLockName(threadId), 
            getWriteLockName(threadId));
    }
redis里键值对说明
redis的键为：atguiguLock101

key为：mode，value为：read

key为：fb7c6838-6a88-4117-a660-088493b67489:63，value为：1

redis的键为：{atguiguLock101}:fb7c6838-6a88-4117-a660-088493b67489:63:rwlock_timeout:1
redis的值为：1
lua脚本说明
					"local mode = redis.call('hget', KEYS[1], 'mode'); " +
                                "if (mode == false) then " +

					//keys[1]为前缀xxx+101 商品ID。如：atguiguLock101
					//使用hash 设置这个 redis键，hash的key为mode，value为 read
                     "redis.call('hset', KEYS[1], 'mode', 'read'); " +

					//进行加锁，加锁的 hash key为如下 ，value为1
					//fb7c6838-6a88-4117-a660-088493b67489:69:write
                    "redis.call('hset', KEYS[1], ARGV[2], 1); " +

					//设置这个：{atguiguLock101}:fb7c6838:63:rwlock_timeout:1 值为1
                                  "redis.call('set', KEYS[2] .. ':1', 1); " +
                                  "redis.call('pexpire', KEYS[2] .. ':1', ARGV[1]); " +
                                  "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                                  "return nil; " +
                                "end; " +

	//如果模式为 读锁， or mode为写锁，并且 这个hash 存在
	//如果为 读锁 或者 为同一个写锁
    "if (mode == 'read') or
(mode == 'write' and redis.call('hexists', KEYS[1], ARGV[3]) == 1) then " +

		//然后 增加1
        "local ind = redis.call('hincrby', KEYS[1], ARGV[2], 1); " +

								  //这个redis 设置为 1
                                  "local key = KEYS[2] .. ':' .. ind;" +
                                  "redis.call('set', key, 1); " +
                                  "redis.call('pexpire', key, ARGV[1]); " +
                                  "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                                  "return nil; " +
                                "end;" +
                                "return redis.call('pttl', KEYS[1]);"

写锁的

@Override
    <T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
        internalLockLeaseTime = unit.toMillis(leaseTime);

        return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,
                            "local mode = redis.call('hget', KEYS[1], 'mode'); " +
                            "if (mode == false) then " +
                                  "redis.call('hset', KEYS[1], 'mode', 'write'); " +
                                  "redis.call('hset', KEYS[1], ARGV[2], 1); " +
                                  "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                                  "return nil; " +
                              "end; " +
                              "if (mode == 'write') then " +
                                  "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
                                      "redis.call('hincrby', KEYS[1], ARGV[2], 1); " + 
                                      "local currentExpire = redis.call('pttl', KEYS[1]); " +
                                      "redis.call('pexpire', KEYS[1], currentExpire + ARGV[1]); " +
                                      "return nil; " +
                                  "end; " +
                                "end;" +
                                "return redis.call('pttl', KEYS[1]);",
                        Arrays.<Object>asList(getName()), 
                        internalLockLeaseTime, getLockName(threadId));
    }

5. 多级缓存 和 只有查询：tryLock使用场景

  • 查询逻辑，第一次执行 放入redis，有了 缓存后，将 走不到 tryLock锁的逻辑里。
        //判断缓存是否存在
        RLock lock = redisson.getLock(REDIS_LOCK + productId);
		//lock.Lock() 如果不能容忍，偶尔大量的请求，打到数据库。

		//锁只等 3秒。抢锁失败，返回false，执行 下面的逻辑
        boolean b = lock.tryLock(3, TimeUnit.SECONDS);

		//再次判断

		//DCL 双重锁的逻辑
		//检查缓存，如果存在，直接返回

        synchronized(this){//换成 分布式锁
            //先获取缓存，如果有 直接返回

            //查询数据

            //放入到缓存
        }

查询的方法总览 多级缓存

从cache中 获取缓存
    private Product getProductFromCache(String productCacheKey) {
        Product product = null;

        //先去 map中 ，查询，多级 缓存 。内存能抗 更高的并发。因为 redis 有一次 远程的开销。
        Product mapProduct = productMap.get(productCacheKey);
        if (mapProduct != null) {
            return mapProduct;
        }

        String productStr = redis.opsForValue().get(productCacheKey);

        if (!StringUtils.isEmpty(productStr)) {
            if ("".equals(productCacheKey)) {
                product = new Product();
            }
            product = new Product();//productStr 转为 Product
        }
        return null;
    }
ID获产品：Map redis 获取锁 尝试上锁 在走缓存 读写锁
public Product get(Long productId) throws Exception {
        Product product = null;

        String productCacheKey = Product_cache + productId;
        //一般会在前面 + JVM 内存级别的 缓存。

        //先从缓存中 获取
        product = getProductFromCache(productCacheKey);
        if (product != null) {
            return product;
        }

        RLock lock = redisson.getLock("LOCK_PRODUCT" + product);
        //允许 短时间 大量请求 进入，使用 tryLock 增加性能
        lock.tryLock(3, TimeUnit.SECONDS);

        try {
            //再次 从缓冲中 读取
            product = getProductFromCache(productCacheKey);
            if (product != null) {
                return product;
            }

            //获取 读写锁
            RReadWriteLock readWriteLock = redisson.getReadWriteLock("LOCK_PRODUCT" + product);
            RLock rLock = readWriteLock.readLock();
            rLock.lock();//这里使用 读锁，上锁

            try {
                //查询数据库
                product = new Product();
                if (product != null) {
                    //10分钟 超时，应该转为 json
                    redis.opsForValue().set(productCacheKey, product.toString(), 10, TimeUnit.MINUTES);

                    //map中也 放一份
                    productMap.put(productCacheKey, product);
                } else {
                    //为null，设置为空
                    redis.opsForValue().set(productCacheKey, new Product().toString(), 10, TimeUnit.MINUTES);
                }
            } finally {
                rLock.unlock();
            }
        } finally {
            lock.unlock();
        }
        return null;
    }

一线互联网 技术栈

分布式架构
微服务架构
源码分析
并发编程
高并发实战
性能优化
数据结构与算法
工程化协作
项目经验

Redis底层

字符串(String)

  • 整型(int)
    embstr编码的简单动态字符串
    raw编码的简单动态字符串

列表(List)

  • 双端链表(Linkedlist)
    压缩表(Ziplist)

哈希(Hash)

  • 哈希表(Hashtable)
    压缩表(Ziplist)

集合(Set)

  • 整型数组集合(lintset)
    哈希表(Hashtable)

有序集合(Zset)

  • 压缩表(ziplisi)
    跳跃表(Skiplist)

Bitmap 位图

GEO 地图

Hyperloglog是用来做基数统计的

其可以非常省内存的去统计各种计数，比如注册ip数、每日访问IP数、页面实时UV（PV肯定字符串就搞定了）、在线用户数

pfadd language "java" #添加成功
integer) 1
pfadd language "python"

pfcount language
integer) 2

pfadd language "java"  #再次添加失败
integer) 0
  • List item
天海华兮
关注
专栏目录
Java开发面试题精选：分布式锁相关一篇全搞定
凡夫编程
05-17 1107
面试路上，分布式锁始终是绕不开的坎？别怕，这篇精心准备的文章正是您的通关秘籍！这篇文章聚焦面试官最青睐的提问点：从分布式锁基础概念到其实现机理，再到它在多场景下的应用智慧；深入剖析性能优化窍门，以及确保一致性和可用性的核心策略。更有过来人的面试经验与实战心得，让您在面对各种难题时胸有成竹。这不仅是一篇文章，更是您提升技术深度、拓宽视野的加速器。准备好了吗？启程吧，让每一次面试都成为展现您专业实力的舞台！
Redis 作者 Antirez 讲如何实现分布式锁？Redis 实现分布式锁天然的缺陷分析&Redis分布式锁的正确使用姿势！...
AI天才研究院
11-11 8556
Redis分布式锁基本原理采用 redis 实现分布式锁，主要是利用其单线程命令执行的特性，一般是 setnx， 只会有一个线程会执行成功，也就是只有一个线程能成功获取锁；看着很完美。然而——看看可能有什么问题？一般生产环境为了可用性，redis 会部署 master-slave + sentinel 的结构， 如：master 提供服务、slave standby 作为备份节点不提供服务， ma...
用Redis实现延迟队列，耗时几天研究了两种方案，发现并不简单
z1ztai的博客
03-20 1354
这样，一旦时间来到了上面说的最早到过期时间任务的到期时间戳，redisson_delay_queue_timeout:SANYOU中上面说的最早到过期时间的任务已经到期了，客户端的延迟任务也同时到期，于是开始执行lua脚本操作，及时将到了延迟时间的任务放到目标队列中。至于后台的定时清理的任务什么时候能扫到，这个没有固定时间，可能一到过期时间就被扫到，也可能等一定时间才会被扫到，这就可能会造成了客户端从发布到监听到的消息时间差会大于等于过期时间，从而造成一定时间消息的延迟，这就着实有点坑了。
Redis分布式锁有哪些缺点？如何解决？
weixin_71921932的博客
04-19 4332
因为每个客户端在设置锁过期时间时可能出现网络延迟等原因，有可能出现某个客户端加锁之后，由于它异常退出或其他原因导致业务逻辑执行完之后没有及时释放锁，就会导致死锁问题。，每个请求都会依次被处理，当高并发请求增加时，锁的抢占时间会变长，从而导致。：如果锁的粒度过大，即锁定的资源过多，那么锁的抢占时间就会变长。如果加锁的时间过长，就会导致锁的时效性问题，影响系统的响应速度。：通过优化业务逻辑，减少执行的操作，可以减少锁的抢占时间。：将锁粒度减小，只锁定必要的资源，可以减少锁的抢占时间。
翻译 | Redis Redisson 指南
最新发布
高行行
09-03 421
在本文中，我们将探讨它的一些功能，并演示它如何帮助构建分布式业务应用程序。
Redis 分布式锁有什么缺陷？
sanmansan的博客
01-12 866
Redis 分布式锁有什么缺陷？
redis---分布式锁存在的问题及解决方案（Redisson）
热门推荐
池海
04-01 1万+
系列文章目录 提示：这里可以添加系列文章的所有文章的目录，目录需要自己手动添加 例如：第一章 Python 机器学习入门之pandas的使用 提示：写完文章后，目录可以自动生成，如何生成可参考右边的帮助文档 文章目录系列文章目录前言一、pandas是什么？二、使用步骤1.setNx2.set NX NP3.锁超时问题3.1过期时间如何设置3.2锁的续签4.增加锁的可重入性2.读入数据总结 前言 提示：这里可以添加本文要记录的大概内容： 例如：随着人工智能的不断发展，机器学习这门技术也越来越重要，很多人
redisson client 介绍及优缺点
z69183787的专栏
03-10 8600
由于redisson是2014年1月份才发布的开源项目，对于很多使用redis的用户来说，还是个新东西，关于redisson的文档除了github上边有简单介绍之外，其它网站还没有，所以我基于对源码的理解还有github介绍，简单介绍下redisson。   　　redisson实现了分布式和可扩展的java数据结构，支持的数据结构有：List, Set, Map, Queue, So
Redis分布式锁、Redisson原理
qq_44027353的博客
03-25 713
方法加锁，但是只会有一个线程加锁成功，如果线程1加锁成功了那么就会另外开启一个线程，默认每隔10s去检查锁是否还存在，如果还存在则重新设置锁过期时间为30秒。如果加锁成功是返回null，如果加锁没成功是返回的锁过期时间，所以这里接下来就是一个while(true)死循环，不断尝试获取锁。核心思想是首先等一段时间，延迟执行TimerTask类的run()方法，等待的时间是key过期时间的三分之一，默认是10s。方法没有加锁成功，那么返回的是这个锁的过期时间，那么接下来也就回到了加锁部分的第一张图中了。
Mysql学习总结（83）——常用的几种分布式锁：ZK分布式锁、Redis分布式锁、数据库分布式锁、基于JDK的分布式锁方案对比总结
科技D人生
01-18 463
一、基于数据库实现分布式锁 1.1、悲观锁 利用select … where … for update 排他锁。注意: 其他附加功能与实现一基本一致，这里需要注意的是“where name=lock ”，name字段必须要走索引，否则会锁表。有些情况下，比如表不大，mysql优化器会不走这个索引，导致锁表问题。 1.2、乐观锁 所谓乐观锁与前边最大区别在于基于CAS思想，是不具有互斥性，不会产生锁等待而消耗资源，操作过程中认为不存在并发冲突，只有update version失败后才能觉察到。我们的抢
redis 分布式锁有什么缺陷？
MRZHQ的博客
02-21 2422
例如，如果锁的过期时间是1秒钟，但是某个进程或线程在执行某个操作时需要1.5秒钟，那么在这个操作执行完成之前锁就会被自动释放。例如，如果对整个Redis实例进行加锁，那么所有需要对Redis进行读写操作的线程都会被阻塞，影响整个系统的并发性能。高可用问题：如果使用Redis单实例进行分布式锁的实现，那么一旦Redis实例出现故障，整个分布式锁系统将会失效。死锁风险：分布式锁在获取锁和释放锁之间可能存在异常情况，如获取锁后崩溃或释放锁时网络异常，这可能导致死锁的情况。
【分布式锁Redisson原理入门1】四大特征：互斥，防死锁，高性能，重入，看门狗机制，Redisson缺点 主节点宕机未同步。RedLock。
qq120631157的博客
04-06 911
【分布式锁Redisson原理入门1】四大特征：互斥，防死锁，高性能，重入，看门狗机制，Redisson缺点 主节点宕机未同步。RedLock。
浅谈一下Redis分布式锁存在的问题
huangliangbao2009的专栏
03-04 308
假设有这样一个场景，在一个购票软件上买一张票，但是此时剩余票数只有一张或几张，这个时候有几十个人都在同时使用这个软件购票。在不考虑任何影响下，正常的逻辑是首先判断当前是否还有剩余的票，如果有，那么就进行购买并扣减库存数，否则就会提示票数不足，购买失败。
分布式锁性能问题
weixin_38071106的博客
03-14 1997
原文：https://mp.weixin.qq.com/s?__biz=MzUzNjAxODg4MQ==&amp;mid=2247483993&amp;idx=1&amp;sn=3efbacbf3c3481b2d79a61a4b60ae733&amp;scene=21#wechat_redirect 线程并发问题和进程间并发问题都可以通过分布式锁解决，但是很大题小做。非常消耗资源。 分布式锁最...
聊聊redis分布式锁的8大坑
程序员高级码农的博客
03-11 1005
在分布式系统中，由于redis分布式锁相对于更简单和高效，成为了分布式锁的首选，被我们用到了很多实际业务场景当中。但不是说用了redis分布式锁，就可以高枕无忧了，如果没有用好或者用对，也会引来一些意想不到的问题。今天我们就一起聊聊redis分布式锁的一些坑，给有需要的朋友一个参考。
浅谈分布式锁：安全与性能的取舍之道
李兆龙的博客
07-24 1416
文章目录引言解决方案1. 关系型数据库作为锁2.1 Redis做分布式锁2.2 RedLock安全性争议存在的问题3. Zookeeper与Chubby3.1 Zookeeper3.2 Chubby总结参考 引言 我们知道在单机多线程情况下，如果要保证临界区同一时刻只有一个线程访问，我们的做法就是使得多个线程的临界区在CPU看来串行执行，那么如何做到如上操作呢？两个方法，一个是使用外部组件保证同步，常见的有自旋锁，互斥锁，条件变量，信号量等常见的工具，在一些语言内还支持其他比较有特色的工具，比如golang
【redis缓存】分布式锁的8大坑，一文带你了解其中解决方法
程序源日志的博客
12-02 780
在分布式系统中，由于redis分布式锁相对于更简单和高效，成为了分布式锁的首先，被用到了很多业务场景当中。apollo、nocos等的出现，让zookeeper的地位越来越低了。zookeeper分布式锁复杂度更高，想把它使用好并不容易。所以我们还是好好使用redis分布式锁吧。不是说用了redis分布式锁，就可以高枕无忧了，如果没有用好，也会引来一些意想不到的麻烦。今天我们重点聊聊redis分布式锁的一些坑，给有需要的朋友一个参考。
redisson的实现和优缺点
m0_63102097的博客
05-19 1352
是一个基于 Redis 的 Java 驻内存数据网格解决方案，提供了丰富的分布式数据结构和功能，能够有效地解决可重入、可重试、超时释放以及主从一致性等问题。
分布式锁选型方案，Redisson和zookeeper curator 做分布式锁的优缺点
sishenhzy的博客
05-16 2764
Redisson Redisson框架集成以后，可以指定一个keykey，通过lua脚本向redis加锁。 加锁后，将会启动一个“看门狗”的后台线程，定时检测是否仍然持有锁，如果持有，将延长锁的持有时间 其他需要获取该锁的服务，将不断循环获取该锁，直到前面的线程释放了锁为止。 优点： redis性能很高，适合高并发下的加锁机制 缺点： 如果加锁的redis master 故障，刚好数据也还没有同步到slave，那其他加锁的客户端则会再次加锁成功，则相当于有两个客户大都拿到了锁。 zookeep
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值