鍵空間通知（keyspace notification）_鍵空間

Redis鍵空間通知（keyspace notification）

本文檔翻譯自： http://redis.io/topics/notifications 。

鍵空間通知功能目前仍在開發中，這個文檔所描述的內容，以及功能的具體實現，可能會在未來數周內改變，敬請知悉。 功能概覽

鍵空間通知使得用戶端可以通過訂閱頻道或模式， 來接收那些以某種方式改動了 Redis 資料集的事件。

以下是一些鍵空間通知發送的事件的例子： 所有修改鍵的命令。 所有接收到 LPUSH 命令的鍵。 0 號資料庫中所有已到期的鍵。

事件通過 Redis 的訂閱與發布功能（pub/sub）來進行分發， 因此所有支援訂閱與發布功能的用戶端都可以在無須做任何修改的情況下， 直接使用鍵空間通知功能。

因為 Redis 目前的訂閱與發布功能採取的是發送即忘（fire and forget）策略， 所以如果你的程式需要可靠事件通知（reliable notification of events）， 那麼目前的鍵空間通知可能並不適合你： 當訂閱事件的用戶端斷線時， 它會丟失所有在斷線期間分發給它的事件。

未來將會支援更可靠的事件分發， 這種支援可能會通過讓訂閱與發布功能本身變得更可靠來實現， 也可能會在 Lua 指令碼中對訊息（message）的訂閱與發布進行監聽， 從而實作類別似將事件推入到列表這樣的操作。 事件的類型

對於每個修改資料庫的操作，鍵空間通知都會發送兩種不同類型的事件。

比如說，對 0 號資料庫的鍵 mykey 執行 DEL 命令時， 系統將分發兩條訊息， 相當於執行以下兩個 PUBLISH 命令：

PUBLISH __keyspace@0__:mykey delPUBLISH __keyevent@0__:del mykey

訂閱第一個頻道 __keyspace@0__:mykey 可以接收 0 號資料庫中所有修改鍵 mykey 的事件， 而訂閱第二個頻道 __keyevent@0__:del 則可以接收 0 號資料庫中所有執行 del 命令的鍵。

以 keyspace 為首碼的頻道被稱為鍵空間通知（key-space notification）， 而以 keyevent 為首碼的頻道則被稱為鍵事件通知（key-event notification）。

當 del mykey 命令執行時： 鍵空間頻道的訂閱者將接收到被執行的事件的名字，在這個例子中，就是 del 。 鍵事件頻道的訂閱者將接收到被執行事件的鍵的名字，在這個例子中，就是 mykey 。 配置

因為開啟鍵空間通知功能需要消耗一些 CPU ， 所以在預設配置下， 該功能處於關閉狀態。

可以通過修改 redis.conf 檔案， 或者直接使用 CONFIG SET 命令來開啟或關閉鍵空間通知功能： 當 notify-keyspace-events 選項的參數為空白字串時，功能關閉。 另一方面，當參數不是Null 字元串時，功能開啟。

notify-keyspace-events 的參數可以是以下字元的任意組合， 它指定了伺服器該發送哪些類型的通知： 字元 發送的通知 K 鍵空間通知，所有通知以 __keyspace@<db>__ 為首碼 E 鍵事件通知，所有通知以 __keyevent@<db>__ 為首碼 g DEL 、 EXPIRE 、 RENAME 等類型無關的通用命令的通知 $ 字串命令的通知 l 列表命令的通知 s 集合命令的通知 h 雜湊命令的通知 z 有序集合命令的通知 x 到期事件：每當有到期鍵被刪除時發送 e 驅逐(evict)事件：每當有鍵因為 maxmemory 政策而被刪除時發送 A 參數 g$lshzxe 的別名

輸入的參數中至少要有一個 K 或者 E ， 否則的話， 不管其餘的參數是什麼， 都不會有任何通知被分發。

舉個例子， 如果只想訂閱鍵空間中和列表相關的通知， 那麼參數就應該設為 Kl ， 諸如此類。

將參數設為字串 "AKE" 表示發送所有類型的通知。 命令產生的通知

以下列表記錄了不同命令所產生的不同通知： DEL 命令為每個被刪除的鍵產生一個 del 通知。 RENAME 產生兩個通知：為來源鍵（source key）產生一個 rename_from 通知，並為目標鍵（destination key）產生一個 rename_to 通知。 EXPIRE 和 EXPIREAT 在鍵被正確設定到期時間時產生一個 expire 通知。當 EXPIREAT 設定的時間已經到期，或者 EXPIRE 傳入的時間為負數值時，鍵被刪除，併產生一個 del 通知。 SORT 在命令帶有 STORE 參數時產生一個 sortstore 事件。如果 STORE 指示的用於儲存排序結果的鍵已經存在，那麼程式還會發送一個 del 事件。 SET 以及它的所有變種（SETEX 、 SETNX 和 GETSET）都產生 set 通知。其中 SETEX 還會產生 expire 通知。 MSET 為每個鍵產生一個 set 通知。 SETRANGE 產生一個 setrange 通知。 INCR 、 DECR 、 INCRBY 和 DECRBY 都產生 incrby 通知。 INCRBYFLOAT 產生 incrbyfloat 通知。 APPEND 產生 append 通知。 LPUSH 和 LPUSHX 都產生單個 lpush 通知，即使有多個輸入元素時，也是如此。 RPUSH 和 RPUSHX 都產生單個 rpush 通知，即使有多個輸入元素時，也是如此。 RPOP 產生 rpop 通知。如果被彈出的元素是列表的最後一個元素，那麼還會產生一個 del 通知。 LPOP 產生 lpop 通知。如果被彈出的元素是列表的最後一個元素，那麼還會產生一個 del 通知。 LINSERT 產生一個 linsert 通知。 LSET 產生一個 lset 通知。 LTRIM 產生一個 ltrim 通知。如果 LTRIM 執行之後，列表鍵被清空，那麼還會產生一個 del 通知。 RPOPLPUSH 和 BRPOPLPUSH 產生一個 rpop 通知，以及一個 lpush 通知。兩個命令都會保證 rpop 的通知在 lpush 的通知之前分發。如果從鍵彈出元素之後，被彈出的列表鍵被清空，那麼還會產生一個 del 通知。 HSET 、 HSETNX 和 HMSET 都只產生一個 hset 通知。 HINCRBY 產生一個 hincrby 通知。 HINCRBYFLOAT 產生一個 hincrbyfloat 通知。 HDEL 產生一個 hdel 通知。如果執行 HDEL 之後，雜湊鍵被清空，那麼還會產生一個 del 通知。 SADD 產生一個 sadd 通知，即使有多個輸入元素時，也是如此。 SREM 產生一個 srem 通知，如果執行 SREM 之後，集合鍵被清空，那麼還會產生一個 del 通知。 SMOVE 為來源鍵（source key）產生一個 srem 通知，並為目標鍵（destination key）產生一個 sadd 事件。 SPOP 產生一個 spop 事件。如果執行 SPOP 之後，集合鍵被清空，那麼還會產生一個 del 通知。 SINTERSTORE 、 SUNIONSTORE 和 SDIFFSTORE 分別產生 sinterstore 、 sunionostore 和 sdiffstore 三種通知。如果用於儲存結果的鍵已經存在，那麼還會產生一個 del 通知。 ZINCRBY 產生一個 zincr 通知。（譯註：非對稱，請注意。） ZADD 產生一個 zadd 通知，即使有多個輸入元素時，也是如此。 ZREM 產生一個 zrem 通知，即使有多個輸入元素時，也是如此。如果執行 ZREM 之後，有序集合鍵被清空，那麼還會產生一個 del 通知。 ZREMRANGEBYSCORE 產生一個 zrembyscore 通知。（譯註：非對稱，請注意。）如果用於儲存結果的鍵已經存在，那麼還會產生一個 del 通知。 ZREMRANGEBYRANK 產生一個 zrembyrank 通知。（譯註：非對稱，請注意。）如果用於儲存結果的鍵已經存在，那麼還會產生一個 del 通知。 ZINTERSTORE 和 ZUNIONSTORE 分別產生 zinterstore 和 zunionstore 兩種通知。如果用於儲存結果的鍵已經存在，那麼還會產生一個 del 通知。 每當一個鍵因為到期而被刪除時，產生一個 expired 通知。 每當一個鍵因為 maxmemory 政策而被刪除以回收記憶體時，產生一個 evicted 通知。

所有命令都只在鍵真的被改動了之後，才會產生通知。

比如說，當 SREM 試圖刪除不存在於集合的元素時，刪除操作會執行失敗，因為沒有真正的改動鍵，所以這一操作不會發送通知。

如果對命令所產生的通知有疑問， 最好還是使用以下命令， 自己來驗證一下：

$ redis-cli config set notify-keyspace-events KEA$ redis-cli --csv psubscribe '__key*__:*'Reading messages... (press Ctrl-C to quit)"psubscribe","__key*__:*",1

然後， 只要在其他終端裡用 Redis 用戶端發送命令， 就可以看到產生的通知了：

"pmessage","__key*__:*","__keyspace@0__:foo","set""pmessage","__key*__:*","__keyevent@0__:set","foo"...

到期通知的發送時間

Redis 使用以下兩種方式刪除到期的鍵： 當一個鍵被訪問時，程式會對這個鍵進行檢查，如果鍵已經到期，那麼該鍵將被刪除。 底層系統會在後台漸進地尋找並刪除那些到期的鍵，從而處理那些已經到期、但是不會被訪問到的鍵。

當到期鍵被以上兩個程式的任意一個發現、 並且將鍵從資料庫中刪除時， Redis 會產生一個 expired 通知。

Redis 並不保證存留時間（TTL）變為 0 的鍵會立即被刪除： 如果程式沒有訪問這個到期鍵， 或者帶有存留時間的鍵非常多的話， 那麼在鍵的存留時間變為 0 ， 直到鍵真正被刪除這中間， 可能會有一段比較顯著的時間間隔。

因此， Redis 產生 expired 通知的時間為到期鍵被刪除的時候， 而不是鍵的存留時間變為 0 的時候。

from: http://redisdoc.com/topic/notification.html