最近在學習Redis相關知識，看了阿里的redis開發規范，以及Redis開發與運維這本書。分使用規范、有坑的命令、項目實戰操作、運維配置四個方向，整理了使用Redis的21個注意點，希望對大家有幫助，一起學習哈。

一、Redis的使用規范

1、key的規范要點

我們設計Redis的key的時候，要注意以下這幾個點：

•  以業務名為key前綴，用冒號隔開，以防止key沖突覆蓋。如，live:rank:1；
•  確保key的語義清晰的情況下，key的長度盡量小于30個字符；
•  key禁止包含特殊字符，如空格、換行、單雙引號以及其他轉義字符；
•  Redis的key盡量設置ttl，以保證不使用的Key能被及時清理或淘汰。

2、value的規范要點

Redis的value值不可以隨意設置的哦。

「第一點」，如果大量存儲bigKey是會有問題的，會導致慢查詢，內存增長過快等等。

•  如果是String類型，單個value大小控制10k以內；
•  如果是hash、list、set、zset類型，元素個數一般不超過5000。

「第二點」，要選擇適合的數據類型。不少小伙伴只用Redis的String類型，上來就是set和get。實際上，Redis 提供了「豐富的數據結構類型」，有些業務場景，更適合hash、zset等其他數據結果。

「反例：」 

set user:666:name jay  
set user:666:age 18 

「正例」 

hmset user:666 name jay age 18  

3、給Key設置過期時間，同時注意不同業務的key，盡量過期時間分散一點

因為Redis的數據是存在內存中的，而內存資源是很寶貴的。

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

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

如果大量的key在某個時間點集中過期，到過期的那個時間點，Redis可能會存在卡頓，甚至出現「緩存雪崩」現象，因此一般不同業務的key，過期時間應該分散一些。有時候，同業務的，也可以在時間上加一個隨機值，讓過期時間分散一些。

4、建議使用批量操作提高效率

我們日常寫SQL的時候，都知道，批量操作效率會更高，一次更新50條，比循環50次，每次更新一條效率更高。其實Redis操作命令也是這個道理。

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

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

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

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

二、Redis 有坑的那些命令

1、慎用O(n)復雜度命令，如hgetall、smember，lrange等

因為Redis是單線程執行命令的。hgetall、smember等命令時間復雜度為O(n)，當n持續增加時，會導致 Redis CPU 持續飆高，阻塞其他命令的執行。

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

2、慎用Redis的monitor命令

Redis Monitor 命令用于實時打印出Redis服務器接收到的命令，如果我們想知道客戶端對redis服務端做了哪些命令操作，就可以用Monitor 命令查看，但是它一般「調試」用而已，盡量不要在生產上用！因為「monitor命令可能導致redis的內存持續飆升。」

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

3、生產環境不能使用 keys指令

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

keys key前綴* 

但是，redis的keys是遍歷匹配的，復雜度是O（n），數據庫數據越多就越慢。我們知道，redis是單線程的，如果數據比較多的話，keys指令就會導致redis線程阻塞，線上服務也會停頓了，直到指令執行完，服務才會恢復。因此，「一般在生產環境，不要使用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. 

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

scan支持增量式迭代命令，增量式迭代命令也是有缺點的：舉個例子， 使用 SMEMBERS 命令可以返回集合鍵當前包含的所有元素， 但是對于 SCAN 這類增量式迭代命令來說， 因為在對鍵進行增量式迭代的過程中， 鍵可能會被修改， 所以增量式迭代命令只能對被返回的元素提供有限的保證 。

4、禁止使用flushall、flushdb

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

Flushdb 命令用于清空當前數據庫中的所有 key。

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

5、注意使用del命令

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

•  如果刪除一個String類型的key，時間復雜度就是O（1），「可以直接del」；
•  如果刪除一個List/Hash/Set/ZSet類型時，它的復雜度是O(n), n表示元素個數。

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

•  如果是List類型，你可以執行lpop或者rpop，直到所有元素刪除完成；
•  如果是Hash/Set/ZSet類型，你可以先執行hscan/sscan/scan查詢，再執行hdel/srem/zrem依次刪除每個元素。

6 、避免使用SORT、SINTER等復雜度過高的命令。

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

三、項目實戰避坑操作

1、分布式鎖使用的注意點

分布式鎖其實就是，控制分布式系統不同進程共同訪問共享資源的一種鎖的實現。秒殺下單、搶紅包等等業務場景，都需要用到分布式鎖。我們經常使用Redis作為分布式鎖，主要有這些注意點：

3.1.1 兩個命令SETNX + EXPIRE分開寫（典型錯誤實現范例） 

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

如果執行完setnx加鎖，正要執行expire設置過期時間時，進程crash或者要重啟維護了，那么這個鎖就“長生不老”了，「別的線程永遠獲取不到鎖」啦，所以一般分布式鎖不能這么實現。

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

long expires = System.currentTimeMillis() + expireTime; //系統時間+設置的過期時間  
String expiresStr = String.valueOf(expires);  
// 如果當前鎖不存在，返回加鎖成功  
if (jedis.setnx(key_resource_id, expiresStr) == 1) {  
        return true;  
}   
// 如果鎖已經存在，獲取鎖的過期時間  
String currentValueStr = jedis.get(key_resource_id);  
// 如果獲取到的過期時間，小于系統當前時間，表示已經過期  
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {  
     // 鎖已過期，獲取上一個鎖的過期時間，并設置現在鎖的過期時間（不了解redis的getSet命令的小伙伴，可以去官網看下哈）  
    String oldValueStr = jedis.getSet(key_resource_id, expiresStr);   
    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {  
         // 考慮多線程并發的情況，只有一個線程的設置值和當前值相同，它才可以加鎖  
         return true;  
    }  
}       
//其他情況，均返回加鎖失敗  
return false;  
} 

這種方案的「缺點」：

•  過期時間是客戶端自己生成的，分布式環境下，每個客戶端的時間必須同步；
•  沒有保存持有者的唯一標識，可能被別的客戶端釋放/解鎖；
•  鎖過期的時候，并發多個客戶端同時請求過來，都執行了jedis.getSet()，最終只能有一個客戶端加鎖成功，但是該客戶端鎖的過期時間，可能被別的客戶端覆蓋。

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

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

這個方案還是可能存在問題：

•  鎖過期釋放了，業務還沒執行完；
•  鎖被別的線程誤刪。

3.1.4 SET EX PX NX + 校驗唯一隨機值,再刪除（解決了誤刪問題，還是存在鎖過期，業務沒執行完的問題） 

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

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

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

if redis.call('get',KEYS[1]) == ARGV[1] then   
   return redis.call('del',KEYS[1])   
else  
   return 0  
end; 

3.1.5 Redisson框架 + Redlock算法 解決鎖過期釋放，業務沒執行完問題+單機問題

Redisson 使用了一個Watch dog解決了鎖過期釋放，業務沒執行完問題，Redisson原理圖如下:

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

 

如果線程一在Redis的master節點上拿到了鎖，但是加鎖的key還沒同步到slave節點。恰好這時，master節點發生故障，一個slave節點就會升級為master節點。線程二就可以獲取同個key的鎖啦，但線程一也已經拿到鎖了，鎖的安全性就沒了。

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

2、緩存一致性注意點

•  如果是讀請求，先讀緩存，后讀數據庫；
•  如果寫請求，先更新數據庫，再寫緩存；
•  每次更新數據后，需要清除緩存；
•  緩存一般都需要設置一定的過期失效；
•  一致性要求高的話，可以使用biglog+MQ保證。

有興趣的朋友，可以看下我這篇文章哈：并發環境下，先操作數據庫還是先操作緩存？

3、合理評估Redis容量，避免由于頻繁set覆蓋，導致之前設置的過期時間無效。

我們知道，Redis的所有數據結構類型，都是可以設置過期時間的。假設一個字符串，已經設置了過期時間，你再去重新設置它，就會導致之前的過期時間無效。

Redis setKey源碼如下： 

void setKey(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); //去掉過期時間  
    signalModifiedKey(db,key);  
} 

實際業務開發中，同時我們要合理評估Redis的容量，避免頻繁set覆蓋，導致設置了過期時間的key失效。新手小白容易犯這個錯誤。

4、緩存穿透問題

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

「緩存穿透」：指查詢一個一定不存在的數據，由于緩存是不命中時需要從數據庫查詢，查不到數據則不寫入緩存，這將導致這個不存在的數據每次請求都要到數據庫去查詢，進而給數據庫帶來壓力。

通俗點說，讀請求訪問時，緩存和數據庫都沒有某個值，這樣就會導致每次對這個值的查詢請求都會穿透到數據庫，這就是緩存穿透。

緩存穿透一般都是這幾種情況產生的：

•  「業務不合理的設計」，比如大多數用戶都沒開守護，但是你的每個請求都去緩存，查詢某個userid查詢有沒有守護。
•  「業務/運維/開發失誤的操作」，比如緩存和數據庫的數據都被誤刪除了。
•  「黑客非法請求攻擊」，比如黑客故意捏造大量非法請求，以讀取不存在的業務數據。

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

•  如果是非法請求，我們在API入口，對參數進行校驗，過濾非法值；
•  如果查詢數據庫為空，我們可以給緩存設置個空值，或者默認值。但是如有有寫請求進來的話，需要更新緩存哈，以保證緩存一致性，同時，最后給緩存設置適當的過期時間。（業務上比較常用，簡單有效）；
•  使用布隆過濾器快速判斷數據是否存在。即一個查詢請求過來時，先通過布隆過濾器判斷值是否存在，存在才繼續往下查。

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

5、緩存雪奔問題

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

•  緩存雪奔一般是由于大量數據同時過期造成的，對于這個原因，可通過均勻設置過期時間解決，即讓過期時間相對離散一點。如采用一個較大固定值+一個較小的隨機值，5小時+0到1800秒醬紫；
•  Redis 故障宕機也可能引起緩存雪奔。這就需要構造Redis高可用集群啦。

6、緩存擊穿問題

「緩存擊穿：」 指熱點key在某個時間點過期的時候，而恰好在這個時間點對這個Key有大量的并發請求過來，從而大量的請求打到db。

緩存擊穿看著有點像，其實它兩區別是，緩存雪奔是指數據庫壓力過大甚至down機，緩存擊穿只是大量并發請求到了DB數據庫層面。可以認為擊穿是緩存雪奔的一個子集吧。有些文章認為它倆區別，是區別在于擊穿針對某一熱點key緩存，雪奔則是很多key。

解決方案就有兩種：

•  「使用互斥鎖方案」。緩存失效時，不是立即去加載db數據，而是先使用某些帶成功返回的原子操作命令，如(Redis的setnx）去操作，成功的時候，再去加載db數據庫數據和設置緩存。否則就去重試獲取緩存；
•  「 “永不過期”」，是指沒有設置過期時間，但是熱點數據快要過期時，異步線程去更新和設置過期時間。

7、緩存熱key問題

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

而熱點Key是怎么產生的呢？主要原因有兩個：

•  用戶消費的數據遠大于生產的數據，如秒殺、熱點新聞等讀多寫少的場景；
•  請求分片集中，超過單Redi服務器的性能，比如固定名稱key，Hash落入同一臺服務器，瞬間訪問量極大，超過機器瓶頸，產生熱點Key問題。

那么在日常開發中，如何識別到熱點key呢？

•  憑經驗判斷哪些是熱Key；
•  客戶端統計上報；
•  服務代理層上報

如何解決熱key問題？

•  Redis集群擴容：增加分片副本，均衡讀流量；
•  對熱key進行hash散列，比如將一個key備份為key1,key2……keyN，同樣的數據N個備份，N個備份分布到不同分片，訪問時可隨機訪問N個備份中的一個，進一步分擔讀流量；
•  使用二級緩存，即JVM本地緩存,減少Redis的讀請求。

四、Redis配置運維

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

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

連接池可以實現在客戶端建立多個連接并且不釋放，需要使用連接的時候，不用每次都創建連接，節省了耗時。但是需要合理設置參數，長時間不操作 Redis時，也需及時釋放連接資源。

2、只使用 db0

Redis-standalone架構禁止使用非db0.原因有兩個

•  一個連接，Redis執行命令select 0和select 1切換，會損耗新能；
•  Redis Cluster 只支持 db0，要遷移的話，成本高

3、設置maxmemory + 恰當的淘汰策略。

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

•  volatile-lru：當內存不足以容納新寫入數據時，從設置了過期時間的key中使用LRU（最近最少使用）算法進行淘汰；
•  allkeys-lru：當內存不足以容納新寫入數據時，從所有key中使用LRU（最近最少使用）算法進行淘汰；
•  volatile-lfu：4.0版本新增，當內存不足以容納新寫入數據時，在過期的key中，使用LFU算法進行刪除key；
•  allkeys-lfu：4.0版本新增，當內存不足以容納新寫入數據時，從所有key中使用LFU算法進行淘汰；
•  volatile-random：當內存不足以容納新寫入數據時，從設置了過期時間的key中，隨機淘汰數據；
•  allkeys-random：當內存不足以容納新寫入數據時，從所有key中隨機淘汰數據；
•  volatile-ttl：當內存不足以容納新寫入數據時，在設置了過期時間的key中，根據過期時間進行淘汰，越早過期的優先被淘汰；
•  noeviction：默認策略，當內存不足以容納新寫入數據時，新寫入操作會報錯。

4、開啟 lazy-free 機制

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