Redis篇:事務和lua腳本的使用

現在多數秒殺,抽獎,搶紅包等大並發高流量的功能一般都是基於 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

歡迎指正文中錯誤

參考文章