Redis篇：事務和lua指令碼的使用

潛行前行發表於2021-11-21
Redis指令碼

現在多數秒殺，抽獎，搶紅包等大併發高流量的功能一般都是基於 redis 實現，然而在選擇 redis 的時候，我們也要了解 redis 如何保證服務正確執行的原理

前言

  • redis 如何實現高效能和高併發
  • reids 事務的 ACID 原理
  • WATCH、EXEC 命令實現 redis 事務
  • lua 實現 redis事務
  • 搶紅包方案

關注公眾號，一起交流，微信搜一搜: 潛行前行

redis 如何實現高效能和高併發

  • redis 是一個記憶體資料庫，讀寫非常高效。除了開啟 AOF，RDB 非同步執行緒去持久化資料，基本沒有磁碟I/O消耗，效能方面是比 mysql，oracle 快很多
  • redis 自己實現一套簡單高效的基礎資料結構：動態字串（SDS），連結串列，字典，跳躍連結串列，整數集合和壓縮列表。然後在這個基礎上去實現使用者能操作的物件：字串，列表，雜湊，集合，有序集合等物件
  • reactor 模式的網路事件處理器。它使用了 I/O 多路複用去同時監控多個套接字，這是一種高效的I/O模型。reactor 相關知識可以看下這篇文章框架篇：見識一下linux高效能網路IO+Reactor模型
  • 事件處理器是單線執行的，這大大減少CPU的上下文切換，和對資源鎖的競爭問題，極大提高redis服務處理速度（至於為啥使用單執行緒，因為CPU夠用了，它的效能瓶頸在記憶體而不是CPU）
  • Redis直接自己構建了VM 機制 ，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求

reids 事務的 ACID 原理

  • redis 的事務需要先劃分出三個階段
    • 事務開啟，使用 MULTI 可以標誌著執行該命令的客戶端從非事務狀態切換至事務狀態redis> MULTI
    • 命令入隊，MULTI開啟事務之後，非 WATCH、EXEC、DISCARD、MULTI 等特殊命令；客戶端的命令不會被立即執行，而是放入一個事務佇列
    • 執行事務或者丟棄。如果收到 EXEC 的命令，事務佇列裡的命令將會被執行。如果是 DISCARD 則事務被丟棄
  • 命令入隊過程如果出錯(如使用了不存在的命令)，則事務佇列會被拒接執行
  • 執行事務期間出現了異常(如命令和操作的資料型別不匹配)，事務佇列的裡的命令還是繼續執行下去，直到全部命令執行完。不會回滾
  • WATCH 可用於監控 redis 變數值，在命令 EXEC 之前；redis 裡的資料是有機會被其他客戶端的命令修改的。使用 WATCH，監控的變數被修改後，執行 EXEC 時則會返回執行失敗的 nil 回覆
redis> WATCH "name"
OK
redis> MULTI   ### 此時name已被其他客戶端的命令修改
OK
redis> SET "name" "lwl"
QUEUED
redis> EXEC
(nil)
  • 從嚴格意義上來說，redis 是沒有事務的。因為事務必須具備四個特點：原子性(Atomicity)，一致性(Consistency)，隔離性(Isolation)，永續性(Durability)。然後 redis 是做不到這四點，只是具備其中一些特徵，redis的事務是個偽事務，而且不支援回滾。下面將為各位同學一一道來

原子性

從上面可以，事務的異常會發生在EXEC命令執行前、後

  • EXEC命令執行前：在命令入隊時就報錯，（如記憶體不足，命令名稱錯誤），redis 就會報錯並且記錄下這個錯誤。此時，客戶還能繼續提交命令操作；等到執行EXEC時，redis 就會拒絕執行所有提交的命令操作，返回事務失敗的結果 nil
  • EXEC命令執行後：命令和操作的資料型別不匹配，但 redis 例項沒有檢查出錯誤。在執行完 EXEC 命令以後，redis 實際執行這些指令，就會報錯。此時事務是不會回滾的，但事務佇列的命令還是繼續被執行。事務的原子性無法保證
  • EXEC執行時，發生故障：如果 redis 開啟了 AOF 日誌，那麼，只會有部分的事務操作被記錄到 AOF 日誌中。需要使用 redis-check-aof 工具檢查 AOF 日誌檔案，這個工具可以把未完成的事務操作從 AOF 檔案中去除。事務的原子性得到保證

一致性

  • EXEC命令執行前：入隊報錯事務會被放棄執行，具有一致性
  • EXEC命令執行後：實際執行時報錯，錯誤的執行不會執行，正確的指令可以正常執行，一致性可以保證
  • EXEC執行時，發生故障：RDB 模式，RDB 快照不會在事務執行時執行，事務結果不會儲存在RDB；AOF 模式，可以使用 redis-check-aof 工具檢查 AOF 日誌檔案，把未完成的事務操作從 AOF 檔案中去除。可以保證一致性

隔離性

  • EXEC 命令前執行，隔離性需要通過 WATCH 機制保證。因為 EXEC 命令執行前，其他客戶端命令可以被執行，相關變數會被修改；但可以使用  WATCH 機制監控相關變數。一旦相關變數被修改，則 EXEC 後則事務失敗返回；具有隔離性
  • EXEC 命令之後，隔離性可以保證。因為 redis 是單執行緒執行，事務佇列裡的命令和其他客戶端的命令只能二選一被順序執行，因此具有隔離性

永續性

  • 如果 redis 沒有使用 RDB 或 AOF，事務的持久化是不存在的
  • 使用 RDB 模式，那麼在一個事務執行後，而下一次的 RDB 快照還未執行前，如果發生了例項當機，資料丟失，這種情況下，事務修改的資料也是不能保證持久化
  • AOF 模式，因為 AOF 模式的三種配置選項 no、everysec 和 always 都會存在資料丟失的情況。所以，事務的永續性屬性也還是得不到保證

總結

  • redis 的事務機制可以保證一致性和隔離性；但是無法保證永續性；具備了一定的原子性，但不支援回滾

WATCH、EXEC 命令實現 redis 事務

redis> WATCH "map"
OK
redis> MULTI 
OK
redis> HSET map "csc" "lwl"  
QUEUED
redis> HGET map "csc"
QUEUED
redis> EXEC
1) OK
2) "lwl"

lua 實現 redis 事務

除了 MULTI、WATCH、EXEC 命令，還有其他的方式可做到 redis 原子性和隔離性嗎？有的，lua 指令碼；redis 內建了lua的執行環境，並自帶了一些 lua 函式庫。redis 執行 lua 時，會啟動一個偽客戶端去執行指令碼里的 redis 命令

  • 一致性，原子性，永續性 和 MULTI，EXEC 過程相似：如果 lua 存在錯誤的命令名稱，事務會執行失敗。如果在執行 redis 命令過程出現異常，之前正常執行的命令也不會回滾
  • lua 指令碼被當做一命令集合一起被執行，且 redis 是單線處理機制，因此不需要 WATCH 保證隔離性，天然具備隔離性
  • Lua呼叫Redis指令: redis.call("命令名稱"，引數1，引數2)

優點

  • 減少網路開銷：可以將多個請求通過指令碼的形式一次傳送，減少網路時延
  • 原子操作：Redis會將整個指令碼作為一個整體執行，中間不會被其他請求插入。在指令碼執行過程中無需擔心會出現競態條件
  • 可重複使用：客戶端傳送的指令碼會永久存在 redis 中，這樣其他客戶端可以複用這一指令碼，而不需要使用程式碼完成相同的邏輯

搶紅包方案

  • 問題關鍵點
    • 一：使用者是否參與過活動，不可重複參與
    • 二：紅包數量有限；而且一個可搶的紅包，保證不能讓多個人同時搶到
    • 三：持久化儲存紅包與使用者的關係
    • 四：如何保證 步驟一到步驟三的原子性和隔離性

關鍵點一

  • redis 的集合物件 set 是無序且唯一的。set 集合由整數集合或字典實現的，新增，刪除，查詢的複雜度基本視為 O(1)，存放的最大物件個數是2^32 - 1 (4294967295)
  • 使用 set 集合儲存參加過的使用者，每次使用者參與活動時先判斷是否在 set 裡。不在則可以搶紅包
  • 如果是使用者可以重複參與多次的場景，則使用雜湊物件，key存使用者物件，value 存放參與次數。使用 INCR 原子操作增加 value，如果返回數值 > 上限，說明搶的次數用完

關鍵點二

使用 list 或者 set 存放事先建立好的有限個紅包； 因為 redis 是單執行緒操作，同一時間，多人搶紅包，只會有一個人成功。而紅包是事先生成的，消費用完即止，不存在超發的可能

  • 使用 list 列表存放紅包
    • 因為紅包金額大小不一，為增加搶到紅包大小的隨機性，需要先shuffle一次，再 LPUSH 入佇列
    • RPOP 出佇列一個紅包，如果返回不為nil，則代表獲取成功，繼續下一步，反之則說明已搶完，返回
  • set 集合中有兩個指令非常適合在搶紅包、抽獎的場景使用
    • SPOP key [count] 移除並返回集合中的一個隨機元素
    • SRANDMEMBER key [count] 返回集合中一個或多個隨機數；需要再調 SREM 移除一遍
    • 將所有的紅包通過 SADD 新增到 set 中，然後通過隨機命令獲取對應的紅包即可
  • 如果有謝謝惠顧之類的落空選項，生成對應的無效紅包、獎品放入 set 或 list 即可
  • 搶紅包一般是有時效性，正好可以配合 redis 的 key 的失效時間使用。使得搶紅包功能很完美的解決

關鍵點三

  • 使用額為的 list 列表儲存使用者與紅包的關係，使用者搶到紅包後，將對應的關係 LPUSH 入佇列，然後服務去消費拉取資料批量儲存到資料庫即可

關鍵點四

使用 lua 指令碼實現即可

-- 引數：KEYS[1]-紅包list，KEYS[2]-使用者和紅包的消費list，KEYS[3]-去重的雜湊物件，KEYS[4]-使用者ID
-- 函式：嘗試獲得紅包，如果成功，則返回json字串，如果不成功，則返回nil
-- 返回值：nil 或者 json字串，{"userId":"使用者ID","id":"紅包ID"}
-- 如果使用者已搶過紅包，則返回nil

-- 步驟一，攔截重複參與
if redis.call('hexists', KEYS[3], KEYS[4]) == 1 then
  return nil
else
  -- 步驟二，先取出一個紅包
  local lunkMoney = redis.call('rpop', KEYS[1]);
  if luckMoney then
    local data = cjson.decode(luckMoney);
    data['userId'] = KEYS[4]; -- 加入使用者ID資訊
    local re = cjson.encode(data);
    -- 把使用者ID放到去重的雜湊，value設定為 1
    redis.call('hset', KEYS[3], KEYS[4], 1);
    -- 步驟三： 使用者和紅包放到已消費佇列裡
    redis.call('lpush', KEYS[2], re);
    return re;
  end
end
return nil

歡迎指正文中錯誤

參考文章

相關文章