Redis分布式鎖之紅鎖的實(shí)現(xiàn)
一 分布式鎖的概念
1:概念
分布式鎖(多服務(wù)共享鎖) 在分布式的部署環(huán)境下,通過鎖機(jī)制來讓多客戶端互斥的對共享資源進(jìn)行訪問控制分布式系統(tǒng)不同進(jìn)程共同訪問共享資源的一種鎖的實(shí)現(xiàn)。如果不同的系統(tǒng)或同一個(gè)系統(tǒng)的不同主機(jī)之間共享了某個(gè)臨界資源,往往需要互斥來防止彼此干擾,以保證一致性。
2:鎖/分布式鎖/事務(wù)區(qū)別
- 鎖 單進(jìn)程的系統(tǒng)中,存在多線程同時(shí)操作一個(gè)公共變量,此時(shí)需要加鎖對變量進(jìn)行同步操作,保證多線程的操作線性執(zhí)行消除并發(fā)修改。解決的是單進(jìn)程中的多線程并發(fā)問題。
- 分布式鎖 只要的應(yīng)用場景是在集群模式的多個(gè)相同服務(wù),可能會部署在不同機(jī)器上,解決進(jìn)程間安全問題,防止多進(jìn)程同時(shí)操作一個(gè)變量或者數(shù)據(jù)庫。解決的是多進(jìn)程的并發(fā)問題 事務(wù) 解決一個(gè)會話過程中,上下文的修改對所有數(shù)據(jù)庫表的操作要么全部成功,要不全部失敗。所以應(yīng)用在service層。解決的是一個(gè)會話中的操作的數(shù)據(jù)一致性。
- 分布式事務(wù) 解決一個(gè)聯(lián)動操作,比如一個(gè)商品的買賣分為添加商品到購物車、修改商品庫存,此時(shí)購物車服務(wù)和商品庫存服務(wù)可能部署在兩臺電腦,這時(shí)候需要保證對兩個(gè)服務(wù)的操作都全部成功或者全部回退。解決的是組合服務(wù)的數(shù)據(jù)操作的一致性問題
3:reddison的公平鎖
reddison公平鎖枷鎖
默認(rèn)的加鎖邏輯是非公平的。在加鎖失敗時(shí),線程會進(jìn)入 while 循環(huán),一直嘗試獲得鎖,這時(shí)候是多線程進(jìn)行競爭。就是說誰搶到就是誰的。Redisson 提供了公平鎖機(jī)制,使用方式如下
RLock fairLock = redisson.getFairLock("anyLock");
// 最常見的使用方法
fairLock.lock();
看門狗機(jī)制是在 RedissonBaseLock#scheduleExpirationRenewal 方法中,這塊公平鎖和非公平鎖并無區(qū)別。前文已經(jīng)了解到,公平鎖加鎖失敗之后,會將當(dāng)前放到等待隊(duì)列中,通過 Java 代碼中的循環(huán)不斷嘗試獲得鎖。
reddison公平鎖釋放
公平鎖的釋放同樣分為主動釋放和超時(shí)釋放。
- 主動釋放,即自己調(diào)用釋放鎖。
- 超時(shí)刪除,則分為兩種,一種是持鎖線程超時(shí)刪除,這種和非公平鎖沒有任何區(qū)別,因?yàn)檫@個(gè)鎖也是含有超時(shí)時(shí)間+看門狗續(xù)租的。另一種則是等待隊(duì)列中的超時(shí)刪除,是在每次獲取鎖之前,判斷第一個(gè)等待線程的時(shí)間戳是否超時(shí),從而移除鎖。
二 、使用的案例場景
需求當(dāng)在打車軟件中,乘客下了訂單。多個(gè)司機(jī)搶單,此時(shí)因?yàn)閱巫又挥幸粋€(gè),多個(gè)司機(jī)對此共享資源進(jìn)行搶,此處應(yīng)該使用分布式鎖;后臺服務(wù)部署在多臺服務(wù)器上;
controller層代碼
@GetMapping("/do/{orderId}")
public String grab(@PathVariable("orderId") int orderId, int driverId){
System.out.println("order:"+orderId+",driverId:"+driverId);
//此處調(diào)用鎖控制層代碼
grabService.grabOrder(orderId,driverId);
return "";
}
鎖控制層代碼(使用synchronized 不成功)使用synchronized 不能保證多臺服務(wù)器只有一個(gè)搶成功;因?yàn)閟ynchronized 只能鎖本服務(wù)的資源;多臺服務(wù)的資源是鎖不住的;
@Autowired
OrderService orderService;
@Override
public String grabOrder(int orderId, int driverId) {
String lock = (orderId+"");
synchronized (lock.intern()) {
try {
System.out.println("司機(jī):"+driverId+" 執(zhí)行搶單邏輯");
//此處調(diào)用訂單業(yè)務(wù)代碼
boolean b = orderService.grab(orderId, driverId);
if(b) {
System.out.println("司機(jī):"+driverId+" 搶單成功");
}else {
System.out.println("司機(jī):"+driverId+" 搶單失敗");
}
} finally {
}
}
return null;
}
調(diào)用的訂單業(yè)務(wù)代碼這一層就是寫的偽代碼,后續(xù)并不關(guān)注他

三、Redis解決方案-紅鎖
介紹
紅鎖本質(zhì)上就是使用多個(gè)Redis做鎖。例如有5個(gè)Redis,一次鎖的獲取,會對每個(gè)請求都獲取一遍,如果獲取鎖成功的數(shù)量超過一半(2.5),則獲取鎖成功,反之失敗;
釋放鎖也需要對每個(gè)Redis釋放
紅鎖原理
- 在Redis的分布式環(huán)境中,我們假設(shè)有5個(gè)Redis master。這些節(jié)點(diǎn)完全互相獨(dú)立,沒有主從關(guān)系
- 線程1向這5個(gè)redis加鎖,當(dāng)加到第三個(gè)的時(shí)候,4和5加不上了;但是符合紅鎖的n/2+1原則,所以線程1獲取到了鎖;
- 當(dāng)redis3掛了,此時(shí)線程1獲取到了鎖,正在順序執(zhí)行,
- 線程2來到了redis搶占鎖,因?yàn)?掛了,1,2有鎖,只有4和5可以加鎖,因?yàn)槲覀冏缘臅r(shí)候是5臺,4和5這兩臺不滿足n/2+1原則,搶占鎖失??;
當(dāng)鎖遇到故障轉(zhuǎn)移
單實(shí)例肯定不是很可靠吧?加鎖成功之后,結(jié)果 Redis 服務(wù)宕機(jī)了,這不就涼涼~
這時(shí)候會提出來將 Redis 主從部署。即使是主從,也是存在巧合的!
主從結(jié)構(gòu)中存在明顯的競態(tài):
客戶端 A 從 master 獲取到鎖在 master 將鎖同步到 slave 之前,master 宕掉了。
slave 節(jié)點(diǎn)被晉級為 master 節(jié)點(diǎn)客戶端 B 取得了同一個(gè)資源被客戶端 A 已經(jīng)獲取到的另外一個(gè)鎖。安全失效!有時(shí)候程序就是這么巧,比如說正好一個(gè)節(jié)點(diǎn)掛掉的時(shí)候,多個(gè)客戶端同時(shí)取到了鎖。如果你可以接受這種小概率錯(cuò)誤,那用這個(gè)基于復(fù)制的方案就完全沒有問題。
那我使用集群呢?如果還記得前面的內(nèi)容,應(yīng)該是知道對集群進(jìn)行加鎖的時(shí)候,其實(shí)是通過 CRC16 的 hash 函數(shù)來對 key 進(jìn)行取模,將結(jié)果路由到預(yù)先分配過 slot 的相應(yīng)節(jié)點(diǎn)上。
發(fā)現(xiàn)其實(shí)還是發(fā)到單個(gè)節(jié)點(diǎn)上的! 這時(shí)候 Redis 作者提出了 RedLock 的概念

總結(jié)一下就是對集群的每個(gè)節(jié)點(diǎn)進(jìn)行加鎖,如果大多數(shù)(N/2+1)加鎖成功了,則認(rèn)為獲取鎖成功。
RedLock 的問題
看著 RedLock 好像是解決問題了:
客戶端 A 鎖住了集群的大多數(shù)(一半以上);
客戶端 B 也要鎖住大多數(shù);
這里肯定會沖突,所以 客戶端 B 加鎖失敗。
那實(shí)際解決問題了么?
加鎖 key 的問題
有一個(gè)很大的疑問,我加鎖 lock1、lock2、lock3,但是 RedissonRedLock 是如何保證這三個(gè) key 是在歸屬于 Redis 集群中不同的 master 呢?因?yàn)榘凑?RedLock 的理論,是需要在半數(shù)以上的 master 節(jié)點(diǎn)加鎖成功。閱讀完源碼之后,發(fā)現(xiàn) RedissonRedLock 完全是 RedissonMultiLock 的子類,只是重寫了 failedLocksLimit 方法,保證半數(shù)以上加鎖成功即可。所以這三個(gè) key,是需要用戶來保證分散在不同的節(jié)點(diǎn)上的。
紅鎖的爭議
那我使用 5 個(gè)單節(jié)點(diǎn)的客戶端,然后再使用紅鎖,聽著好像是可以的,并且 RedissonRedLock 可以這樣使用。但是那和 Redis 集群還有啥關(guān)系??!所以依然沒有解決我的問題,在 redis 集群下 針對master節(jié)點(diǎn)集群,,還是需要用戶自己來“手工定位鎖”,使鎖的節(jié)點(diǎn)分散到不同的master 集群節(jié)點(diǎn)下。 手工定位鎖,這個(gè)…… 我考慮了下,還是不用 RedLock 吧!如果master節(jié)點(diǎn)變動則鎖也存在問題,master集群同步等等鎖的同步和鎖失效也是需要考慮的問題;
Redisson 的開發(fā)者認(rèn)為 Redis 的紅鎖也存在爭議(前文介紹的那個(gè)爭議),但是為了保證可用性,RLock 對象執(zhí)行的每個(gè) Redis 命令執(zhí)行都通過 Redis 3.0 中引入的 WAIT 命令進(jìn)行同步。
Redisson 的開發(fā)者認(rèn)為 Redis 的紅鎖也存在爭議(前文介紹的那個(gè)爭議),但是為了保證可用性,RLock 對象執(zhí)行的每個(gè)
Redis 命令執(zhí)行都通過 Redis 3.0 中引入的 WAIT 命令進(jìn)行同步。

源碼在這一部分。

看源碼,同時(shí)發(fā)送了一個(gè) WAIT 1 1000 到 Redis。
結(jié)論:Redisson RedLock 是基于聯(lián)鎖 MultiLock 實(shí)現(xiàn)的,但是使用過程中需要自己判斷 key 落在哪個(gè)節(jié)點(diǎn)上,對使用者不是很友好。
紅鎖使用說明-官網(wǎng)介紹
基于Redis的Redisson紅鎖RedissonRedLock對象實(shí)現(xiàn)了Redlock介紹的加鎖算法。該對象也可以用來將多個(gè)RLock對象關(guān)聯(lián)為一個(gè)紅鎖,每個(gè)RLock對象實(shí)例可以來自于不同的Redisson實(shí)例。
RLock lock1 = redissonInstance1.getLock("lock1");
RLock lock2 = redissonInstance2.getLock("lock2");
RLock lock3 = redissonInstance3.getLock("lock3");
RedissonRedLock lock = new RedissonRedLock(lock1, lock2, lock3);
// 同時(shí)加鎖:lock1 lock2 lock3
// 紅鎖在大部分節(jié)點(diǎn)上加鎖成功就算成功。
lock.lock();
...
lock.unlock();
大家都知道,如果負(fù)責(zé)儲存某些分布式鎖的某些Redis節(jié)點(diǎn)宕機(jī)以后,而且這些鎖正好處于鎖住的狀態(tài)時(shí),這些鎖會出現(xiàn)鎖死的狀態(tài)。為了避免這種情況的發(fā)生,Redisson內(nèi)部提供了一個(gè)監(jiān)控鎖的看門狗,它的作用是在Redisson實(shí)例被關(guān)閉前,不斷的延長鎖的有效期。默認(rèn)情況下,看門狗的檢查鎖的超時(shí)時(shí)間是30秒鐘,也可以通過修改Config.lockWatchdogTimeout來另行指定。
另外Redisson還通過加鎖的方法提供了leaseTime的參數(shù)來指定加鎖的時(shí)間。超過這個(gè)時(shí)間后鎖便自動解開了。
RedissonRedLock lock = new RedissonRedLock(lock1, lock2, lock3); // 給lock1,lock2,lock3加鎖,如果沒有手動解開的話,10秒鐘后將會自動解開 lock.lock(10, TimeUnit.SECONDS); // 為加鎖等待100秒時(shí)間,并在加鎖成功10秒鐘后自動解開 boolean res = lock.tryLock(100, 10, TimeUnit.SECONDS); ... lock.unlock();
紅鎖實(shí)戰(zhàn)
1.注冊紅鎖的RedissonClient
@Component
public class RedisConfig {
@Bean(name = "redissonRed1")
@Primary
public RedissonClient redissonRed1(){
Config config = new Config();
config.useSingleServer().setAddress("127.0.0.1:6379").setDatabase(0);
return Redisson.create(config);
}
@Bean(name = "redissonRed2")
public RedissonClient redissonRed2(){
Config config = new Config();
config.useSingleServer().setAddress("127.0.0.1:6380").setDatabase(0);
return Redisson.create(config);
}
@Bean(name = "redissonRed3")
public RedissonClient redissonRed3(){
Config config = new Config();
config.useSingleServer().setAddress("127.0.0.1:6381").setDatabase(0);
return Redisson.create(config);
}
@Bean(name = "redissonRed4")
public RedissonClient redissonRed4(){
Config config = new Config();
config.useSingleServer().setAddress("127.0.0.1:6382").setDatabase(0);
return Redisson.create(config);
}
@Bean(name = "redissonRed5")
public RedissonClient redissonRed5(){
Config config = new Config();
config.useSingleServer().setAddress("127.0.0.1:6383").setDatabase(0);
return Redisson.create(config);
}
}
配置方式2
基于 Redis 的 Redisson 分布式聯(lián)鎖 RedissonMultiLock 對象可以將多個(gè) RLock 對象關(guān)聯(lián)為一個(gè)聯(lián)鎖,每個(gè) RLock 對象實(shí)例可以來自于不同的 Redisson 實(shí)例。

按照官方文檔的說法,這里 Redisson 客戶端可以不是同一個(gè)。當(dāng)然,一般工作中也不會說不用一個(gè)客戶端吧,可以看出 遍歷所有的鎖,依次加鎖。加鎖邏輯就和可重入鎖加鎖并無區(qū)別了。所以 Lua 腳本就不進(jìn)行分析了
2. 紅鎖使用
package com.online.taxi.order.service.impl;
import com.online.taxi.order.constant.RedisKeyConstant;
import com.online.taxi.order.service.GrabService;
import com.online.taxi.order.service.OrderService;
import org.redisson.Redisson;
import org.redisson.RedissonRedLock;
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.beans.factory.annotation.Qualifier;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;
import java.util.concurrent.TimeUnit;
@Service
public class GrabRedisRedissonRedLockLockServiceImpl implements GrabService {
// 紅鎖
@Autowired
@Qualifier("redissonRed1")
private RedissonClient redissonRed1;
@Autowired
@Qualifier("redissonRed2")
private RedissonClient redissonRed2;
@Autowired
@Qualifier("redissonRed3")
private RedissonClient redissonRed3;
@Autowired
@Qualifier("redissonRed4")
private RedissonClient redissonRed4;
@Autowired
@Qualifier("redissonRed5")
private RedissonClient redissonRed5;
@Autowired
OrderService orderService;
@Override
public String grabOrder(int orderId , int driverId){
System.out.println("紅鎖實(shí)現(xiàn)類");
//生成key
String lockKey = ("" + orderId).intern();
//redisson鎖 單節(jié)點(diǎn)
// RLock rLock = redissonRed1.getLock(lockKey);
//紅鎖 redis son
RLock rLock1 = redissonRed1.getLock(lockKey);
RLock rLock2 = redissonRed2.getLock(lockKey);
RLock rLock3 = redissonRed3.getLock(lockKey);
RLock rLock4 = redissonRed4.getLock(lockKey);
RLock rLock5 = redissonRed5.getLock(lockKey);
RedissonRedLock rLock = new RedissonRedLock(rLock1,rLock2,rLock3,rLock4,rLock5);
try {
/**紅鎖
* waitTimeout 嘗試獲取鎖的最大等待時(shí)間,超過這個(gè)值,則認(rèn)為獲取鎖失敗
* leaseTime 鎖的持有時(shí)間,超過這個(gè)時(shí)間鎖會自動失效(值應(yīng)設(shè)置為大于業(yè)務(wù)處理的時(shí)間,確保在鎖有效期內(nèi)業(yè)務(wù)能處理完)
*/
boolean b1 = rLock.tryLock((long)waitTimeout, (long)leaseTime, TimeUnit.SECONDS);
if (b1){
System.out.println("加鎖成功");
// 此代碼默認(rèn) 設(shè)置key 超時(shí)時(shí)間30秒,過10秒,再延時(shí)
System.out.println("司機(jī):"+driverId+" 執(zhí)行搶單邏輯");
boolean b = orderService.grab(orderId, driverId);
if(b) {
System.out.println("司機(jī):"+driverId+" 搶單成功");
}else {
System.out.println("司機(jī):"+driverId+" 搶單失敗");
}
System.out.println("加鎖成功");
}else {
System.out.println("加鎖失敗");
}
} finally {
rLock.unlock();
}
return null;
}
}
四、單機(jī)版redission 使用
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson-spring-boot-starter</artifactId>
<version>3.18.0</version>
</dependency>
1.配置
@Value("${spring.redis.host}")
private String url;
@Value("${spring.redis.port}")
private Integer port;
@Value("${spring.redis.password}")
private String password;
@Bean
public RedissonClient redissonClient(){
// 配置
Config config = new Config();
log.info("Redisson 初始化 {}",String.format("redis://%s:%d",url,port));
config.useSingleServer().setAddress(String.format("redis://%s:%d",url,port) )
.setPassword(password);
// 創(chuàng)建RedissonClient對象
return Redisson.create(config);
}
2. 注入分布式鎖
此處枷鎖后在釋放鎖是解決了鎖的讀寫機(jī)制問題
@Autowired
private RedissonClient redissonClient;
public List<? extends Object> getCachedConfigList(String ode) {
List<StructureVo> configuration =null;
String key = getCacheKey(orgCode, STR_CONFIG_LIST);
List<Object> cacheConfig = redisCache.getCacheList(key);
if (!CollectionUtils.isEmpty(cacheConfig)) {
return cacheConfig;
}
RLock lock = redissonClient.getLock(getReddisonEbomCacheKey());
try {
lock.lock(DEFAULT_EXPIRE_SECOND,TimeUnit.SECONDS);
List<Object> secondCacheConfig = redisCache.getCacheList(key);
if (!CollectionUtils.isEmpty(secondCacheConfig)) {
log.info("second lock reddison 查詢到緩存釋放鎖!");
reddisnUnlock(getReddisonEbomCacheKey());
return cacheConfig;
}
log.info("reddison枷鎖成功!存放緩存資源!");
configuration = this.queryAllConfiguration();
redisCache.setCacheList(key, configuration);
redisCache.expire(key, DEFAULT_EXPIRE_HOURS, TimeUnit.HOURS);
} catch (Exception e) {
log.error("Happen Exception: " + e.getMessage(),e);
}finally {
reddisnUnlock(getReddisonEbomCacheKey());
}
return configuration;
}
釋放鎖方法
private void reddisnUnlock(String key) {
log.info(" reddison key {}鎖釋放!",key);
try {
RLock unlock = redissonClient.getLock(key);
if (unlock != null && unlock.isHeldByCurrentThread()) {
unlock.unlock();
}
} catch (IllegalMonitorStateException e) {
log.info("reddison鎖釋放 Exception: " + e.getMessage(),e);
}
}
Redis 單實(shí)例版本鎖 NX
單實(shí)例加鎖
SET resource_name my_random_value NX PX 30000
對于單實(shí)例 Redis 只需要使用這個(gè)命令即可。
- NX:僅在不存在 key 的時(shí)候才能被執(zhí)行成功;
- PX:失效時(shí)間,傳入 30000,就是 30s 后自動釋放鎖;
- my_random_value:就是隨機(jī)值,可以是線程號之類的。主要是為了更安全的釋放鎖,釋放鎖的時(shí)候使用腳本告訴 Redis: 只有 key 存在并且存儲的值和我指定的值一樣才能刪除成功。
簡單描述即為
- 指定一個(gè) key 作為鎖標(biāo)記,存入 Redis 中,指定一個(gè) 唯一的用戶標(biāo)識作為 value。
- 當(dāng) key 不存在時(shí)才能設(shè)置值,確保同一時(shí)間只有一個(gè)客戶端進(jìn)程獲得鎖,滿足互斥性特性。
- 設(shè)置一個(gè)過期時(shí)間,防止因系統(tǒng)異常導(dǎo)致沒能刪除這個(gè) key,滿足防死鎖特性。
- 當(dāng)處理完業(yè)務(wù)之后需要清除這個(gè) key 來釋放鎖,清除 key 時(shí)需要校驗(yàn) value 值,需要滿足只有加鎖的人才能釋放鎖
可以通過以下 Lua 腳本實(shí)現(xiàn)鎖釋放:
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end為什么要設(shè)置隨機(jī)值?
主要是為了防止鎖被其他客戶端刪除。有這么一種情況:
- 客戶端 A 獲得了鎖,還沒有執(zhí)行結(jié)束,但是鎖超時(shí)自動釋放了;
- 客戶端 B 此時(shí)過來,是可以獲得鎖的,加鎖成功;
- 此時(shí),客戶端 A 執(zhí)行結(jié)束了,要去釋放鎖,如果不對比隨機(jī)值,就會把客戶端 B 的鎖給釋放了。
當(dāng)然前面看過 Redisson 的處理,這個(gè) my_random_value 存放的是 UUID:ThreadId 組合成的一個(gè)類似 931573de-903e-42fd-baa7-428ebb7eda80:1 的字符串。
為什么要用lua腳本操作redis數(shù)據(jù)庫?
1.減少開銷–減少向redis服務(wù)器的請求次數(shù)
2.原子操作–redis將lua腳本作為一個(gè)原子執(zhí)行
3.可復(fù)用–其他客戶端可以使用已經(jīng)執(zhí)行過的lua腳本
4.增加redis靈活性–lua腳本可以幫助redis做更多的事情
到此這篇關(guān)于Redis分布式鎖之紅鎖的實(shí)現(xiàn)的文章就介紹到這了,更多相關(guān)Redis 紅鎖內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Redis 中的熱點(diǎn)鍵和數(shù)據(jù)傾斜示例詳解
熱點(diǎn)鍵是指在 Redis 中被頻繁訪問的特定鍵,這些鍵由于其高訪問頻率,可能導(dǎo)致 Redis 服務(wù)器的性能問題,尤其是在高并發(fā)場景下,本文給大家介紹Redis 中的熱點(diǎn)鍵和數(shù)據(jù)傾斜,感興趣的朋友一起看看吧2025-03-03
詳解使用Redis SETNX 命令實(shí)現(xiàn)分布式鎖
本篇文章主要介紹了詳解使用Redis SETNX 命令實(shí)現(xiàn)分布式鎖,小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,也給大家做個(gè)參考。一起跟隨小編過來看看吧2017-01-01
Redis持久化方式之RDB和AOF的原理及優(yōu)缺點(diǎn)
在Redis中,數(shù)據(jù)可以分為兩類,即內(nèi)存數(shù)據(jù)和磁盤數(shù)據(jù),Redis?提供了兩種不同的持久化方式,其中?RDB?是快照備份機(jī)制,AOF?則是追加寫操作機(jī)制,本文將詳細(xì)給大家介紹Redis?持久化方式RDB和AOF的原理及優(yōu)缺點(diǎn),感興趣的同學(xué)可以跟著小編一起來學(xué)習(xí)2023-06-06
從原理到實(shí)踐分析?Redis?分布式鎖的多種實(shí)現(xiàn)方案
在分布式系統(tǒng)中,為了保證多個(gè)進(jìn)程或線程之間的數(shù)據(jù)一致性和正確性,需要使用鎖來實(shí)現(xiàn)互斥訪問共享資源,然而,使用本地鎖在分布式系統(tǒng)中存在問題,這篇文章主要介紹了從原理到實(shí)踐分析?Redis?分布式鎖的多種實(shí)現(xiàn)方案,需要的朋友可以參考下2024-07-07

