?摘要：利用 Redis 實作房間業務管理的實踐與思考，

文｜即構業務后臺開發團隊

在一些互動場景中，比如語音聊天室、電商直播等，成員控制、連麥、獻花、發彈幕等互動功能，通常要求后臺服務器能夠儲存管理房間及房間內成員的資料，

那么如何組織、存盤、操作這些資料以完成既定的業務，并且還要同時保證服務器和客戶端之間的資料一致性，是實作這類音視頻互動場景的業務后臺需要考慮的問題之一，

RoomKit 作為即構科技推出的一款全新形態 LCEP（Low-code Engagement Platform）產品，高度抽象了音視頻通話、白板涂鴉、檔案演示、實時訊息等通用能力，模塊功能可以任意組裝，讓用戶用低/零碼的方式可完成多個業務場景搭建，所以在 Roomkit 這款產品的后臺邏輯中，房間資料管理作為業務的核心部分，貫穿了整個開發程序，

Redis 作為一款高性能 kv 資料庫，在后臺開發中應用十分廣泛，Roomkit 后臺我們也使用了 Redis 進行房間資料管理，

那么本文我們就來看下，即構后臺開發團隊在利用 Redis 實作業務時遇到的技術難點和解決方案，讀者在使用即構 aPaaS 層實作自己的業務遇到相似的問題時，也可以參考本文進行解決，

一、Roomkit 后臺整體介紹

1、功能模塊劃分

根據業務邏輯，RoomKit 將代碼劃分為房間控制模塊和功能插件模塊兩大模塊，下面為大家詳細介紹這些模塊的功能，

房間控制模塊

房間控制模塊主要用于管理房間串列、房間狀態、房間內成員的狀態互動，

RoomKit 適用的場景多種多樣，大班課、直播、小班課、視頻會議、1v1，但實際這些場景可以劃分為類視頻會議場景和類直播場景，

這兩個場景的邏輯側重各不相同，類視頻會議場景參與成員相對較少，但是成員之間互動很頻繁；而類直播場景參與人數一般較多，但是主播與聽眾互動相對較少，基于這個標準 RoomKit 后臺又將房間控制模塊又劃分為兩個子模塊，由于與本文主題無關，這里不再展開描述，

功能插件模塊

功能插件模塊指的是與 RoomKit 支持的插件功能，如共享、教學插件、IM 等，其邏輯與場景無關，均可作為獨立模塊進行開發，與房間控制模塊的互動通過相互提供 handler 完成，

2、后臺服務架構

RoomKit 后臺基于 Redis 管理房間資料，并利用即構信令后臺提供的即時推送能力，向客戶端實時推送房間狀態變化通知，下圖是后臺與其他服務和客戶端之間的架構關系，

二、利用 Redis 管理房間資料的關鍵技術

下面我們主要以【房間控制模塊】為例，介紹 Roomkit 后臺在利用 Redis 實作房間業務時的一些關鍵點，

1、利用 Redis 儲存房間資料

為了實作房間內的互動功能，Roomkit 后臺需要記錄房間、成員等狀態資訊，為了在業務服務器程式之間共享這些資料，我們選擇將資料儲存在 Redis 中，

Redis 的 hash 結構天然的可以用于記錄房間狀態等資料，對房間的設定，如開始上課操作，只需要更改對應的 field 即可，

而為了能夠跟蹤到當前處于打開狀態的房間，Roomkit 后臺將房間 ID 和創建時間記錄到一個全域的 ZSET 中，后臺會定時遍歷這些房間以處理統計資料、檢查離線成員等，

房間內成員狀態同樣會記錄在一個 hash 結構中，而成員 ID 會被記錄在與房間 ID 對應的 ZSET中，其中 score 為成員登陸或上次心跳時間，成員每次心跳都會更新 score 到當前時間，

利用 ZSET 按 score 排序的特性，后臺可以很容易的篩選出離線的成員并移出房間，

2、Redis key 無過期時間設計

在撰寫代碼的程序中，我們經常會遇到記憶體泄漏的問題，而在利用 Redis 儲存資料的時候，同樣也會存在key泄漏的問題，Redis 在作為 cache 中間件使用時，為了避免 key 泄漏，通常都會對 key 設定過期時間，但是在 Roomkit 中，房間資料銷毀是在房間結束時發生的，而房間結束時間是由成員控制的，設定過短的 ttl 會導致資料丟失，而設定太長的 ttl 實際上會導致 Redis 的 key 泄漏問題，

針對這個問題，Roomkit 后臺采用了無過期時間設計，也就是不對 key 設定 ttl，

為了防止 key 泄漏，在 Roomkit 后臺中，每一個動態創建的 key 都會被記錄在一些固定的 key 中，在進行銷毀的時候，從這些固定的key出發，就可以索引到所有的 key 了，

例如在共享模塊中，為了能在成員退出房間時關閉該成員的共享內容，會在成員創建共享內容的同時，創建一個 key 為 personal_share:{uid} 的 SET 結構以記錄這個成員創建的共享內容，而這個 key 自身則會被記錄到另一個 key 為 share_recycle_bin 的 SET 結構中，

這樣在房間結束時，通過獲取并洗掉 cycle_bin 中記錄的 key，達到清理資料的目的，

local keys=redis.call("SMEMBERS","share_recycle_bin")
redis.call("DEL",unpack(keys))

另外為了避免要回收的 key 過多導致的 Redis 執行阻塞過長，Roomit 在洗掉時還做了分批處理的優化，

3、多機協作遍歷任務串列

為了實作對每個房間的檢查和統計，需要定時遍歷房間串列，從中取出需要檢查的房間進行業務定義的檢查，如果串列很長，僅憑單機完成檢查作業需要較長的時間，在單機編程環境下，這類問題我們通常會使用執行緒池等技術解決，

而在多機環境下，我們會期望將這些任務均衡的攤派到各個服務器上，這就需要各個服務器之間進行協作，

Roomkit 后臺利用 Redis 的單執行緒執行特性和 zscan 機制實作了分布式協作遍歷，

簡要實作如下：

local now = tonumber(redis.call("TIME")[1])
local cursor = redis.call("GET","cursor_key") 
if cursor=="0" then 
    local next_check_time = redis.call("GET","next_check_time_key") 
    if tonumber(next_check_time)>now then 
        return next_check_time-now 
    end
end
local scan_result = redis.call("ZSCAN","room_zset_key",cursor) 
redis.call("SET","cursor_key",scan_result[1]) 
if scan_result[1]=="0" then redis.call("SET","next_check_time_key",now+scan_interval) end 
return scan_result[2]

單個節點執行遍歷時，使用 ZSCAN 命令獲取一批需要檢查的房間號，并將回傳的 cursor 值更新到全域 cursor 上，如果 cursor 為 0，表示遍歷完畢，這時候會設定下一次開始遍歷的時間，在每次執行遍歷時會檢查這個時間，如果沒有到開始時間，則回傳，

房間遍歷邏輯不與客戶端直接互動，且支持水平擴容，實際部署上可以作為獨立的功能組件使用，根據業務負載情況動態調整 worker 數量，

4、seq 與最終一致性

在強互動場景下，保持客戶端與服務器的資料一致性是非常重要的，否則就會出現狀態錯亂的情況，影響互動效果，所以我們采用了 seq 機制來保證資料變動的邏輯順序，

事實上我們可以把客戶端本地所持房間內資料看作是后臺所持房間資料的副本，這樣客戶端(視為 follower ) 和后臺 (視為 leader ) 就可以看作一個分布式的資料儲存系統，

Roomkit 后臺在對資料進行變更后，需要通過信令后臺提供的房間內廣播能力，向所有的客戶端推送變更通知，通知包括變更事件和變更的詳細資料，使得客戶端與服務器保持一致，

但是客戶端所處網路情況是非常復雜的，在弱網情況下可能存在通知丟失、亂序的情況，而通知的丟失和亂序會導致成員和房間狀態例外，

由于弱網情況不可避免，為了保證客戶端本地所持資料最終能夠與后臺資料一致，Roomkit 在每條通知上加上了一個用于校驗的 seq 號，當后臺資料狀態發生變更時，seq 都會進行自增，因此 seq 實際上代表了后臺資料的版本號，

客戶端在首次進入房間時會拉取全量資料及相應的 seq ，然后通過通知里的資料對本地資料進行增量更新，并推進 seq，另外在客戶端心跳時，后臺也會回傳最新的 seq ，客戶端在發現本地的 seq 與心跳回傳的 seq 不一致時，將再次拉取全量資料來與后臺保持資料一致，

利用 seq 還可以避免一些全體操作導致的通知過長問題，

例如在小班課中進行全體閉麥操作，如果將所有人的變更都放到通知中，會因為訊息過長而無法發送，因此后臺針對這樣的全體操作通知進行了優化，僅發送事件本身，不發送變更資料，客戶端在接收到通知后，首先核對 seq 是否是本地seq 的下一 seq ，如果是，則認為全體操作作用的資料是與后臺一致的，可以在本地進行操作重放，使資料變更到與后臺一致，否則就需要拉取全域資料進行覆寫，

5、CAS 操作

競態條件是在并發編程中最常見的問題，而這在多機環境下也是可能出現的，通常使用 Redis lua 等臨界區技術可以避免這個問題，但是如果業務流不能在一個臨界區內執行完怎么辦？這時我們就需要使用 CAS 操作，

Roomkit 后臺在一些復雜邏輯的實作上使用了 Redis 的 lua 腳本機制，但是眾所周知，Redis 是單執行緒執行的，如果 lua 腳本比較復雜，會導致執行時間過長，阻塞其他命令執行，因此Roomkit 后臺對部分過長的 lua 進行了拆分，并利用 CAS 避免競態條件，

例如在演講模式中，后臺會將房間狀態 hash 結構中 speaker 欄位的值設定為當前主講人的成員 ID ；如果主講人直接退出房間，后臺在處理通用成員退出邏輯的同時，還要選擇一個在線成員設定為主講人，而選擇下一主講人的邏輯較為復雜，如果放到成員退出邏輯中一起執行，可能會導致執行阻塞；而如果分為兩個 lua 腳本執行，則有可能出現這樣一種情況：在成員退出腳本執行完畢、設定主講人腳本開始執行之前，有另外一個設定主講人的請求到達后端并成功執行，這時候如果再執行設定主講人腳本，將會覆寫設定主講人的請求，導致客戶端的例外表現，

解決方案一：利用CAS，在執行設定主講人腳本時，首先查看 speaker 欄位的值是否已經改變，如果已經改變則放棄執行，

local speaker=redis.call("HGET","room_stat_key","speaker")
if speaker~=left_speaker_id then return end
-- select next speaker...

這個解決方案仍然有個缺陷：在設定主講人腳本開始執行之前行程 crash 了，這時候主講人欄位的值將不會改變，這就導致成員已退出房間，但主講人仍然是該成員這樣邏輯不一致的系統狀態，

解決方案二：在成員退出腳本中，將 speaker 欄位置為初始值也就是空值，代表目前沒有主講人，這樣如果遇到行程crash 等情況，雖然無法執行設定主講人腳本，系統仍然可以保持邏輯一致，

這樣設定主講人腳本邏輯就變更為查看 speaker 欄位的值是否為空值，如果不是則放棄執行，

-- user left script
--...
local speaker=redis.call("HSET","room_stat_key","speaker","")
--...
?
-- set speaker script
--...
local speaker=redis.call("HGET","room_stat_key","speaker")
if speaker~="" then return end
-- select next speaker...