[[436743]]

本文轉載自微信公眾號「潛行前行」，作者cscw 。轉載本文請聯(lián)系潛行前行公眾號。

 現(xiàn)在多數(shù)秒殺，抽獎，搶紅包等大并發(fā)高流量的功能一般都是基于 redis 實現(xiàn)，然而在選擇 redis 的時候，我們也要了解 redis 如何保證服務正確運行的原理

前言

• redis 如何實現(xiàn)高性能和高并發(fā)
• reids 事務的 ACID 原理
• WATCH、EXEC 命令實現(xiàn) redis 事務
• lua 實現(xiàn) redis事務
• 搶紅包方案

redis 如何實現(xiàn)高性能和高并發(fā)

• redis 是一個內(nèi)存數(shù)據(jù)庫，讀寫非常高效。除了開啟 AOF，RDB 異步線程去持久化數(shù)據(jù)，基本沒有磁盤I/O消耗，性能方面是比 mysql，oracle 快很多
• redis 自己實現(xiàn)一套簡單高效的基礎數(shù)據(jù)結構：動態(tài)字符串(SDS)，鏈表，字典，跳躍鏈表，整數(shù)集合和壓縮列表。然后在這個基礎上去實現(xiàn)用戶能操作的對象：字符串，列表，哈希，集合，有序集合等對象
• reactor 模式的網(wǎng)絡事件處理器。它使用了 I/O 多路復用去同時監(jiān)控多個套接字，這是一種高效的I/O模型。reactor 相關知識可以看下這篇文章框架篇：見識一下linux高性能網(wǎng)絡IO+Reactor模型
• 事件處理器是單線執(zhí)行的，這大大減少CPU的上下文切換，和對資源鎖的競爭問題，極大提高redis服務處理速度(至于為啥使用單線程，因為CPU夠用了，它的性能瓶頸在內(nèi)存而不是CPU)
• Redis直接自己構建了VM 機制 ，因為一般的系統(tǒng)調(diào)用系統(tǒng)函數(shù)的話，會浪費一定的時間去移動和請求

reids 事務的 ACID 原理

redis 的事務需要先劃分出三個階段

• 事務開啟，使用 MULTI 可以標志著執(zhí)行該命令的客戶端從非事務狀態(tài)切換至事務狀態(tài)redis> MULTI
• 命令入隊，MULTI開啟事務之后，非 WATCH、EXEC、DISCARD、MULTI 等特殊命令;客戶端的命令不會被立即執(zhí)行，而是放入一個事務隊列
• 執(zhí)行事務或者丟棄。如果收到 EXEC 的命令，事務隊列里的命令將會被執(zhí)行。如果是 DISCARD 則事務被丟棄

命令入隊過程如果出錯(如使用了不存在的命令)，則事務隊列會被拒接執(zhí)行

執(zhí)行事務期間出現(xiàn)了異常(如命令和操作的數(shù)據(jù)類型不匹配)，事務隊列的里的命令還是繼續(xù)執(zhí)行下去，直到全部命令執(zhí)行完。不會回滾

WATCH 可用于監(jiān)控 redis 變量值，在命令 EXEC 之前;redis 里的數(shù)據(jù)是有機會被其他客戶端的命令修改的。使用 WATCH，監(jiān)控的變量被修改后，執(zhí)行 EXEC 時則會返回執(zhí)行失敗的 nil 回復

redis> WATCH "name" 
OK 
redis> MULTI   ### 此時name已被其他客戶端的命令修改 
OK 
redis> SET "name" "lwl" 
QUEUED 
redis> EXEC 
(nil) 

從嚴格意義上來說，redis 是沒有事務的。因為事務必須具備四個特點：原子性(Atomicity)，一致性(Consistency)，隔離性(Isolation)，持久性(Durability)。然后 redis 是做不到這四點，只是具備其中一些特征，redis的事務是個偽事務，而且不支持回滾。下面將為各位同學一一道來

原子性

從上面可以，事務的異常會發(fā)生在EXEC命令執(zhí)行前、后

EXEC命令執(zhí)行前：在命令入隊時就報錯，(如內(nèi)存不足，命令名稱錯誤)，redis 就會報錯并且記錄下這個錯誤。此時，客戶還能繼續(xù)提交命令操作;等到執(zhí)行EXEC時，redis 就會拒絕執(zhí)行所有提交的命令操作，返回事務失敗的結果 nil

EXEC命令執(zhí)行后：命令和操作的數(shù)據(jù)類型不匹配，但 redis 實例沒有檢查出錯誤。在執(zhí)行完 EXEC 命令以后，redis 實際執(zhí)行這些指令，就會報錯。此時事務是不會回滾的，但事務隊列的命令還是繼續(xù)被執(zhí)行。事務的原子性無法保證

EXEC執(zhí)行時，發(fā)生故障：如果 redis 開啟了 AOF 日志，那么，只會有部分的事務操作被記錄到 AOF 日志中。需要使用 redis-check-aof 工具檢查 AOF 日志文件，這個工具可以把未完成的事務操作從 AOF 文件中去除。事務的原子性得到保證

一致性

EXEC命令執(zhí)行前：入隊報錯事務會被放棄執(zhí)行，具有一致性

EXEC命令執(zhí)行后：實際執(zhí)行時報錯，錯誤的執(zhí)行不會執(zhí)行，正確的指令可以正常執(zhí)行，一致性可以保證

EXEC執(zhí)行時，發(fā)生故障：RDB 模式，RDB 快照不會在事務執(zhí)行時執(zhí)行，事務結果不會保存在RDB;AOF 模式，可以使用 redis-check-aof 工具檢查 AOF 日志文件，把未完成的事務操作從 AOF 文件中去除?？梢员ＷC一致性

隔離性

EXEC 命令前執(zhí)行，隔離性需要通過 WATCH 機制保證。因為 EXEC 命令執(zhí)行前，其他客戶端命令可以被執(zhí)行，相關變量會被修改;但可以使用 WATCH 機制監(jiān)控相關變量。一旦相關變量被修改，則 EXEC 后則事務失敗返回;具有隔離性

EXEC 命令之后，隔離性可以保證。因為 redis 是單線程執(zhí)行，事務隊列里的命令和其他客戶端的命令只能二選一被順序執(zhí)行，因此具有隔離性

持久性

如果 redis 沒有使用 RDB 或 AOF，事務的持久化是不存在的

使用 RDB 模式，那么在一個事務執(zhí)行后，而下一次的 RDB 快照還未執(zhí)行前，如果發(fā)生了實例宕機，數(shù)據(jù)丟失，這種情況下，事務修改的數(shù)據(jù)也是不能保證持久化

AOF 模式，因為 AOF 模式的三種配置選項 no、everysec 和 always 都會存在數(shù)據(jù)丟失的情況。所以，事務的持久性屬性也還是得不到保證

總結

redis 的事務機制可以保證一致性和隔離性;但是無法保證持久性;具備了一定的原子性，但不支持回滾

WATCH、EXEC 命令實現(xiàn) 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 實現(xiàn) redis 事務

除了 MULTI、WATCH、EXEC 命令，還有其他的方式可做到 redis 原子性和隔離性嗎?有的，lua 腳本;redis 內(nèi)置了lua的執(zhí)行環(huán)境，并自帶了一些 lua 函數(shù)庫。redis 執(zhí)行 lua 時，會啟動一個偽客戶端去執(zhí)行腳本里的 redis 命令

一致性，原子性，持久性 和 MULTI，EXEC 過程相似：如果 lua 存在錯誤的命令名稱，事務會執(zhí)行失敗。如果在執(zhí)行 redis 命令過程出現(xiàn)異常，之前正常執(zhí)行的命令也不會回滾

lua 腳本被當做一命令集合一起被執(zhí)行，且 redis 是單線處理機制，因此不需要 WATCH 保證隔離性，天然具備隔離性

Lua調(diào)用Redis指令: redis.call("命令名稱"，參數(shù)1，參數(shù)2)

優(yōu)點

減少網(wǎng)絡開銷：可以將多個請求通過腳本的形式一次發(fā)送，減少網(wǎng)絡時延

原子操作：Redis會將整個腳本作為一個整體執(zhí)行，中間不會被其他請求插入。在腳本運行過程中無需擔心會出現(xiàn)競態(tài)條件

可重復使用：客戶端發(fā)送的腳本會永久存在 redis 中，這樣其他客戶端可以復用這一腳本，而不需要使用代碼完成相同的邏輯

搶紅包方案

問題關鍵點

• 一：用戶是否參與過活動，不可重復參與
• 二：紅包數(shù)量有限;而且一個可搶的紅包，保證不能讓多個人同時搶到
• 三：持久化存儲紅包與用戶的關系
• 四：如何保證 步驟一到步驟三的原子性和隔離性

關鍵點一

redis 的集合對象 set 是無序且唯一的。set 集合由整數(shù)集合或字典實現(xiàn)的，添加，刪除，查找的復雜度基本視為 O(1)，存放的最大對象個數(shù)是2^32 - 1 (4294967295)

使用 set 集合保存參加過的用戶，每次用戶參與活動時先判斷是否在 set 里。不在則可以搶紅包

如果是用戶可以重復參與多次的場景，則使用哈希對象，key存用戶對象，value 存放參與次數(shù)。使用 INCR 原子操作增加 value，如果返回數(shù)值 > 上限，說明搶的次數(shù)用完

關鍵點二

使用 list 或者 set 存放事先創(chuàng)建好的有限個紅包;因為 redis 是單線程操作，同一時間，多人搶紅包，只會有一個人成功。而紅包是事先生成的，消費用完即止，不存在超發(fā)的可能

使用 list 列表存放紅包

• 因為紅包金額大小不一，為增加搶到紅包大小的隨機性，需要先shuffle一次，再 LPUSH 入隊列
• RPOP 出隊列一個紅包，如果返回不為nil，則代表獲取成功，繼續(xù)下一步，反之則說明已搶完，返回

set 集合中有兩個指令非常適合在搶紅包、抽獎的場景使用

• SPOP key [count] 移除并返回集合中的一個隨機元素
• SRANDMEMBER key [count] 返回集合中一個或多個隨機數(shù);需要再調(diào) SREM 移除一遍
• 將所有的紅包通過 SADD 添加到 set 中，然后通過隨機命令獲取對應的紅包即可

如果有謝謝惠顧之類的落空選項，生成對應的無效紅包、獎品放入 set 或 list 即可

搶紅包一般是有時效性，正好可以配合 redis 的 key 的失效時間使用。使得搶紅包功能很完美的解決

關鍵點三

使用額外的 list 列表保存用戶與紅包的關系，用戶搶到紅包后，將對應的關系 LPUSH 入隊列，然后服務去消費拉取數(shù)據(jù)批量保存到數(shù)據(jù)庫即可

關鍵點四

使用 lua 腳本實現(xiàn)即可

-- 參數(shù)：KEYS[1]-紅包list，KEYS[2]-用戶和紅包的消費list，KEYS[3]-去重的哈希對象，KEYS[4]-用戶ID 
-- 函數(shù)：嘗試獲得紅包，如果成功，則返回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 

參考文章

redis事務一致性問題?

Redis的ACID屬性

搶紅包設計

騰訊二面：Redis 事務支持 ACID 么?