Redis進(jìn)階: 鎖的使用

• 1. 概念
• • 1. 原子性
  • 2. 事務(wù)
• 2. 使用Redis構(gòu)建全局并發(fā)鎖
• 3. Redlock（redis分布式鎖）
• • 總結(jié)
• 相關(guān)Blog

1. 概念

1. 原子性

原子性
原子性是數(shù)據(jù)庫(kù)的事務(wù)中的特性。在數(shù)據(jù)庫(kù)事務(wù)的情景下，原子性指的是：一個(gè)事務(wù)（transaction）中的所有操作，要么全部完成，要么全部不完成，不會(huì)結(jié)束在中間某個(gè)環(huán)節(jié)。
對(duì)于Redis而言，命令的原子性指的是：一個(gè)操作的不可以再分，操作要么執(zhí)行，要么不執(zhí)行。

Redis操作原子性的原因
Redis的操作之所以是原子性的，是因?yàn)镽edis是單線程的。

進(jìn)程與線程

• 進(jìn)程
  計(jì)算機(jī)中已執(zhí)行程序的實(shí)體。比如，一個(gè)啟動(dòng)了的php-fpm，就是一個(gè)進(jìn)程。
• 線程
  操作系統(tǒng)能夠進(jìn)行運(yùn)算調(diào)度的最小單元。它被包含在進(jìn)程之中，是進(jìn)程的實(shí)際運(yùn)作單位。一條線程指的是進(jìn)程中一個(gè)單一順序的控制流，一個(gè)進(jìn)程中可以并發(fā)多個(gè)線程，每條線程并行執(zhí)行不同的任務(wù)。比如，mysql運(yùn)行時(shí)，mysql啟動(dòng)后，該mysql服務(wù)就是一個(gè)進(jìn)程，而mysql的連接、查詢的操作，就是線程。

進(jìn)程與線程的區(qū)別

• 資源（如打開(kāi)文件）：進(jìn)程間的資源相互獨(dú)立，同一進(jìn)程的各線程間共享資源。某進(jìn)程的線程在其他進(jìn)程不可見(jiàn)。
• 通信：進(jìn)程間通信：消息傳遞、同步、共享內(nèi)存、遠(yuǎn)程過(guò)程調(diào)用、管道。線程間通信：直接讀寫進(jìn)程數(shù)據(jù)段（需要進(jìn)程同步和互斥手段的輔助，以保證數(shù)據(jù)的一致性）。
• 調(diào)度和切換：線程上下文切換比進(jìn)程上下文切換要快得多。
  線程，是操作系統(tǒng)最小的執(zhí)行單元，在單線程程序中，任務(wù)一個(gè)一個(gè)地做，必須做完一個(gè)任務(wù)后，才會(huì)去做另一個(gè)任務(wù)。

Redis在并發(fā)中的表現(xiàn)
Redis的API是原子性的操作，那么多個(gè)命令在并發(fā)中也是原子性的嗎？
看看下面這段代碼：

$redis= newRedis(); $redis->connect('127.0.0.1',6379); for($i= 0;$iget('val'); $num++; $redis->set('val',$num); usleep(10000); }

用兩個(gè)終端執(zhí)行上面的程序，發(fā)現(xiàn)val的結(jié)果是小于2000的值，那么可以知道，在程序中執(zhí)行多個(gè)Redis命令并非是原子性的，這也和普通數(shù)據(jù)庫(kù)的表現(xiàn)是一樣的。
如果想在上面的程序中實(shí)現(xiàn)原子性，可以將get和set改成單命令操作，比如incr，或者使用Redis的事務(wù)，或者使用Redis+Lua的方式實(shí)現(xiàn)。

原子性總結(jié)

綜上所述，對(duì)Redis來(lái)說(shuō)，執(zhí)行g(shù)et、set以及eval等API，都是一個(gè)一個(gè)的任務(wù)，這些任務(wù)都會(huì)由Redis的線程去負(fù)責(zé)執(zhí)行，任務(wù)要么執(zhí)行成功，要么執(zhí)行失敗，這就是Redis的命令是原子性的原因。

Redis本身提供的所有API都是原子操作，Redis中的事務(wù)其實(shí)是要保證批量操作的原子性。

2. 事務(wù)

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事務(wù)相關(guān)的命令。事務(wù)可以一次執(zhí)行多個(gè)命令， 并且?guī)в幸韵聝蓚€(gè)重要的保證：

• 事務(wù)是一個(gè)單獨(dú)的隔離操作：事務(wù)中的所有命令都會(huì)序列化、按順序地執(zhí)行。事務(wù)在執(zhí)行的過(guò)程中，不會(huì)被其他客戶端發(fā)送來(lái)的命令請(qǐng)求所打斷。
• 事務(wù)是一個(gè)原子操作：事務(wù)中的命令要么全部被執(zhí)行，要么全部都不執(zhí)行。

事務(wù)的關(guān)鍵字

• EXEC 命令負(fù)責(zé)觸發(fā)并執(zhí)行事務(wù)中的所有命令：
  如果客戶端在使用 MULTI 開(kāi)啟了一個(gè)事務(wù)之后，卻因?yàn)閿嗑€而沒(méi)有成功執(zhí)行 EXEC ，那么事務(wù)中的所有命令都不會(huì)被執(zhí)行。
• 另一方面，如果客戶端成功在開(kāi)啟事務(wù)之后執(zhí)行 EXEC ，那么事務(wù)中的所有命令都會(huì)被執(zhí)行。
  當(dāng)使用 AOF 方式做持久化的時(shí)候， Redis 會(huì)使用單個(gè) write(2) 命令將事務(wù)寫入到磁盤中。
  然而，如果 Redis 服務(wù)器因?yàn)槟承┰虮还芾韱T殺死，或者遇上某種硬件故障，那么可能只有部分事務(wù)命令會(huì)被成功寫入到磁盤中。
  如果 Redis 在重新啟動(dòng)時(shí)發(fā)現(xiàn) AOF 文件出了這樣的問(wèn)題，那么它會(huì)退出，并匯報(bào)一個(gè)錯(cuò)誤。
  使用redis-check-aof程序可以修復(fù)這一問(wèn)題：它會(huì)移除 AOF 文件中不完整事務(wù)的信息，確保服務(wù)器可以順利啟動(dòng)。
  從 2.2 版本開(kāi)始，Redis 還可以通過(guò)樂(lè)觀鎖（optimistic lock）實(shí)現(xiàn) CAS （check-and-set）操作，具體信息請(qǐng)參考文檔的后半部分。

事務(wù)的語(yǔ)句

> MULTI OK > INCR foo QUEUED > INCR bar QUEUED > EXEC 1) (integer) 1 2) (integer) 1

為什么 Redis 不支持回滾（roll back）

如果你有使用關(guān)系式數(shù)據(jù)庫(kù)的經(jīng)驗(yàn)， 那么 “Redis 在事務(wù)失敗時(shí)不進(jìn)行回滾，而是繼續(xù)執(zhí)行余下的命令”這種做法可能會(huì)讓你覺(jué)得有點(diǎn)奇怪。
以下是這種做法的優(yōu)點(diǎn)：

• Redis 命令只會(huì)因?yàn)殄e(cuò)誤的語(yǔ)法而失敗（并且這些問(wèn)題不能在入隊(duì)時(shí)發(fā)現(xiàn)），或是命令用在了錯(cuò)誤類型的鍵上面：這也就是說(shuō)，從實(shí)用性的角度來(lái)說(shuō)，失敗的命令是由編程錯(cuò)誤造成的，而這些錯(cuò)誤應(yīng)該在開(kāi)發(fā)的過(guò)程中被發(fā)現(xiàn)，而不應(yīng)該出現(xiàn)在生產(chǎn)環(huán)境中。

2. 使用Redis構(gòu)建全局并發(fā)鎖

談起Redis的用途，小伙伴們都會(huì)說(shuō)使用它作為緩存，目前很多公司都用Redis作為緩存，但是使用Redis僅僅作為緩存未免太大材小用了。深究Redis的原理后你會(huì)發(fā)現(xiàn)它有很多用途，在很多場(chǎng)景下能夠使用它快速地解決問(wèn)題。常見(jiàn)的用途有：分布式鎖控制并發(fā)、結(jié)合bloom filter用于推薦去重、HyperLogLog用于統(tǒng)計(jì)UV、限流控制流量等等；這里我談下Redis分布式鎖控制并發(fā)的問(wèn)題。

Redis分布式鎖控制并發(fā)主要是通過(guò)在Redis里面創(chuàng)建一個(gè)key，當(dāng)其它進(jìn)程準(zhǔn)備占用的時(shí)候只能等待key釋放再占用。Redis里面有一個(gè)原子性指令setnx，當(dāng)key存在時(shí)，它返回0，表示當(dāng)前已有進(jìn)程占用，當(dāng)它返回1時(shí)可以執(zhí)行業(yè)務(wù)邏輯，此時(shí)沒(méi)有進(jìn)程占用，等邏輯執(zhí)行完后，可以刪除key釋放鎖，這樣可以簡(jiǎn)單的控制并發(fā)。

127.0.0.1:6379> setnx copy_question 11 (integer) 1 127.0.0.1:6379> setnx copy_question 11 (integer) 0

在業(yè)務(wù)邏輯執(zhí)行的過(guò)程中如果發(fā)生異常，此時(shí)key并沒(méi)有刪除，這樣就會(huì)造成死鎖，死鎖帶來(lái)的后果想必大家都很清楚。為了解決這個(gè)問(wèn)題，可以在setnx加鎖后設(shè)置key的過(guò)期時(shí)間，當(dāng)key到期自動(dòng)刪除。

127.0.0.1:6379> expire copy_question l0 (integer) 1

但是仔細(xì)想想你還會(huì)發(fā)現(xiàn)，如果在執(zhí)行setnx后，執(zhí)行expire前Redis發(fā)生宕機(jī)了，這樣就不會(huì)執(zhí)行expire，也會(huì)造成死鎖。由于setnx與expire是兩條命令，并且expire依賴setnx的執(zhí)行結(jié)果，為了解決這個(gè)問(wèn)題可以使用set key value [expiration EX seconds|PX milliseconds] [NX|XX] ，這是一條原子性的指令，同時(shí)包含setnx和expire。

127.0.0.1:6379> set copy_question l11 ex 10 nx OK 127.0.0.1:6379> set copy_question l11 ex 10 nx (nil)

使用python實(shí)現(xiàn)的代碼：

class RedisLock(object):"""踩坑 Redis并發(fā)鎖"""def __init__(self, key):self.redis_conn = get_redis_conn()self.lock_key = "{}_redis_gil".format(key)@staticmethoddef get_lock_value(cls):"""獲取value:param cls::return:"""cls.get_lok = cls.redis_conn.get(cls.lock_key)return cls.get_lok@staticmethoddef set_lock(cls, random_value):"""不能使用setnx 沒(méi)有設(shè)置過(guò)期時(shí)間，可能會(huì)出現(xiàn)死鎖引入random_value ：自己加的鎖只能自己釋放:param cls::param random_value::return:"""cls._lock = cls.redis_conn.set(cls.lock_key, random_value, nx=True, ex=5)# 如果返回null 表示key存在存在并發(fā)if cls._lock:return Trueelse:LOGGER = logging.getLogger('core.utils')LOGGER.warning(u"試題復(fù)制存在并發(fā)")raise RsError("試題復(fù)制存在并發(fā)，請(qǐng)稍后再試")@staticmethoddef release(cls):"""釋放鎖:param cls::return:"""cls.redis_conn.delete(cls.lock_key)@staticmethoddef redis_lock(cls):"""只有當(dāng)設(shè)置的value與do_something執(zhí)行完后所獲取的值相同時(shí)才刪除key防止在分布式中： clientA由于執(zhí)行時(shí)間過(guò)期(clientA的執(zhí)行時(shí)間比設(shè)置的過(guò)期時(shí)間大)，clientB獲取鎖，clientA執(zhí)行完后釋放鎖(刪除key)，其實(shí)這時(shí)候刪除的是B的key，為防止這種情況引入random_value 只有當(dāng)前值為random_value時(shí)才刪除:param cls::return:"""random_value = time.time()if cls.set_lock(cls, random_value):do_something()now_value = cls.get_lock_value(cls)if now_value == random_value:cls.release()return Trueelse:return Falsedef do_something():pass

在實(shí)際業(yè)務(wù)中調(diào)用Redis全局鎖，進(jìn)行加鎖示例：

# 公庫(kù)試題復(fù)制到平臺(tái)考慮并發(fā)問(wèn)題，加鎖處理 if self.visible_scope == 10:key = hash(self.question_id)cls = RedisLock(key)cls.redis_lock(cls)try:self.insert_question()except Exception:raise RsError("試題插入失敗")finally:cls.release(cls)

如果是Redis集群下此方法可能仍然有問(wèn)題，試想下：在一個(gè)redis集群中，主節(jié)點(diǎn)由于某種原因掛掉了，從節(jié)點(diǎn)變成了主節(jié)點(diǎn)，而此時(shí)redis鎖還未同步到原從節(jié)點(diǎn)中，那么這個(gè)鎖也就失效了，當(dāng)其它進(jìn)程申請(qǐng)鎖時(shí)仍然可以申請(qǐng)成功。

針對(duì)這個(gè)問(wèn)題，新版的redis引入了redlock，通過(guò)redlock.Redlock對(duì)多個(gè)redis節(jié)點(diǎn)進(jìn)行加鎖，當(dāng)超過(guò)一半的節(jié)點(diǎn)加鎖成功時(shí)鎖才生效。這樣在一定程度上提高了高可用性，但由于每次加鎖和釋放鎖要對(duì)多個(gè)節(jié)點(diǎn)進(jìn)行讀寫，所以性能上肯定是沒(méi)有單節(jié)點(diǎn)鎖高的。

3. Redlock（redis分布式鎖）

**Redlock：**全名叫做 Redis Distributed Lock;即使用redis實(shí)現(xiàn)的分布式鎖；

使用場(chǎng)景：多個(gè)服務(wù)間保證同一時(shí)刻同一時(shí)間段內(nèi)同一用戶只能有一個(gè)請(qǐng)求（防止關(guān)鍵業(yè)務(wù)出現(xiàn)并發(fā)攻擊）；

官網(wǎng)文檔地址如下：https://redis.io/topics/distlock

這個(gè)鎖的算法實(shí)現(xiàn)了多redis實(shí)例的情況，相對(duì)于單redis節(jié)點(diǎn)來(lái)說(shuō)，優(yōu)點(diǎn)在于 防止了 單節(jié)點(diǎn)故障造成整個(gè)服務(wù)停止運(yùn)行的情況；并且在多節(jié)點(diǎn)中鎖的設(shè)計(jì)，及多節(jié)點(diǎn)同時(shí)崩潰等各種意外情況有自己獨(dú)特的設(shè)計(jì)方法；

此博客或者官方文檔的相關(guān)概念：

• 1.TTL：Time To Live;只 redis key 的過(guò)期時(shí)間或有效生存時(shí)間

• 2.clock drift:時(shí)鐘漂移；指兩個(gè)電腦間時(shí)間流速基本相同的情況下，兩個(gè)電腦（或兩個(gè)進(jìn)程間）時(shí)間的差值；如果電腦距離過(guò)遠(yuǎn)會(huì)造成時(shí)鐘漂移值 過(guò)大

最低保證分布式鎖的有效性及安全性的要求如下：

• 1.互斥；任何時(shí)刻只能有一個(gè)client獲取鎖

• 2.釋放死鎖；即使鎖定資源的服務(wù)崩潰或者分區(qū)，仍然能釋放鎖

• 3.容錯(cuò)性；只要多數(shù)redis節(jié)點(diǎn)（一半以上）在使用，client就可以獲取和釋放鎖

網(wǎng)上講的基于故障轉(zhuǎn)移實(shí)現(xiàn)的redis主從無(wú)法真正實(shí)現(xiàn)Redlock:

• 因?yàn)閞edis在進(jìn)行主從復(fù)制時(shí)是異步完成的，比如在clientA獲取鎖后，主redis復(fù)制數(shù)據(jù)到從redis過(guò)程中崩潰了，導(dǎo)致沒(méi)有復(fù)制到從redis中，然后從redis選舉出一個(gè)升級(jí)為主redis,造成新的主redis沒(méi)有clientA 設(shè)置的鎖，這是clientB嘗試獲取鎖，并且能夠成功獲取鎖，導(dǎo)致互斥失效；

思考題：這個(gè)失敗的原因是因?yàn)閺膔edis立刻升級(jí)為主redis，如果能夠過(guò)TTL時(shí)間再升級(jí)為主redis（延遲升級(jí)）后，或者立刻升級(jí)為主redis但是過(guò)TTL的時(shí)間后再執(zhí)行獲取鎖的任務(wù)，就能成功產(chǎn)生互斥效果；是不是這樣就能實(shí)現(xiàn)基于redis主從的Redlock;

redis單實(shí)例中實(shí)現(xiàn)分布式鎖的正確方式（原子性非常重要）:

• 1.設(shè)置鎖時(shí)，使用set命令，因?yàn)槠浒藄etnx,expire的功能，起到了原子操作的效果，給key設(shè)置隨機(jī)值，并且只有在key不存在時(shí)才設(shè)置成功返回True,并且設(shè)置key的過(guò)期時(shí)間（最好用毫秒）

SET key_name my_random_value NX PX 30000 -- NX 表示if not exist 就設(shè)置并返回True，否則不設(shè)置并返回False PX 表示過(guò)期時(shí)間用毫秒級(jí)， 30000 表示這些毫秒時(shí)間后此key過(guò)期

2.在獲取鎖后，并完成相關(guān)業(yè)務(wù)后，需要?jiǎng)h除自己設(shè)置的鎖（必須是只能刪除自己設(shè)置的鎖，不能刪除他人設(shè)置的鎖）；

• 刪除原因：保證服務(wù)器資源的高利用效率，不用等到鎖自動(dòng)過(guò)期才刪除；

• 刪除方法：最好使用Lua腳本刪除（redis保證執(zhí)行此腳本時(shí)不執(zhí)行其他操作，保證操作的原子性），代碼如下；邏輯是 先獲取key，如果存在并且值是自己設(shè)置的就刪除此key;否則就跳過(guò)；

if redis.call("get",KEYS[1]) == ARGV[1] thenreturn redis.call("del",KEYS[1]) elsereturn 0 end

算法流程圖如下:

多節(jié)點(diǎn)redis實(shí)現(xiàn)的分布式鎖算法(RedLock):有效防止單點(diǎn)故障

假設(shè)有5個(gè)完全獨(dú)立的redis主服務(wù)器

• 1.獲取當(dāng)前時(shí)間戳

• 2.client嘗試按照順序使用相同的key,value獲取所有redis服務(wù)的鎖，在獲取鎖的過(guò)程中的獲取時(shí)間比鎖過(guò)期時(shí)間短很多，這是為了不要過(guò)長(zhǎng)時(shí)間等待已經(jīng)關(guān)閉的redis服務(wù)。并且試著獲取下一個(gè)redis實(shí)例。

  比如：TTL為5s,設(shè)置獲取鎖最多用1s，所以如果一秒內(nèi)無(wú)法獲取鎖，就放棄獲取這個(gè)鎖，從而嘗試獲取下個(gè)鎖

• 3.client通過(guò)獲取所有能獲取的鎖后的時(shí)間減去第一步的時(shí)間，這個(gè)時(shí)間差要小于TTL時(shí)間并且至少有3個(gè)redis實(shí)例成功獲取鎖，才算真正的獲取鎖成功

• 4.如果成功獲取鎖，則鎖的真正有效時(shí)間是 TTL減去第三步的時(shí)間差 的時(shí)間；比如：TTL 是5s,獲取所有鎖用了2s,則真正鎖有效時(shí)間為3s(其實(shí)應(yīng)該再減去時(shí)鐘漂移);

• 5.如果客戶端由于某些原因獲取鎖失敗，便會(huì)開(kāi)始解鎖所有redis實(shí)例；因?yàn)榭赡芤呀?jīng)獲取了小于3個(gè)鎖，必須釋放，否則影響其他client獲取鎖

算法示意圖如下：

RedLock算法是否是異步算法？？

可以看成是同步算法；因?yàn)?即使進(jìn)程間（多個(gè)電腦間）沒(méi)有同步時(shí)鐘，但是每個(gè)進(jìn)程時(shí)間流速大致相同；并且時(shí)鐘漂移相對(duì)于TTL叫小，可以忽略，所以可以看成同步算法；（不夠嚴(yán)謹(jǐn)，算法上要算上時(shí)鐘漂移，因?yàn)槿绻麅蓚€(gè)電腦在地球兩端，則時(shí)鐘漂移非常大）

RedLock失敗重試

當(dāng)client不能獲取鎖時(shí)，應(yīng)該在隨機(jī)時(shí)間后重試獲取鎖；并且最好在同一時(shí)刻并發(fā)的把set命令發(fā)送給所有redis實(shí)例；而且對(duì)于已經(jīng)獲取鎖的client在完成任務(wù)后要及時(shí)釋放鎖，這是為了節(jié)省時(shí)間；

RedLock釋放鎖

由于釋放鎖時(shí)會(huì)判斷這個(gè)鎖的value是不是自己設(shè)置的，如果是才刪除；所以在釋放鎖時(shí)非常簡(jiǎn)單，只要向所有實(shí)例都發(fā)出釋放鎖的命令，不用考慮能否成功釋放鎖；

RedLock注意點(diǎn)（Safety arguments）:

• 1.先假設(shè)client獲取所有實(shí)例，所有實(shí)例包含相同的key和過(guò)期時(shí)間(TTL) ,但每個(gè)實(shí)例set命令時(shí)間不同導(dǎo)致不能同時(shí)過(guò)期，第一個(gè)set命令之前是T1,最后一個(gè)set命令后為T2,則此client有效獲取鎖的最小時(shí)間為TTL-(T2-T1)-時(shí)鐘漂移;

• 2.對(duì)于以N/2+ 1(也就是一半以 上)的方式判斷獲取鎖成功，是因?yàn)槿绻∮谝话肱袛酁槌晒Φ脑?#xff0c;有可能出現(xiàn)多個(gè)client都成功獲取鎖的情況， 從而使鎖失效

• 3.一個(gè)client鎖定大多數(shù)事例耗費(fèi)的時(shí)間大于或接近鎖的過(guò)期時(shí)間，就認(rèn)為鎖無(wú)效，并且解鎖這個(gè)redis實(shí)例(不執(zhí)行業(yè)務(wù)) ;只要在TTL時(shí)間內(nèi)成功獲取一半以上的鎖便是有效鎖;否則無(wú)效

系統(tǒng)有活性的三個(gè)特征:

• 1.能夠自動(dòng)釋放鎖

• 2.在獲取鎖失敗（不到一半以上），或任務(wù)完成后 能夠自動(dòng)釋放鎖，不用等到其自動(dòng)過(guò)期

• 3.在client重試獲取哦鎖前（第一次失敗到第二次重試時(shí)間間隔）大于第一次獲取鎖消耗的時(shí)間；

• 4.重試獲取鎖要有一定次數(shù)限制

RedLock性能及崩潰恢復(fù)的相關(guān)解決方法:

• 1.如果redis沒(méi)有持久化功能，在clientA獲取鎖成功后，所有redis重啟，clientB能夠再次獲取到鎖，這樣違法了鎖的排他互斥性;

• 2.如果啟動(dòng)AOF永久化存儲(chǔ)，事情會(huì)好些， 舉例:當(dāng)我們重啟redis后，由于redis過(guò)期機(jī)制是按照unix時(shí)間戳走的，所以在重啟后，然后會(huì)按照規(guī)定的時(shí)間過(guò)期，不影響業(yè)務(wù);但是由于AOF同步到磁盤的方式默認(rèn)是每秒-次，如果在一秒內(nèi)斷電，會(huì)導(dǎo)致數(shù)據(jù)丟失，立即重啟會(huì)造成鎖互斥性失效;但如果同步磁盤方式使用Always(每一個(gè)寫命令都同步到硬盤)造成性能急劇下降;所以在鎖完全有效性和性能方面要有所取舍;

• 3.有效解決既保證鎖完全有效性及性能高效及即使斷電情況的方法是redis同步到磁盤方式保持默認(rèn)的每秒，在redis無(wú)論因?yàn)槭裁丛蛲５艉笠却齌TL時(shí)間后再重啟(學(xué)名:延遲重啟) ;缺點(diǎn)是 在TTL時(shí)間內(nèi)服務(wù)相當(dāng)于暫停狀態(tài);

總結(jié)

• 1.TTL時(shí)長(zhǎng) 要大于正常業(yè)務(wù)執(zhí)行的時(shí)間+獲取所有redis服務(wù)消耗時(shí)間+時(shí)鐘漂移

• 2.獲取redis所有服務(wù)消耗時(shí)間要 遠(yuǎn)小于TTL時(shí)間，并且獲取成功的鎖個(gè)數(shù)要 在總數(shù)的一般以上:N/2+1

• 3.嘗試獲取每個(gè)redis實(shí)例鎖時(shí)的時(shí)間要 遠(yuǎn)小于TTL時(shí)間

• 4.嘗試獲取所有鎖失敗后 重新嘗試一定要有一定次數(shù)限制

• 5.在redis崩潰后（無(wú)論一個(gè)還是所有），要延遲TTL時(shí)間重啟redis

• 6.在實(shí)現(xiàn)多redis節(jié)點(diǎn)時(shí)要結(jié)合單節(jié)點(diǎn)分布式鎖算法 共同實(shí)現(xiàn)

相關(guān)Blog

Redis原子性
Redis構(gòu)建全局并發(fā)鎖
Redlock（redis分布式鎖）原理分析

總結(jié)

以上是生活随笔為你收集整理的Redis进阶: 锁的使用的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。