Redisson--红锁(Redlock)--使用/原理

原文网址:Redisson--红锁(Redlock)--使用/原理_IT利刃出鞘的博客-CSDN博客

技术星球

欢迎来到IT技术星球,网站是:learn.skyofit.com(或者百度直接搜:自学精灵)。内容有:Java真实面试题Java设计模式实战、Shiro项目实战、Idea和Navicat的“魔法”教程、SpringBoot进阶、架构与微服务设计、高并发实战、Java入门实战、网站防御技术、JavaWeb入门项目等。网站的定位:超高的质量、超高的真实性、超高的实用性。欢迎加入~

简介

说明

本文介绍为什么要使用Redis的红锁(Redlock)、什么是Redis的红锁以及Redis红锁的原理。

本文用Redisson来介绍Redis红锁的用法。

Redisson 高版本会根据redisClient的模式来决定getLock返回的锁类型,如果集群模式,满足红锁的条件,则会直接返回红锁。

官网

REDIS distlock -- Redis中国用户组(CRUG)

为什么使用Redis的红锁

主从结构分布式锁的问题

实现Redis分布式锁的最简单的方法就是在Redis中创建一个key,这个key有一个失效时间(TTL),以保证锁最终会被自动释放掉。当客户端释放资源(解锁)的时候,会删除掉这个key。

从表面上看似乎效果不错,但有一个严重的单点失败问题:如果Redis挂了怎么办?你可能会说,可以通过增加一个slave节点解决这个问题。但这通常是行不通的。这样做,我们不能实现资源的独享,因为Redis的主从同步通常是异步的。

在这种场景(主从结构)中存在明显的竞态:

  1. 客户端A从master获取到锁
  2. 在master将锁同步到slave之前,master宕掉了。
  3. slave节点被晋级为master节点
  4. 客户端B从新的master获取到锁
    1. 这个锁对应的资源之前已经被客户端A已经获取到了。安全失效!

有时候程序就是这么巧,比如说正好一个节点挂掉的时候,多个客户端同时取到了锁。如果你可以接受这种小概率错误,那用这个基于复制的方案就完全没有问题。否则的话,我们建议你实现下面描述的解决方案。

上边只是部分内容,为便于维护,本文已迁移到此地址:Redisson-红锁(Redlock)-使用/原理 - 自学精灵

  • 19
    点赞
  • 156
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 18
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 18
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

IT利刃出鞘

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值