Redis进阶: 锁的使用
Redis進階: 鎖的使用
- 1. 概念
- 1. 原子性
- 2. 事務(wù)
- 2. 使用Redis構(gòu)建全局并發(fā)鎖
- 3. Redlock（redis分布式鎖）
- 總結(jié)
- 相關(guān)Blog
1. 概念
1. 原子性
原子性
原子性是數(shù)據(jù)庫的事務(wù)中的特性。在數(shù)據(jù)庫事務(wù)的情景下，原子性指的是：一個事務(wù)（transaction）中的所有操作，要么全部完成，要么全部不完成，不會結(jié)束在中間某個環(huán)節(jié)。
對于Redis而言，命令的原子性指的是：一個操作的不可以再分，操作要么執(zhí)行，要么不執(zhí)行。
Redis操作原子性的原因
Redis的操作之所以是原子性的，是因為Redis是單線程的。
進程與線程
- 進程
計算機中已執(zhí)行程序的實體。比如，一個啟動了的php-fpm，就是一個進程。 - 線程
操作系統(tǒng)能夠進行運算調(diào)度的最小單元。它被包含在進程之中，是進程的實際運作單位。一條線程指的是進程中一個單一順序的控制流，一個進程中可以并發(fā)多個線程，每條線程并行執(zhí)行不同的任務(wù)。比如，mysql運行時，mysql啟動后，該mysql服務(wù)就是一個進程，而mysql的連接、查詢的操作，就是線程。
進程與線程的區(qū)別
- 資源（如打開文件）：進程間的資源相互獨立，同一進程的各線程間共享資源。某進程的線程在其他進程不可見。
- 通信：進程間通信：消息傳遞、同步、共享內(nèi)存、遠程過程調(diào)用、管道。線程間通信：直接讀寫進程數(shù)據(jù)段（需要進程同步和互斥手段的輔助，以保證數(shù)據(jù)的一致性）。
- 調(diào)度和切換：線程上下文切換比進程上下文切換要快得多。
線程，是操作系統(tǒng)最小的執(zhí)行單元，在單線程程序中，任務(wù)一個一個地做，必須做完一個任務(wù)后，才會去做另一個任務(wù)。
Redis在并發(fā)中的表現(xiàn)
Redis的API是原子性的操作，那么多個命令在并發(fā)中也是原子性的嗎？
看看下面這段代碼：
用兩個終端執(zhí)行上面的程序，發(fā)現(xiàn)val的結(jié)果是小于2000的值，那么可以知道，在程序中執(zhí)行多個Redis命令并非是原子性的，這也和普通數(shù)據(jù)庫的表現(xiàn)是一樣的。
如果想在上面的程序中實現(xiàn)原子性，可以將get和set改成單命令操作，比如incr，或者使用Redis的事務(wù)，或者使用Redis+Lua的方式實現(xiàn)。
原子性總結(jié)
綜上所述，對Redis來說，執(zhí)行g(shù)et、set以及eval等API，都是一個一個的任務(wù)，這些任務(wù)都會由Redis的線程去負責(zé)執(zhí)行，任務(wù)要么執(zhí)行成功，要么執(zhí)行失敗，這就是Redis的命令是原子性的原因。
Redis本身提供的所有API都是原子操作，Redis中的事務(wù)其實是要保證批量操作的原子性。
2. 事務(wù)
MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事務(wù)相關(guān)的命令。事務(wù)可以一次執(zhí)行多個命令， 并且?guī)в幸韵聝蓚€重要的保證：
- 事務(wù)是一個單獨的隔離操作：事務(wù)中的所有命令都會序列化、按順序地執(zhí)行。事務(wù)在執(zhí)行的過程中，不會被其他客戶端發(fā)送來的命令請求所打斷。
- 事務(wù)是一個原子操作：事務(wù)中的命令要么全部被執(zhí)行，要么全部都不執(zhí)行。
事務(wù)的關(guān)鍵字
- EXEC 命令負責(zé)觸發(fā)并執(zhí)行事務(wù)中的所有命令：
如果客戶端在使用 MULTI 開啟了一個事務(wù)之后，卻因為斷線而沒有成功執(zhí)行 EXEC ，那么事務(wù)中的所有命令都不會被執(zhí)行。 - 另一方面，如果客戶端成功在開啟事務(wù)之后執(zhí)行 EXEC ，那么事務(wù)中的所有命令都會被執(zhí)行。
當使用 AOF 方式做持久化的時候， Redis 會使用單個 write(2) 命令將事務(wù)寫入到磁盤中。
然而，如果 Redis 服務(wù)器因為某些原因被管理員殺死，或者遇上某種硬件故障，那么可能只有部分事務(wù)命令會被成功寫入到磁盤中。
如果 Redis 在重新啟動時發(fā)現(xiàn) AOF 文件出了這樣的問題，那么它會退出，并匯報一個錯誤。
使用redis-check-aof程序可以修復(fù)這一問題：它會移除 AOF 文件中不完整事務(wù)的信息，確保服務(wù)器可以順利啟動。
從 2.2 版本開始，Redis 還可以通過樂觀鎖（optimistic lock）實現(xiàn) CAS （check-and-set）操作，具體信息請參考文檔的后半部分。
事務(wù)的語句
> MULTI OK > INCR foo QUEUED > INCR bar QUEUED > EXEC 1) (integer) 1 2) (integer) 1為什么 Redis 不支持回滾（roll back）
如果你有使用關(guān)系式數(shù)據(jù)庫的經(jīng)驗， 那么 “Redis 在事務(wù)失敗時不進行回滾，而是繼續(xù)執(zhí)行余下的命令”這種做法可能會讓你覺得有點奇怪。
以下是這種做法的優(yōu)點：
- Redis 命令只會因為錯誤的語法而失敗（并且這些問題不能在入隊時發(fā)現(xiàn)），或是命令用在了錯誤類型的鍵上面：這也就是說，從實用性的角度來說，失敗的命令是由編程錯誤造成的，而這些錯誤應(yīng)該在開發(fā)的過程中被發(fā)現(xiàn)，而不應(yīng)該出現(xiàn)在生產(chǎn)環(huán)境中。
2. 使用Redis構(gòu)建全局并發(fā)鎖
談起Redis的用途，小伙伴們都會說使用它作為緩存，目前很多公司都用Redis作為緩存，但是使用Redis僅僅作為緩存未免太大材小用了。深究Redis的原理后你會發(fā)現(xiàn)它有很多用途，在很多場景下能夠使用它快速地解決問題。常見的用途有：分布式鎖控制并發(fā)、結(jié)合bloom filter用于推薦去重、HyperLogLog用于統(tǒng)計UV、限流控制流量等等；這里我談下Redis分布式鎖控制并發(fā)的問題。
Redis分布式鎖控制并發(fā)主要是通過在Redis里面創(chuàng)建一個key，當其它進程準備占用的時候只能等待key釋放再占用。Redis里面有一個原子性指令setnx，當key存在時，它返回0，表示當前已有進程占用，當它返回1時可以執(zhí)行業(yè)務(wù)邏輯，此時沒有進程占用，等邏輯執(zhí)行完后，可以刪除key釋放鎖，這樣可以簡單的控制并發(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í)行的過程中如果發(fā)生異常，此時key并沒有刪除，這樣就會造成死鎖，死鎖帶來的后果想必大家都很清楚。為了解決這個問題，可以在setnx加鎖后設(shè)置key的過期時間，當key到期自動刪除。
127.0.0.1:6379> expire copy_question l0 (integer) 1但是仔細想想你還會發(fā)現(xiàn)，如果在執(zhí)行setnx后，執(zhí)行expire前Redis發(fā)生宕機了，這樣就不會執(zhí)行expire，也會造成死鎖。由于setnx與expire是兩條命令，并且expire依賴setnx的執(zhí)行結(jié)果，為了解決這個問題可以使用set key value [expiration EX seconds|PX milliseconds] [NX|XX] ，這是一條原子性的指令，同時包含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實現(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 沒有設(shè)置過期時間，可能會出現(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ā)，請稍后再試")@staticmethoddef release(cls):"""釋放鎖:param cls::return:"""cls.redis_conn.delete(cls.lock_key)@staticmethoddef redis_lock(cls):"""只有當設(shè)置的value與do_something執(zhí)行完后所獲取的值相同時才刪除key防止在分布式中： clientA由于執(zhí)行時間過期(clientA的執(zhí)行時間比設(shè)置的過期時間大)，clientB獲取鎖，clientA執(zhí)行完后釋放鎖(刪除key)，其實這時候刪除的是B的key，為防止這種情況引入random_value 只有當前值為random_value時才刪除: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在實際業(yè)務(wù)中調(diào)用Redis全局鎖，進行加鎖示例：
# 公庫試題復(fù)制到平臺考慮并發(fā)問題，加鎖處理 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集群下此方法可能仍然有問題，試想下：在一個redis集群中，主節(jié)點由于某種原因掛掉了，從節(jié)點變成了主節(jié)點，而此時redis鎖還未同步到原從節(jié)點中，那么這個鎖也就失效了，當其它進程申請鎖時仍然可以申請成功。
針對這個問題，新版的redis引入了redlock，通過redlock.Redlock對多個redis節(jié)點進行加鎖，當超過一半的節(jié)點加鎖成功時鎖才生效。這樣在一定程度上提高了高可用性，但由于每次加鎖和釋放鎖要對多個節(jié)點進行讀寫，所以性能上肯定是沒有單節(jié)點鎖高的。
3. Redlock（redis分布式鎖）
**Redlock：**全名叫做 Redis Distributed Lock;即使用redis實現(xiàn)的分布式鎖；
使用場景：多個服務(wù)間保證同一時刻同一時間段內(nèi)同一用戶只能有一個請求（防止關(guān)鍵業(yè)務(wù)出現(xiàn)并發(fā)攻擊）；
官網(wǎng)文檔地址如下：https://redis.io/topics/distlock
這個鎖的算法實現(xiàn)了多redis實例的情況，相對于單redis節(jié)點來說，優(yōu)點在于 防止了 單節(jié)點故障造成整個服務(wù)停止運行的情況；并且在多節(jié)點中鎖的設(shè)計，及多節(jié)點同時崩潰等各種意外情況有自己獨特的設(shè)計方法；
此博客或者官方文檔的相關(guān)概念：
-
1.TTL：Time To Live;只 redis key 的過期時間或有效生存時間
-
2.clock drift:時鐘漂移；指兩個電腦間時間流速基本相同的情況下，兩個電腦（或兩個進程間）時間的差值；如果電腦距離過遠會造成時鐘漂移值 過大
最低保證分布式鎖的有效性及安全性的要求如下：
-
1.互斥；任何時刻只能有一個client獲取鎖
-
2.釋放死鎖；即使鎖定資源的服務(wù)崩潰或者分區(qū)，仍然能釋放鎖
-
3.容錯性；只要多數(shù)redis節(jié)點（一半以上）在使用，client就可以獲取和釋放鎖
網(wǎng)上講的基于故障轉(zhuǎn)移實現(xiàn)的redis主從無法真正實現(xiàn)Redlock:
- 因為redis在進行主從復(fù)制時是異步完成的，比如在clientA獲取鎖后，主redis復(fù)制數(shù)據(jù)到從redis過程中崩潰了，導(dǎo)致沒有復(fù)制到從redis中，然后從redis選舉出一個升級為主redis,造成新的主redis沒有clientA 設(shè)置的鎖，這是clientB嘗試獲取鎖，并且能夠成功獲取鎖，導(dǎo)致互斥失效；
思考題：這個失敗的原因是因為從redis立刻升級為主redis，如果能夠過TTL時間再升級為主redis（延遲升級）后，或者立刻升級為主redis但是過TTL的時間后再執(zhí)行獲取鎖的任務(wù)，就能成功產(chǎn)生互斥效果；是不是這樣就能實現(xiàn)基于redis主從的Redlock;
redis單實例中實現(xiàn)分布式鎖的正確方式（原子性非常重要）:
- 1.設(shè)置鎖時，使用set命令，因為其包含了setnx,expire的功能，起到了原子操作的效果，給key設(shè)置隨機值，并且只有在key不存在時才設(shè)置成功返回True,并且設(shè)置key的過期時間（最好用毫秒）
2.在獲取鎖后，并完成相關(guān)業(yè)務(wù)后，需要刪除自己設(shè)置的鎖（必須是只能刪除自己設(shè)置的鎖，不能刪除他人設(shè)置的鎖）；
-
刪除原因：保證服務(wù)器資源的高利用效率，不用等到鎖自動過期才刪除；
-
刪除方法：最好使用Lua腳本刪除（redis保證執(zhí)行此腳本時不執(zhí)行其他操作，保證操作的原子性），代碼如下；邏輯是 先獲取key，如果存在并且值是自己設(shè)置的就刪除此key;否則就跳過；
算法流程圖如下:
多節(jié)點redis實現(xiàn)的分布式鎖算法(RedLock):有效防止單點故障
假設(shè)有5個完全獨立的redis主服務(wù)器
-
1.獲取當前時間戳
-
2.client嘗試按照順序使用相同的key,value獲取所有redis服務(wù)的鎖，在獲取鎖的過程中的獲取時間比鎖過期時間短很多，這是為了不要過長時間等待已經(jīng)關(guān)閉的redis服務(wù)。并且試著獲取下一個redis實例。
比如：TTL為5s,設(shè)置獲取鎖最多用1s，所以如果一秒內(nèi)無法獲取鎖，就放棄獲取這個鎖，從而嘗試獲取下個鎖
-
3.client通過獲取所有能獲取的鎖后的時間減去第一步的時間，這個時間差要小于TTL時間并且至少有3個redis實例成功獲取鎖，才算真正的獲取鎖成功
-
4.如果成功獲取鎖，則鎖的真正有效時間是 TTL減去第三步的時間差 的時間；比如：TTL 是5s,獲取所有鎖用了2s,則真正鎖有效時間為3s(其實應(yīng)該再減去時鐘漂移);
-
5.如果客戶端由于某些原因獲取鎖失敗，便會開始解鎖所有redis實例；因為可能已經(jīng)獲取了小于3個鎖，必須釋放，否則影響其他client獲取鎖
算法示意圖如下：
RedLock算法是否是異步算法？？
可以看成是同步算法；因為 即使進程間（多個電腦間）沒有同步時鐘，但是每個進程時間流速大致相同；并且時鐘漂移相對于TTL叫小，可以忽略，所以可以看成同步算法；（不夠嚴謹，算法上要算上時鐘漂移，因為如果兩個電腦在地球兩端，則時鐘漂移非常大）
RedLock失敗重試
當client不能獲取鎖時，應(yīng)該在隨機時間后重試獲取鎖；并且最好在同一時刻并發(fā)的把set命令發(fā)送給所有redis實例；而且對于已經(jīng)獲取鎖的client在完成任務(wù)后要及時釋放鎖，這是為了節(jié)省時間；
RedLock釋放鎖
由于釋放鎖時會判斷這個鎖的value是不是自己設(shè)置的，如果是才刪除；所以在釋放鎖時非常簡單，只要向所有實例都發(fā)出釋放鎖的命令，不用考慮能否成功釋放鎖；
RedLock注意點（Safety arguments）:
-
1.先假設(shè)client獲取所有實例，所有實例包含相同的key和過期時間(TTL) ,但每個實例set命令時間不同導(dǎo)致不能同時過期，第一個set命令之前是T1,最后一個set命令后為T2,則此client有效獲取鎖的最小時間為TTL-(T2-T1)-時鐘漂移;
-
2.對于以N/2+ 1(也就是一半以 上)的方式判斷獲取鎖成功，是因為如果小于一半判斷為成功的話，有可能出現(xiàn)多個client都成功獲取鎖的情況， 從而使鎖失效
-
3.一個client鎖定大多數(shù)事例耗費的時間大于或接近鎖的過期時間，就認為鎖無效，并且解鎖這個redis實例(不執(zhí)行業(yè)務(wù)) ;只要在TTL時間內(nèi)成功獲取一半以上的鎖便是有效鎖;否則無效
系統(tǒng)有活性的三個特征:
-
1.能夠自動釋放鎖
-
2.在獲取鎖失敗（不到一半以上），或任務(wù)完成后 能夠自動釋放鎖，不用等到其自動過期
-
3.在client重試獲取哦鎖前（第一次失敗到第二次重試時間間隔）大于第一次獲取鎖消耗的時間；
-
4.重試獲取鎖要有一定次數(shù)限制
RedLock性能及崩潰恢復(fù)的相關(guān)解決方法:
-
1.如果redis沒有持久化功能，在clientA獲取鎖成功后，所有redis重啟，clientB能夠再次獲取到鎖，這樣違法了鎖的排他互斥性;
-
2.如果啟動AOF永久化存儲，事情會好些， 舉例:當我們重啟redis后，由于redis過期機制是按照unix時間戳走的，所以在重啟后，然后會按照規(guī)定的時間過期，不影響業(yè)務(wù);但是由于AOF同步到磁盤的方式默認是每秒-次，如果在一秒內(nèi)斷電，會導(dǎo)致數(shù)據(jù)丟失，立即重啟會造成鎖互斥性失效;但如果同步磁盤方式使用Always(每一個寫命令都同步到硬盤)造成性能急劇下降;所以在鎖完全有效性和性能方面要有所取舍;
-
3.有效解決既保證鎖完全有效性及性能高效及即使斷電情況的方法是redis同步到磁盤方式保持默認的每秒，在redis無論因為什么原因停掉后要等待TTL時間后再重啟(學(xué)名:延遲重啟) ;缺點是 在TTL時間內(nèi)服務(wù)相當于暫停狀態(tài);
總結(jié)
-
1.TTL時長 要大于正常業(yè)務(wù)執(zhí)行的時間+獲取所有redis服務(wù)消耗時間+時鐘漂移
-
2.獲取redis所有服務(wù)消耗時間要 遠小于TTL時間，并且獲取成功的鎖個數(shù)要 在總數(shù)的一般以上:N/2+1
-
3.嘗試獲取每個redis實例鎖時的時間要 遠小于TTL時間
-
4.嘗試獲取所有鎖失敗后 重新嘗試一定要有一定次數(shù)限制
-
5.在redis崩潰后（無論一個還是所有），要延遲TTL時間重啟redis
-
6.在實現(xiàn)多redis節(jié)點時要結(jié)合單節(jié)點分布式鎖算法 共同實現(xiàn)
相關(guān)Blog
Redis原子性
Redis構(gòu)建全局并發(fā)鎖
Redlock（redis分布式鎖）原理分析
總結(jié)
以上是生活随笔為你收集整理的Redis进阶: 锁的使用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： [Redux/Mobx] redux它的
- 下一篇： React开发（234）:windows