# 前言 `Redis` 當中提供了許多重要的高階特性，比如釋出與訂閱，`Lua` 指令碼等。`Redis` 當中也提供了自增的原子命令，但是假如我們需要同時執行好幾個命令的同時又想讓這些命令保持原子性，該怎麼辦呢？這時候就可以使用本文介紹的 `Lua` 指令碼來實現。 # 釋出與訂閱 釋出與訂閱功能理論上來說可以直接通過一個雙端連結串列就可以實現了，然而這種通過普通的雙端連結串列來實現的釋出與訂閱功能有兩個侷限性： - 如果生產者生產訊息的速度遠大於消費者消費訊息的速度，那麼連結串列中未消費的訊息會大量堆積，導致佔用大量的記憶體。 - 基於連結串列實現的訊息佇列，不支援一對多的訊息分發。 因為普通雙端連結串列來實現釋出與訂閱功能有這兩個侷限性，故而 `Redis` 當中並沒有直接通過雙端列表來實現。在 `Redis` 中的釋出與訂閱可以分為兩種型別：**基於頻道**和**基於模式**。 ## 基於頻道的實現 基於頻道的實現方式主要通過以下三個命令： - subscribe channel-1 channel-2：訂閱一個或者多個頻道。 - unsubscribe channel-1：取消頻道的訂閱（命令操作介面上無法退訂）。 - publish channel-1 message：向頻道 `channel-1` 傳送訊息 `message`。 開啟一個客戶端 一，輸入訂閱命令 `subscribe music movie`，表示當前客戶端訂閱了 `music` 和 `movie` 兩個頻道的訊息：  然後再開啟一個客戶端二，執行以下發布訊息命令： ```java publish movie myCountry //釋出訊息 myCountry 到 movie 頻道 publish music love //釋出訊息 love 到 music 頻道 publish tv myHome //釋出訊息 myHome 到 tv 頻道 ```  前面兩個頻道釋出之後返回 `1` 就表示當前有 `1` 個客戶端訂閱了該頻道，訊息已經發送到這個客戶端。 這時候我們再回到之前的客戶端一，就會發現客戶端一收到了訊息 `myCountry` 和 `love` 兩條訊息，而 `myHome` 這條訊息是屬於頻道 `tv`，客戶端一併沒有訂閱，故而不會收到：  同時，還有以下 `2` 個命令可以檢視當前客戶端訂閱的頻道資訊： - punsub channels [channel_name] ：檢視當前伺服器被訂閱的頻道。不帶引數則返回所有頻道，後面的引數可以使用萬用字元 `?` 或者 `*`。 - pubsub numsub channel_name [channel_name]：檢視指定頻道的訂閱數（可同時檢視多個）。 ### 實現原理分析 客戶端與其訂閱的頻道資訊被儲存在 `redisServer` 物件中的 `pubsub_channels` 屬性中。 ```c struct redisServer { dict *pubsub_channels;//儲存了客戶端及其訂閱的頻道資訊 //... 省略其他資訊 }; ``` `pubsub_channels` 屬性是一個字典，其 `key` 值儲存的就是頻道名，`value` 是一個連結串列，連結串列中儲存的就是每個客戶端的 `id`，下圖就是基於頻道訂閱的儲存結構示意圖：  - 訂閱 訂閱的時候首先會檢查字典內是否存在這個頻道：如果不存在，則需要為當前頻道建立一個字典，同時建立一個連結串列作為 `value`，並將當前客戶端 `id` 放入連結串列；如果存在，則直接將當前客戶端 `id` 放入連結串列末尾即可。 - 取消訂閱 取消訂閱的時候需要將客戶端 `id` 從對應的連結串列中移除，如果移除之後連結串列為空，則需要同時將該頻道從字典內刪除。 - 傳送訊息 傳送訊息時首先會去 `pubsub_channels` 字典內尋找鍵，如果發現有可以匹配上的鍵，則會找到對應的連結串列，進行遍歷傳送訊息。 ## 基於模式的實現 基於模式的釋出與訂閱實現方式主要通過以下三個命令： - psubscribe pattern-1 pattern-2：訂閱一個或者多個模式，模式可以通過萬用字元 `?` 和 `*` 來表示。 - punsubscribe pattern-1 pattern-1：取消模式的訂閱（基於命令操作，介面上無法退訂） - publish channel-1 message ：向頻道 `channel-1` 傳送訊息 `message`。這裡和上面基於頻道命令是一樣的。 開啟一個客戶端 一，輸入訂閱命令 `psubscribe m*`，表示當前客戶端訂閱了所有以 `m` 開頭的頻道：  然後再開啟一個客戶端二，執行一下發布訊息命令： ```java publish movie myCountry //釋出訊息 myCountry 到 movie 頻道 publish music love //釋出訊息 love 到 music 頻道 publish tv myHome //釋出訊息 myHome 到 tv 頻道 ```  前面兩個頻道釋出之後返回 `1` 就表示當前有 `1` 個客戶端訂閱了該頻道（上面基於頻道訂閱的客戶端關閉之後會自動取消訂閱），訊息已經發送到這個客戶端。 這時候我們再回到之前的客戶端一，就會發現客戶端一收到了 `myCountry` 和 `love` 兩條訊息，因為這兩個頻道都是以 `m` 開頭的，而 `myHome` 這條訊息是屬於頻道 `tv`，並不是以 `m` 開頭，客戶端一併沒有訂閱，故而不會收到：  同樣的，基於模式的訂閱也提供了一個查詢命令： - pubsub numpat：查詢當前伺服器被訂閱模式的數量。 ### 實現原理分析 客戶端與其訂閱的模式資訊被儲存在 `redisServer` 物件中的 `pubsub_patterns` 屬性中。 ```c struct redisServer { list pubsub_patterns;//儲存了客戶端及其訂閱的模式資訊 //...省略其他資訊 }; ``` `pubsub_patterns` 屬性是一個列表，其列表內結構（原始碼 `serer.h` 內）定義如下： ```c typedef struct pubsubPattern { client *client;//訂閱模式的客戶端 robj *pattern;//被訂閱的模式 } pubsubPattern; ```  - 訂閱 新建一個 `pubsubPattern` 資料結構加入到連結串列 `pubsub_patterns` 的結尾。 - 取消訂閱 從連結串列中將當前取消訂閱的客戶端 `pubsubPattern ` 從連結串列 `pubsub_patterns` 中移除 - 傳送訊息 此時需要遍歷整個連結串列來尋找能匹配的模式。之所以基於模式場景使用連結串列是因為模式支援萬用字元，所以沒有辦法直接用字典實現。 PS：當基於頻道和基於模式兩種訂閱同時都存在時，`Redis` 會先去尋找頻道字典，再去遍歷模式連結串列進行訊息傳送。 # Lua 指令碼 `Redis` 從 `2.6` 版本開始支援 `Lua` 指令碼，為了支援 `Lua` 指令碼，`Redis` 在伺服器中嵌入了 `Lua` 環境。 使用 `Lua` 指令碼最大的好處是 `Redis` 會將整個指令碼作為一個整體執行，不會被其他請求打斷，可以保持原子性且減少了網路開銷。 ## Lua 指令碼的呼叫 `Lua` 指令碼的執行語法如下： ```java eval lua-script numkeys key [key ...] arg [arg ...] ``` - eval：執行 `Lua` 指令碼的命令。 - lua-script：`Lua` 指令碼內容。 - numkeys：表示的是 `Lua` 指令碼中需要用到多少個 `key`，如果沒用到則寫 `0`。 - key [key ...]：將 `key` 作為引數按順序傳遞到 `Lua` 指令碼，`numkeys` 是 `0` 時則可省略。 - arg：`Lua` 指令碼中用到的引數，如果沒有可省略。 接下來我們執行一個不帶任何引數的簡單 `Lua` 指令碼命令： ```java eval "return 'Hello Redis'" 0 ```  ### Lua 指令碼中執行 Redis 命令 在 `Lua` 指令碼中執行 `Redis` 命令時需要使用以下語法： ```java redis.call(command, key [key ...] argv [argv…]) ``` - command：`Redis` 中的命令，如 `set`、`get` 等。 - key：操作 `Redis` 中的 `key` 值，相當於我們呼叫方法時的形參。 - param：代表引數，相當於我們呼叫方法時的實參。 假如我們想執行一個命令 `set name lonely_wolf`，那麼利用 `Lua` 指令碼則應該這麼執行： ```java eval "return redis.call('set',KEYS[1],ARGV[1])" 1 name lonely_wolf ```  需要注意的是：**`KEYS` 和 `ARGV` 必須要大寫，引數的下標從 `1` 開始**。上面命令中 `1` 表示當前需要傳遞 `1` 個 `key` ### Lua 指令碼摘要 有時候如果我們執行的一個 `Lua` 指令碼很長的話，那麼直接這麼呼叫 `Lua` 指令碼的話非常不方便，所以 `Redis` 當中提供了一個命令 `script load` 來手動給每一個 `Lua` 指令碼生成摘要，**這裡之所以要說手動的原因是即使我們不使用這個命令，每次呼叫完 `Lua` 指令碼的時候，`Redis` 也會為每個 `Lua` 指令碼生成一個摘要**。 其他相關命令： - `script exists 摘要`：判斷一個摘要是否存在。`0` 表示不存在，`1` 表示存在。 - `script flush`：清除所有 `Lua` 指令碼快取。 接下來我們來驗證一下，依次執行以下命令： ```java script load "return redis.call('set',KEYS[1],ARGV[1])" //給當前 Lua指令碼生成摘要，這時候會返回一個摘要 evalsha "c686f316aaf1eb01d5a4de1b0b63cd233010e63d" 1 address china //相當於執行命令 set address china get address //獲取 adress，確認上面的指令碼是否執行成功 script exists "c686f316aaf1eb01d5a4de1b0b63cd233010e63d" //判斷當前摘要的 Lua指令碼是否存在 script flush //清除所有 Lua指令碼快取 script exists "c686f316aaf1eb01d5a4de1b0b63cd233010e63d" //清除之後這裡就不存在了 ``` 執行之後得到如下效果：  ### Lua 指令碼檔案 當我們的 `Lua` 指令碼很長時，直接在命令視窗中寫指令碼是不直觀的，也很難發現語法問題，所以 `Redis` 當中也支援我們直接把先把指令碼寫入檔案中，然後直接呼叫檔案。 比如我們新建一個 `test.lua` 指令碼： ```lua redis.call('set',KEYS[1],ARGV[1]) return redis.call('get',KEYS[1]) ``` 將檔案上傳到指定目錄之後，執行如下命令： ```java redis-cli --eval test.lua 1 age , 18 //注意 key 和 arg 引數之間要以逗號隔開，且逗號兩邊的空格不能省略 ``` 這時候就可以正常返回 `18`：  ### 指令碼異常 我們知道，`Redis` 的指令是單執行緒執行的，而現在使用了 `Lua` 指令碼，我們就可以通過 `Lua` 指令碼來實現一些業務邏輯，那麼如果 `Lua` 指令碼執行超時或者陷入了死迴圈，這個時候其他的指令就會被阻塞，導致 `Redis` 無法正常使用。這個時候應該如何處理呢？ #### 指令碼超時 為了解決 `Lua` 指令碼超時的問題，`Redis` 提供了一個超時時間的引數 `lua-time-limit` 來控制 `Lua` 指令碼執行的超時時間，單位是毫秒，預設是 `5000` （即 `5` 秒），到達超時時間之後 `Lua` 會自動中斷指令碼。 #### 指令碼陷入死迴圈 假如指令碼陷入了死迴圈，這時候超時時間就不起作用了，我們來模擬一下： 首先開啟客戶端一，執行一個死迴圈的 `lua` 指令碼： ```java eval 'while(true) do end' 0 ```  然後開啟另一個客戶端二，任意執行一個命令： ```java get name ``` 這時候會返回 `busy`，表示當前無法執行這個命令：  提示 `busy` 之後，同時 `Redis` 也給出瞭解決方案，我們只能只用 `script kill` 或者 `shutdown nosave` 命令，這兩個命令又是做什麼用的呢？ - script kill：當指令碼陷入死迴圈之後，執行這個命令可以強制 `Lua` 指令碼中斷執行。這個指令碼的侷限性就是當前陷入死迴圈的 `Lua` 指令碼必須沒有成功執行過命令。 - shutdown nosave：強制退出 `Lua` 指令碼，可以解決 `script kill` 命令的侷限性。 接下來讓我們在客戶端二執行命令 `script kill`，然後再去看看陷入死迴圈的客戶端一的效果：  可以看到，客戶端一的 `Lua` 指令碼已經退出了，根據後面的提示可以知道就是因為執行了 `script kill` 命令而導致了 `Lua` 指令碼的中斷。 現在我們重新用客戶端一執行下面這個 `Lua` 指令碼，這個指令碼和上面的指令碼區別就是這裡執行成功了一個 `Redis` 命令之後才開始死迴圈： ```java eval "redis.call('set','age','28') while true do end" 0 ``` 這時候再去客戶端二執行 `script kill` 命令，發現無法中止 `Lua` 指令碼了：  這裡不允許直接中斷 `Lua` 指令碼是因為在死迴圈前已經有 `Redis` 命令被成功執行了，如果直接中斷，那麼就會造成資料不一致問題。 在這種場景下，只能通過執行 `shutdown nosave` 命令來強行中斷 `Lua` 指令碼，這裡因為加了 `nosave` 之後不會觸發 `Redis` 的持久化，所以當重啟 `Redis` 服務之後，可以保證資料的一致性，下圖就是執行 `shutdown nosave` 命令之後客戶端一的效果圖：  #### 為什麼可以執行 script kill 命令 `Redis` 當中執行命令是單執行緒的，那麼為什麼 `Lua` 指令碼陷入死迴圈之後其他客戶端還可以執行 `script kill` 命令呢？ 這是因為 `Lua` 指令碼引擎提供了鉤子（hook）函式，它允許在內部虛擬機器執行指令時執行鉤子程式碼，所以 `Redis` 正是利用了這一原理，在執行 `Lua` 指令碼之前設定了一個鉤子，也就是說 `script kill` 命令是通過鉤子（hook）函式來執行的。 # 總結 本文主要介紹了 `Redis` 中的釋出訂閱功能和 `Lua` 指令碼的使用，使用 `Lua` 指令碼可以讓多個命令原子執行，減少網路開銷，但是同時也要注意 `Lua` 指令碼引發的死迴圈