Redis 經常使用命令詳解

key 經常使用的命令

跟 key 相關的命令一共有 24 種，這裏只介紹經常使用的。想查看所有命令請參考官網

刪除 key

語法
DEL key1 [key2 ...]

返回值
被刪除 key 的數量。

說明
不存在的 key 會被忽略。(刪除 key 後，對應的 value 也會被刪除)

查看 key 是否存在

語法
EXISTS key1 [key2 ...]

返回值

• 指定單個key時，返回1或0
• 指定多個key時，返回現有key的總數
• 多個 key 相同時，會重複計數。例如 EXISTS somekey 返回1，EXISTS somekey somekey 返回2

說明
從Redis 3.0.3開始，能夠指定多個key

給 key 設置生存時間

在 Redis 中，帶有生存時間的 key 被稱爲 volatile (易丟失)。

當 key 過時時(生存時間爲 0 )，它會被自動刪除。

語法
EXPIRE key1 秒

返回值
設置成功返回 1 。
當 key 不存在或者不能爲 key 設置生存時間時(好比在低於 2.1.3 版本的 Redis 中你嘗試更新 key 的生存時間)，返回 0 。

說明
有些命令會對 key 的生存時間產生影響

• DEL 命令會刪除 key， key 不存在了，生存時間也會被移除
• PERSIST 命令能夠在不刪除 key 的狀況下，移除 key 的生存時間，讓 key 從新成爲一個持久的key 。
• SET 和 GETSET 命令 能夠覆寫 key 和生存時間

若是一個命令只是修改 key 的值而不是用一個新的 key 值來代替它的話，那麼生存時間不會被改變。

例如，如下操做都不會修改 key 自己的生存時間。

• 對一個 key 執行 INCR 命令
• 對一個列表進行 LPUSH 命令
• 或者對一個哈希表執行 HSET 命令

若是使用 RENAME 命令對一個 key 進行更名，那麼更名後的 key 的生存時間和更名前同樣。這句話也適用於如下特殊狀況。

假若有個兩個帶生存時間的 key。

• 第一個key：名稱爲 name1 生存時間爲 10秒
• 第二個key ：名稱爲 name2 生存時間爲 5秒

如今使用 RENAME 命令將 name1 更名爲 name2。因爲 Redis 不容許存在重名的 key，所以 name2 會先被刪除，而後再將 name1 更名爲 name2，值得注意是，更名後的name1生存時間仍是10秒！！！

過時精度

在Redis 2.4中，過時精確存在 0～1秒的時間偏差。

從Redis 2.6開始，過時精確偏差縮小爲0～1毫秒。

Redis 2.1.3 以前

在 Redis 2.1.3 以前的版本中，修改一個帶有生存時間的 key 會致使整個 key 被刪除，這一行爲是受當時複製(replication)層的限制而做出的，Redis 2.1.3 以後，這一限制已經被修復。

Redis 如何過時 key

Redis密鑰使用兩種方式過時 key

• 被動式
• 主動式

被動式
當客戶端訪問 key 時，若是 key 設置了過時時間，會檢查過時時間，若是發現超時，會作超時處理(刪掉key)。

固然，只依賴被動式還不夠，由於有過時的 key 可能永遠不會被訪問，所以Redis會按期主動清理。

主動式
Redis 默認每秒執行10次如下操做

1. 從一組相關聯的帶生存時間的 key中，隨機抽取20個key做爲樣本。
2. 刪除樣本中全部已過時的key。
3. 若是樣本中超過25％的key已過時，從步驟1從新開始。

過時與持久化

Key 的過時時間使用 Unix 時間戳存儲(從 Redis 2.6 開始以毫秒爲單位)。
當你使用 EXPIRE命令給某個 key 設置存活時間爲 60 秒，redis 會把當前時間加 60 秒做爲該 key 的過時時間。這意味着即便 Redis 實例關機，key 的時間也是一直在流逝。

要想處理好 key 的過時的工做，你的計算機時間必須穩定準確！若是你將 RDB 文件在兩臺時間不一樣步的電腦間同步，可能會發生一些有趣的事情，好比全部的 key 在裝載時就會過時

即便正在運行的 redis 實例也會檢查計算機的時鐘，例如若是你設置了一個 key 的存活時間是1000秒，在這瞬間你設置你的計算機時間爲將來的1000秒，這時 key 會當即失效，而不是等1000秒以後。

在複製 AOF 文件時如何處理過時

爲了得到正確的行爲而不犧牲一致性，當一個 key 過時，刪除該 key 的DEL 命令將隨着 AOF 文件，發送給全部的 slaves。在 master 實例中，這種方法是集中的，而且不存在一致性錯誤的機會。

slaves 鏈接到 master 時，不會獨自過時 key，會等到 master 傳輸 DEL 命令，在這期間，過時數據依然在 slave 裏面。