Redisson

Redisson

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

技术星球

欢迎来到IT技术星球，网站是：learn.skyofit（或者百度直接搜：自学精灵）。内容有：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)-使用/原理 - 自学精灵