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