exists——判定 key 是否存在

語(yǔ)法：

exists key [key...]
# 返回值：key 存在的個(gè)數(shù)

針對(duì)多個(gè) key 來(lái)說(shuō)，是非常有用的

時(shí)間復(fù)雜度 O(1)O(1)O(1)

Redis 組織這些 key 就是按照哈希表的方式來(lái)組織的。Redis 支持很多數(shù)據(jù)結(jié)構(gòu)指的是 value 可以是一些復(fù)雜的數(shù)據(jù)結(jié)構(gòu)
Redis 自身的這些鍵值對(duì)，是通過(guò)哈希表的方式來(lái)組織的，Redis 具體的值，又可以是一些數(shù)據(jù)結(jié)構(gòu)

• Redis 是一個(gè)客戶(hù)端-服務(wù)器結(jié)構(gòu)的程序，客戶(hù)端和服務(wù)器之間通過(guò)網(wǎng)絡(luò)來(lái)進(jìn)行通信
• 每次我們敲的命令，都是由 Redis 客戶(hù)端包裝成一個(gè)請(qǐng)求，發(fā)送給 Redis 服務(wù)器，服務(wù)器再返回響應(yīng)
• 因此最好不要把 key 分開(kāi)寫(xiě)。分開(kāi)寫(xiě)會(huì)產(chǎn)生更多輪次的網(wǎng)絡(luò)通信，效率比較低，成本比較高

封裝和分用

• 進(jìn)行網(wǎng)絡(luò)通信的時(shí)候，發(fā)送方發(fā)送一個(gè)數(shù)據(jù)，這個(gè)數(shù)據(jù)就要從應(yīng)用層，到物理層，層層封裝（每一層協(xié)議都要加上報(bào)頭或者尾）==>發(fā)送一個(gè)快遞，要包裝一下，要包裝好多層
• 接收方收到一個(gè)數(shù)據(jù)，這個(gè)數(shù)據(jù)就要從物理層，到應(yīng)用層，層層分用（把每一層協(xié)議中的報(bào)頭或者尾給拆掉）==>收到一個(gè)快遞，要拆快遞，拆很多層
• 這些過(guò)程都是要消耗時(shí)間，消耗 CPU 的

Redis 自身也非常清楚上述問(wèn)題，所以 Redis 的很多命令都支持一次就能操作多個(gè) key 的/多種操作

del——刪除指定的 key

可以一次刪除一個(gè)或者多個(gè)

語(yǔ)法：

del key [key...]

• 時(shí)間復(fù)雜度 O(1)O(1)O(1)
• 返回值：刪除掉的 key 的個(gè)數(shù)

在 MySQL 中，刪除類(lèi)的操作

• drop database
• drop table
• drop from…
  這些都是非常危險(xiǎn)的操作，一旦刪除之后，數(shù)據(jù)就沒(méi)了。但在 Redis 中，危險(xiǎn)程度就小很多了
• 因?yàn)?Redis 的主要應(yīng)用場(chǎng)景，就是作為緩存，里面存的只是一個(gè)熱點(diǎn)數(shù)據(jù)，而全量數(shù)據(jù)是在 MySQL 中。如果把 Redis 中的 key 刪除了幾個(gè)，問(wèn)題不大，大不了再?gòu)?MySQL 中讀就可以了。
• 但是如果把所有的數(shù)據(jù)，或者一大半數(shù)據(jù)都干沒(méi)了，這種影響就會(huì)很大。本來(lái)是靠 Redis 幫 MySQL 負(fù)重前行，Redis 沒(méi)數(shù)據(jù)了，大部分請(qǐng)求就直接打給 MySQL 了，然后就容易把 MySQL 搞掛
• 相比之下，如果是 MySQL 這樣的數(shù)據(jù)，哪怕誤刪了一個(gè)數(shù)據(jù)，都可能影響是很大的
• 但如果是把 Redis 作為數(shù)據(jù)庫(kù)，此時(shí)誤刪數(shù)據(jù)的影響就大了

expire——給 key 設(shè)置過(guò)期時(shí)間

單位為秒

key 存活時(shí)間超過(guò)這個(gè) expire 指定的值，就會(huì)被自動(dòng)刪除

• 在很多業(yè)務(wù)場(chǎng)景，都是有時(shí)間限制的
  • 驗(yàn)證碼。要實(shí)現(xiàn)驗(yàn)證碼一分鐘失效的功能，我們就可以把這個(gè)驗(yàn)證碼信息存儲(chǔ)到 Redis 中，將 expire 設(shè)置為 60，等到一分鐘后 Redis 里面的驗(yàn)證碼信息被刪除，就查詢(xún)不到了
  • 點(diǎn)外賣(mài)。優(yōu)惠券，在指定時(shí)間有效
  • 分布式鎖?；?Redis 實(shí)現(xiàn)分布式鎖，為了避免出現(xiàn)不能正確解鎖的情況，通常都會(huì)在加鎖的時(shí)候設(shè)置一下過(guò)期事假（所謂的使用 Redis 作為分布式鎖，就是給 Redis 里寫(xiě)一個(gè)特殊的 key value）

語(yǔ)法：

expire key seconds
pexpire key 毫秒

• 對(duì)于計(jì)算機(jī)來(lái)說(shuō)，秒是一個(gè)非常長(zhǎng)的時(shí)間，下面的時(shí)間單位是毫秒

ttl——查詢(xún)過(guò)期時(shí)間

time to live

在網(wǎng)絡(luò)原理，IP 協(xié)議報(bào)頭中，就有一個(gè) TTL 字段

• IP 中的 TTL 不是用時(shí)間衡量過(guò)期的，而是次數(shù)

查詢(xún)當(dāng)前 key 的過(guò)期時(shí)間還剩多少
語(yǔ)法：

ttl key    //秒
pttl key   //毫秒

• 返回剩余過(guò)期時(shí)間
• 返回 -1 表示沒(méi)有關(guān)聯(lián)過(guò)期時(shí)間
• 返回 -2 表示 key 不存在

過(guò)期策略是如何實(shí)現(xiàn)的

#高頻面試
一個(gè) Redis 中可能同時(shí)存在很多很多 key，這些 key 中有很大一部分都有過(guò)期時(shí)間。此時(shí)，Redis 服務(wù)器怎么知道哪些 key 已經(jīng)過(guò)期要被刪除，哪些 key 還沒(méi)過(guò)期？

• 如果直接遍歷所有的 key，顯然是行不通的，效率非常低
• Redis 整體的策略是兩方面
  1. 定期刪除
  2. 惰性刪除

惰性刪除

• 假設(shè)這個(gè) key 已經(jīng)到達(dá)過(guò)期時(shí)間了，但是暫時(shí)還沒(méi)刪除它，key 還在
• 緊接著，后面又一次訪問(wèn)，正好用到了這個(gè) key，于是這次訪問(wèn)就會(huì)讓 Redis 服務(wù)器觸發(fā)刪除 key 的操作，同時(shí)再放回一個(gè) nil

• 你去超市買(mǎi)水，正要付錢(qián)的時(shí)候，看了一眼日期，發(fā)現(xiàn)過(guò)期了，于是老板就說(shuō)不賣(mài)了，于是就把這瓶水下架了，這就是“惰性刪除”
• 老板也不清楚哪些過(guò)期了，哪些沒(méi)過(guò)期，就在賣(mài)出的時(shí)候做一次檢查，如果過(guò)期了就不賣(mài)了，如果還沒(méi)過(guò)期，就繼續(xù)賣(mài)

但顯然，單靠惰性刪除肯定是不靠譜的，一個(gè)超市這么多商品，怎么可能全去靠用戶(hù)去檢查，所以肯定還得要有一個(gè)輔助的機(jī)制——定期刪除

定期刪除

這個(gè)超市老板，要定期查看超市里面的商品，看是否有過(guò)期產(chǎn)品

• 但是如果超市商品很多，那么每次遍歷一遍就非常慢
• 所以，每次抽取一部分，進(jìn)行驗(yàn)證過(guò)期時(shí)間。保證抽取檢查的過(guò)程足夠快

為什么這對(duì)定期刪除的時(shí)間有明確的要求呢？

• 因?yàn)?Redis 是單線(xiàn)程程序，主要的任務(wù)是處理每個(gè)命令的任務(wù)（剛才掃描過(guò)期 key…）
• 如果掃描過(guò)期 key 消耗的時(shí)間太多了，就可能導(dǎo)致正常處理請(qǐng)求命令就被阻塞了（產(chǎn)生了類(lèi)似 key * 的效果）

雖然有了上述兩種策略結(jié)合，但整體的效果仍一般。仍然有可能會(huì)有很多過(guò)期的 key 被殘留了，沒(méi)有及時(shí)刪除掉

但是 Redis 為了對(duì)上述進(jìn)行補(bǔ)充，還提供了一系列的內(nèi)存淘汰策略

到此這篇關(guān)于redis中全局命令exists、del、expire、ttl(惰性刪除和定期刪除)的文章就介紹到這了,更多相關(guān)redis 全局命令exists、del、expire、ttl內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！