前言

最近在學(xué)習(xí)Redis相關(guān)知識，看了阿里的redis開發(fā)規(guī)范，以及Redis開發(fā)與運(yùn)維這本書。分使用規(guī)范、有坑的命令、項(xiàng)目實(shí)戰(zhàn)操作、運(yùn)維配置四個(gè)方向，整理了使用Redis的21個(gè)注意點(diǎn)，希望對大家有幫助，一起學(xué)習(xí)哈

1、Redis的使用規(guī)范

1.1、 key的規(guī)范要點(diǎn)

我們設(shè)計(jì)Redis的key的時(shí)候，要注意以下這幾個(gè)點(diǎn)：

以業(yè)務(wù)名為key前綴，用冒號隔開，以防止key沖突覆蓋。如，live1

確保key的語義清晰的情況下，key的長度盡量小于30個(gè)字符。

key禁止包含特殊字符，如空格、換行、單雙引號以及其他轉(zhuǎn)義字符。

Redis的key盡量設(shè)置ttl，以保證不使用的Key能被及時(shí)清理或淘汰。

?

1.2、value的規(guī)范要點(diǎn)

Redis的value值不可以隨意設(shè)置的哦。

「第一點(diǎn)」，如果大量存儲bigKey是會有問題的，會導(dǎo)致慢查詢，內(nèi)存增長過快等等。

如果是String類型，單個(gè)value大小控制10k以內(nèi)。

如果是hash、list、set、zset類型，元素個(gè)數(shù)一般不超過5000。

「第二點(diǎn)」，要選擇適合的數(shù)據(jù)類型。不少小伙伴只用Redis的String類型，上來就是set和get。實(shí)際上，Redis 提供了「豐富的數(shù)據(jù)結(jié)構(gòu)類型」，有些業(yè)務(wù)場景，更適合hash、zset等其他數(shù)據(jù)結(jié)果。

「反例：」

setusernamejay setuserage18

「正例」

hmsetuser:666namejayage18

1.3. 給Key設(shè)置過期時(shí)間，同時(shí)注意不同業(yè)務(wù)的key，盡量過期時(shí)間分散一點(diǎn)

因?yàn)镽edis的數(shù)據(jù)是存在內(nèi)存中的，而內(nèi)存資源是很寶貴的。

我們一般是把Redis當(dāng)做緩存來用，而「不是數(shù)據(jù)庫」，所以key的生命周期就不宜太長久啦。

因此，你的key，一般建議用「expire設(shè)置過期時(shí)間」。

如果大量的key在某個(gè)時(shí)間點(diǎn)集中過期，到過期的那個(gè)時(shí)間點(diǎn)，Redis可能會存在卡頓，甚至出現(xiàn)「緩存雪崩」現(xiàn)象，因此一般不同業(yè)務(wù)的key，過期時(shí)間應(yīng)該分散一些。有時(shí)候，同業(yè)務(wù)的，也可以在時(shí)間上加一個(gè)隨機(jī)值，讓過期時(shí)間分散一些。

1.4.建議使用批量操作提高效率

我們?nèi)粘慡QL的時(shí)候，都知道，批量操作效率會更高，一次更新50條，比循環(huán)50次，每次更新一條效率更高。其實(shí)Redis操作命令也是這個(gè)道理。

Redis客戶端執(zhí)行一次命令可分為4個(gè)過程：1.發(fā)送命令-> 2.命令排隊(duì)-> 3.命令執(zhí)行-> 4. 返回結(jié)果。1和4 稱為RRT（命令執(zhí)行往返時(shí)間）。Redis提供了「批量操作命令，如mget、mset」等，可有效節(jié)約RRT。但是呢，大部分的命令，是不支持批量操作的，比如hgetall，并沒有mhgetall存在。「Pipeline」則可以解決這個(gè)問題。

Pipeline是什么呢?它能將一組Redis命令進(jìn)行組裝，通過一次RTT傳輸給Redis，再將這組Redis命令的執(zhí)行結(jié)果按順序返回給客戶端.

我們先來看下沒有使用Pipeline執(zhí)行了n條命令的模型：

使用Pipeline執(zhí)行了n次命令，整個(gè)過程需要1次RTT，模型如下：

2、Redis 有坑的那些命令

2.1. 慎用O(n)復(fù)雜度命令，如hgetall、smember，lrange等

因?yàn)镽edis是單線程執(zhí)行命令的。hgetall、smember等命令時(shí)間復(fù)雜度為O(n)，當(dāng)n持續(xù)增加時(shí)，會導(dǎo)致 Redis CPU 持續(xù)飆高，阻塞其他命令的執(zhí)行。

hgetall、smember，lrange等這些命令不是一定不能使用，需要綜合評估數(shù)據(jù)量，明確n的值，再去決定。比如hgetall，如果哈希元素n比較多的話，可以優(yōu)先考慮使用「hscan」。

2.2 慎用Redis的monitor命令

Redis Monitor 命令用于實(shí)時(shí)打印出Redis服務(wù)器接收到的命令，如果我們想知道客戶端對redis服務(wù)端做了哪些命令操作，就可以用Monitor 命令查看，但是它一般「調(diào)試」用而已，盡量不要在生產(chǎn)上用！因?yàn)椤竚onitor命令可能導(dǎo)致redis的內(nèi)存持續(xù)飆升。」

monitor的模型是醬紫的，它會將所有在Redis服務(wù)器執(zhí)行的命令進(jìn)行輸出，一般來講Redis服務(wù)器的QPS是很高的，也就是如果執(zhí)行了monitor命令，Redis服務(wù)器在Monitor這個(gè)客戶端的輸出緩沖區(qū)又會有大量“存貨”，也就占用了大量Redis內(nèi)存。

2.3、生產(chǎn)環(huán)境不能使用 keys指令

Redis Keys 命令用于查找所有符合給定模式pattern的key。如果想查看Redis 某類型的key有多少個(gè)，不少小伙伴想到用keys命令，如下：

keyskey前綴*

但是，redis的keys是遍歷匹配的，復(fù)雜度是O（n），數(shù)據(jù)庫數(shù)據(jù)越多就越慢。我們知道，redis是單線程的，如果數(shù)據(jù)比較多的話，keys指令就會導(dǎo)致redis線程阻塞，線上服務(wù)也會停頓了，直到指令執(zhí)行完，服務(wù)才會恢復(fù)。因此，「一般在生產(chǎn)環(huán)境，不要使用keys指令」。官方文檔也有聲明：

Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use KEYS in your regular application code. If you're looking for a way to find keys in a subset of your keyspace, consider using sets.

其實(shí)，可以使用scan指令，它同keys命令一樣提供模式匹配功能。它的復(fù)雜度也是 O(n)，但是它通過游標(biāo)分步進(jìn)行，「不會阻塞redis線程」;但是會有一定的「重復(fù)概率」，需要在「客戶端做一次去重」。

scan支持增量式迭代命令，增量式迭代命令也是有缺點(diǎn)的：舉個(gè)例子， 使用 SMEMBERS 命令可以返回集合鍵當(dāng)前包含的所有元素， 但是對于 SCAN 這類增量式迭代命令來說， 因?yàn)樵趯︽I進(jìn)行增量式迭代的過程中， 鍵可能會被修改， 所以增量式迭代命令只能對被返回的元素提供有限的保證 。

2.4 禁止使用flushall、flushdb

Flushall 命令用于清空整個(gè) Redis 服務(wù)器的數(shù)據(jù)(刪除所有數(shù)據(jù)庫的所有 key )。

Flushdb 命令用于清空當(dāng)前數(shù)據(jù)庫中的所有 key。

這兩命令是原子性的，不會終止執(zhí)行。一旦開始執(zhí)行，不會執(zhí)行失敗的。

2.5 注意使用del命令

刪除key你一般使用什么命令？是直接del？如果刪除一個(gè)key，直接使用del命令當(dāng)然沒問題。但是，你想過del的時(shí)間復(fù)雜度是多少嘛？我們分情況探討一下：

如果刪除一個(gè)String類型的key，時(shí)間復(fù)雜度就是O（1），「可以直接del」。

如果刪除一個(gè)List/Hash/Set/ZSet類型時(shí)，它的復(fù)雜度是O(n), n表示元素個(gè)數(shù)。

因此，如果你刪除一個(gè)List/Hash/Set/ZSet類型的key時(shí)，元素越多，就越慢。「當(dāng)n很大時(shí)，要尤其注意」，會阻塞主線程的。那么，如果不用del，我們應(yīng)該怎么刪除呢？

如果是List類型，你可以執(zhí)行l(wèi)pop或者rpop，直到所有元素刪除完成。

如果是Hash/Set/ZSet類型，你可以先執(zhí)行hscan/sscan/scan查詢，再執(zhí)行hdel/srem/zrem依次刪除每個(gè)元素。

2.6 避免使用SORT、SINTER等復(fù)雜度過高的命令。

執(zhí)行復(fù)雜度較高的命令，會消耗更多的 CPU 資源，會阻塞主線程。所以你要避免執(zhí)行如SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE等聚合命令，一般建議把它放到客戶端來執(zhí)行。

3、項(xiàng)目實(shí)戰(zhàn)避坑操作

3.1 分布式鎖使用的注意點(diǎn)

分布式鎖其實(shí)就是，控制分布式系統(tǒng)不同進(jìn)程共同訪問共享資源的一種鎖的實(shí)現(xiàn)。秒殺下單、搶紅包等等業(yè)務(wù)場景，都需要用到分布式鎖。我們經(jīng)常使用Redis作為分布式鎖，主要有這些注意點(diǎn)：

3.1.1 兩個(gè)命令SETNX + EXPIRE分開寫（典型錯(cuò)誤實(shí)現(xiàn)范例）

if（jedis.setnx(key_resource_id,lock_value)==1）{//加鎖 expire（key_resource_id，100）;//設(shè)置過期時(shí)間 try{ dosomething//業(yè)務(wù)請求 }catch(){ } finally{ jedis.del(key_resource_id);//釋放鎖 } }

如果執(zhí)行完setnx加鎖，正要執(zhí)行expire設(shè)置過期時(shí)間時(shí)，進(jìn)程crash或者要重啟維護(hù)了，那么這個(gè)鎖就“長生不老”了，「別的線程永遠(yuǎn)獲取不到鎖」啦，所以一般分布式鎖不能這么實(shí)現(xiàn)。

3.1.2 SETNX + value值是過期時(shí)間 (有些小伙伴是這么實(shí)現(xiàn)，有坑)

longexpires=System.currentTimeMillis()+expireTime;//系統(tǒng)時(shí)間+設(shè)置的過期時(shí)間 StringexpiresStr=String.valueOf(expires); //如果當(dāng)前鎖不存在，返回加鎖成功 if(jedis.setnx(key_resource_id,expiresStr)==1){ returntrue; } //如果鎖已經(jīng)存在，獲取鎖的過期時(shí)間 StringcurrentValueStr=jedis.get(key_resource_id); //如果獲取到的過期時(shí)間，小于系統(tǒng)當(dāng)前時(shí)間，表示已經(jīng)過期 if(currentValueStr!=null&&Long.parseLong(currentValueStr)

//鎖已過期，獲取上一個(gè)鎖的過期時(shí)間，并設(shè)置現(xiàn)在鎖的過期時(shí)間（不了解redis的getSet命令的小伙伴，可以去官網(wǎng)看下哈） StringoldValueStr=jedis.getSet(key_resource_id,expiresStr); if(oldValueStr!=null&&oldValueStr.equals(currentValueStr)){ //考慮多線程并發(fā)的情況，只有一個(gè)線程的設(shè)置值和當(dāng)前值相同，它才可以加鎖 returntrue; } } //其他情況，均返回加鎖失敗 returnfalse; }

這種方案的「缺點(diǎn)」：

過期時(shí)間是客戶端自己生成的，分布式環(huán)境下，每個(gè)客戶端的時(shí)間必須同步

沒有保存持有者的唯一標(biāo)識，可能被別的客戶端釋放/解鎖。

鎖過期的時(shí)候，并發(fā)多個(gè)客戶端同時(shí)請求過來，都執(zhí)行了jedis.getSet()，最終只能有一個(gè)客戶端加鎖成功，但是該客戶端鎖的過期時(shí)間，可能被別的客戶端覆蓋。

3.1.3：SET的擴(kuò)展命令（SET EX PX NX）（注意可能存在的問題）

if（jedis.set(key_resource_id,lock_value,"NX","EX",100s)==1）{//加鎖 try{ dosomething//業(yè)務(wù)處理 }catch(){ } finally{ jedis.del(key_resource_id);//釋放鎖 } }

這個(gè)方案還是可能存在問題：

鎖過期釋放了，業(yè)務(wù)還沒執(zhí)行完。

鎖被別的線程誤刪。

3.1.4 SET EX PX NX + 校驗(yàn)唯一隨機(jī)值,再刪除（解決了誤刪問題，還是存在鎖過期，業(yè)務(wù)沒執(zhí)行完的問題）

if（jedis.set(key_resource_id,uni_request_id,"NX","EX",100s)==1）{//加鎖 try{ dosomething//業(yè)務(wù)處理 }catch(){ } finally{ //判斷是不是當(dāng)前線程加的鎖,是才釋放 if(uni_request_id.equals(jedis.get(key_resource_id))){ jedis.del(lockKey);//釋放鎖 } } }

在這里，判斷是不是當(dāng)前線程加的鎖和釋放鎖不是一個(gè)原子操作。如果調(diào)用jedis.del()釋放鎖的時(shí)候，可能這把鎖已經(jīng)不屬于當(dāng)前客戶端，會解除他人加的鎖。

一般也是用lua腳本代替。lua腳本如下：

ifredis.call('get',KEYS[1])==ARGV[1]then returnredis.call('del',KEYS[1]) else return0 end;

3.1.5 Redisson框架 + Redlock算法 解決鎖過期釋放，業(yè)務(wù)沒執(zhí)行完問題+單機(jī)問題

Redisson 使用了一個(gè)Watch dog解決了鎖過期釋放，業(yè)務(wù)沒執(zhí)行完問題，Redisson原理圖如下:

以上的分布式鎖，還存在單機(jī)問題：

如果線程一在Redis的master節(jié)點(diǎn)上拿到了鎖，但是加鎖的key還沒同步到slave節(jié)點(diǎn)。恰好這時(shí)，master節(jié)點(diǎn)發(fā)生故障，一個(gè)slave節(jié)點(diǎn)就會升級為master節(jié)點(diǎn)。線程二就可以獲取同個(gè)key的鎖啦，但線程一也已經(jīng)拿到鎖了，鎖的安全性就沒了。

針對單機(jī)問題，可以使用Redlock算法。有興趣的朋友可以看下我這篇文章哈，七種方案！探討Redis分布式鎖的正確使用姿勢

3.2 緩存一致性注意點(diǎn)

如果是讀請求，先讀緩存，后讀數(shù)據(jù)庫

如果寫請求，先更新數(shù)據(jù)庫，再寫緩存

每次更新數(shù)據(jù)后，需要清除緩存

緩存一般都需要設(shè)置一定的過期失效

一致性要求高的話，可以使用biglog+MQ保證。

有興趣的朋友，可以看下我這篇文章哈：并發(fā)環(huán)境下，先操作數(shù)據(jù)庫還是先操作緩存？

3.3 合理評估Redis容量，避免由于頻繁set覆蓋，導(dǎo)致之前設(shè)置的過期時(shí)間無效。

我們知道，Redis的所有數(shù)據(jù)結(jié)構(gòu)類型，都是可以設(shè)置過期時(shí)間的。假設(shè)一個(gè)字符串，已經(jīng)設(shè)置了過期時(shí)間，你再去重新設(shè)置它，就會導(dǎo)致之前的過期時(shí)間無效。

Redis setKey源碼如下：

voidsetKey(redisDb*db,robj*key,robj*val){ if(lookupKeyWrite(db,key)==NULL){ dbAdd(db,key,val); }else{ dbOverwrite(db,key,val); } incrRefCount(val); removeExpire(db,key);//去掉過期時(shí)間 signalModifiedKey(db,key); }

實(shí)際業(yè)務(wù)開發(fā)中，同時(shí)我們要合理評估Redis的容量，避免頻繁set覆蓋，導(dǎo)致設(shè)置了過期時(shí)間的key失效。新手小白容易犯這個(gè)錯(cuò)誤。

3.4 緩存穿透問題

先來看一個(gè)常見的緩存使用方式：讀請求來了，先查下緩存，緩存有值命中，就直接返回；緩存沒命中，就去查數(shù)據(jù)庫，然后把數(shù)據(jù)庫的值更新到緩存，再返回。

「緩存穿透」：指查詢一個(gè)一定不存在的數(shù)據(jù)，由于緩存是不命中時(shí)需要從數(shù)據(jù)庫查詢，查不到數(shù)據(jù)則不寫入緩存，這將導(dǎo)致這個(gè)不存在的數(shù)據(jù)每次請求都要到數(shù)據(jù)庫去查詢，進(jìn)而給數(shù)據(jù)庫帶來壓力。

通俗點(diǎn)說，讀請求訪問時(shí)，緩存和數(shù)據(jù)庫都沒有某個(gè)值，這樣就會導(dǎo)致每次對這個(gè)值的查詢請求都會穿透到數(shù)據(jù)庫，這就是緩存穿透。

緩存穿透一般都是這幾種情況產(chǎn)生的：

「業(yè)務(wù)不合理的設(shè)計(jì)」，比如大多數(shù)用戶都沒開守護(hù)，但是你的每個(gè)請求都去緩存，查詢某個(gè)userid查詢有沒有守護(hù)。

「業(yè)務(wù)/運(yùn)維/開發(fā)失誤的操作」，比如緩存和數(shù)據(jù)庫的數(shù)據(jù)都被誤刪除了。

「黑客非法請求攻擊」，比如黑客故意捏造大量非法請求，以讀取不存在的業(yè)務(wù)數(shù)據(jù)。

「如何避免緩存穿透呢？」一般有三種方法。

如果是非法請求，我們在API入口，對參數(shù)進(jìn)行校驗(yàn)，過濾非法值。

如果查詢數(shù)據(jù)庫為空，我們可以給緩存設(shè)置個(gè)空值，或者默認(rèn)值。但是如有有寫請求進(jìn)來的話，需要更新緩存哈，以保證緩存一致性，同時(shí)，最后給緩存設(shè)置適當(dāng)?shù)倪^期時(shí)間。（業(yè)務(wù)上比較常用，簡單有效）

使用布隆過濾器快速判斷數(shù)據(jù)是否存在。即一個(gè)查詢請求過來時(shí)，先通過布隆過濾器判斷值是否存在，存在才繼續(xù)往下查。

布隆過濾器原理：它由初始值為0的位圖數(shù)組和N個(gè)哈希函數(shù)組成。一個(gè)對一個(gè)key進(jìn)行N個(gè)hash算法獲取N個(gè)值，在比特?cái)?shù)組中將這N個(gè)值散列后設(shè)定為1，然后查的時(shí)候如果特定的這幾個(gè)位置都為1，那么布隆過濾器判斷該key存在。

3.5 緩存雪奔問題

「緩存雪奔：」指緩存中數(shù)據(jù)大批量到過期時(shí)間，而查詢數(shù)據(jù)量巨大，請求都直接訪問數(shù)據(jù)庫，引起數(shù)據(jù)庫壓力過大甚至down機(jī)。

緩存雪奔一般是由于大量數(shù)據(jù)同時(shí)過期造成的，對于這個(gè)原因，可通過均勻設(shè)置過期時(shí)間解決，即讓過期時(shí)間相對離散一點(diǎn)。如采用一個(gè)較大固定值+一個(gè)較小的隨機(jī)值，5小時(shí)+0到1800秒醬紫。

Redis 故障宕機(jī)也可能引起緩存雪奔。這就需要構(gòu)造Redis高可用集群啦。

3.6 緩存擊穿問題

「緩存擊穿：」指熱點(diǎn)key在某個(gè)時(shí)間點(diǎn)過期的時(shí)候，而恰好在這個(gè)時(shí)間點(diǎn)對這個(gè)Key有大量的并發(fā)請求過來，從而大量的請求打到db。

緩存擊穿看著有點(diǎn)像，其實(shí)它兩區(qū)別是，緩存雪奔是指數(shù)據(jù)庫壓力過大甚至down機(jī)，緩存擊穿只是大量并發(fā)請求到了DB數(shù)據(jù)庫層面。可以認(rèn)為擊穿是緩存雪奔的一個(gè)子集吧。有些文章認(rèn)為它倆區(qū)別，是區(qū)別在于擊穿針對某一熱點(diǎn)key緩存，雪奔則是很多key。

解決方案就有兩種：

「1.使用互斥鎖方案」。緩存失效時(shí)，不是立即去加載db數(shù)據(jù)，而是先使用某些帶成功返回的原子操作命令，如(Redis的setnx）去操作，成功的時(shí)候，再去加載db數(shù)據(jù)庫數(shù)據(jù)和設(shè)置緩存。否則就去重試獲取緩存。

「2. “永不過期”」，是指沒有設(shè)置過期時(shí)間，但是熱點(diǎn)數(shù)據(jù)快要過期時(shí)，異步線程去更新和設(shè)置過期時(shí)間。

3.7、緩存熱key問題

在Redis中，我們把訪問頻率高的key，稱為熱點(diǎn)key。如果某一熱點(diǎn)key的請求到服務(wù)器主機(jī)時(shí)，由于請求量特別大，可能會導(dǎo)致主機(jī)資源不足，甚至宕機(jī)，從而影響正常的服務(wù)。

而熱點(diǎn)Key是怎么產(chǎn)生的呢？主要原因有兩個(gè)：

用戶消費(fèi)的數(shù)據(jù)遠(yuǎn)大于生產(chǎn)的數(shù)據(jù)，如秒殺、熱點(diǎn)新聞等讀多寫少的場景。

請求分片集中，超過單Redi服務(wù)器的性能，比如固定名稱key，Hash落入同一臺服務(wù)器，瞬間訪問量極大，超過機(jī)器瓶頸，產(chǎn)生熱點(diǎn)Key問題。

那么在日常開發(fā)中，如何識別到熱點(diǎn)key呢？

憑經(jīng)驗(yàn)判斷哪些是熱Key；

客戶端統(tǒng)計(jì)上報(bào)；

服務(wù)代理層上報(bào)

如何解決熱key問題？

Redis集群擴(kuò)容：增加分片副本，均衡讀流量；

對熱key進(jìn)行hash散列，比如將一個(gè)key備份為key1,key2……keyN，同樣的數(shù)據(jù)N個(gè)備份，N個(gè)備份分布到不同分片，訪問時(shí)可隨機(jī)訪問N個(gè)備份中的一個(gè)，進(jìn)一步分擔(dān)讀流量；

使用二級緩存，即JVM本地緩存,減少Redis的讀請求。

4. Redis配置運(yùn)維

4.1 使用長連接而不是短連接，并且合理配置客戶端的連接池

如果使用短連接，每次都需要過 TCP 三次握手、四次揮手，會增加耗時(shí)。然而長連接的話，它建立一次連接，redis的命令就能一直使用，醬紫可以減少建立redis連接時(shí)間。

連接池可以實(shí)現(xiàn)在客戶端建立多個(gè)連接并且不釋放，需要使用連接的時(shí)候，不用每次都創(chuàng)建連接，節(jié)省了耗時(shí)。但是需要合理設(shè)置參數(shù)，長時(shí)間不操作 Redis時(shí)，也需及時(shí)釋放連接資源。

4.2 只使用 db0

Redis-standalone架構(gòu)禁止使用非db0.原因有兩個(gè)

一個(gè)連接，Redis執(zhí)行命令select 0和select 1切換，會損耗新能。

Redis Cluster 只支持 db0，要遷移的話，成本高

4.3 設(shè)置maxmemory + 恰當(dāng)?shù)奶蕴呗浴?/p>

為了防止內(nèi)存積壓膨脹。比如有些時(shí)候，業(yè)務(wù)量大起來了，redis的key被大量使用，內(nèi)存直接不夠了，運(yùn)維小哥哥也忘記加大內(nèi)存了。難道redis直接這樣掛掉？所以需要根據(jù)實(shí)際業(yè)務(wù)，選好maxmemory-policy(最大內(nèi)存淘汰策略)，設(shè)置好過期時(shí)間。一共有8種內(nèi)存淘汰策略：

volatile-lru：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，從設(shè)置了過期時(shí)間的key中使用LRU（最近最少使用）算法進(jìn)行淘汰；

allkeys-lru：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，從所有key中使用LRU（最近最少使用）算法進(jìn)行淘汰。

volatile-lfu：4.0版本新增，當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在過期的key中，使用LFU算法進(jìn)行刪除key。

allkeys-lfu：4.0版本新增，當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，從所有key中使用LFU算法進(jìn)行淘汰；

volatile-random：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，從設(shè)置了過期時(shí)間的key中，隨機(jī)淘汰數(shù)據(jù)；。

allkeys-random：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，從所有key中隨機(jī)淘汰數(shù)據(jù)。

volatile-ttl：當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，在設(shè)置了過期時(shí)間的key中，根據(jù)過期時(shí)間進(jìn)行淘汰，越早過期的優(yōu)先被淘汰；

noeviction：默認(rèn)策略，當(dāng)內(nèi)存不足以容納新寫入數(shù)據(jù)時(shí)，新寫入操作會報(bào)錯(cuò)。

4.4 開啟 lazy-free 機(jī)制

Redis4.0+版本支持lazy-free機(jī)制，如果你的Redis還是有bigKey這種玩意存在，建議把lazy-free開啟。當(dāng)開啟它后，Redis 如果刪除一個(gè) bigkey 時(shí)，釋放內(nèi)存的耗時(shí)操作，會放到后臺線程去執(zhí)行，減少對主線程的阻塞影響。

編輯：jq