小編給大家分享一下使用redis時必須注意的要點有哪些，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

在普定等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站設(shè)計、網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè) 網(wǎng)站設(shè)計制作按需制作,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站建設(shè),成都全網(wǎng)營銷推廣,成都外貿(mào)網(wǎng)站建設(shè)公司,普定網(wǎng)站建設(shè)費用合理。

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

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

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

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

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

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

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

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

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

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

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

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

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

反例：

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

正例

hmset user:666 name jay age 18

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

• 因為Redis的數(shù)據(jù)是存在內(nèi)存中的，而內(nèi)存資源是很寶貴的。

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

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

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

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

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

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

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

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

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

2、Redis 有坑的那些命令

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

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

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

2.2 慎用Redis的monitor命令

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

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

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

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

keys key前綴*

但是，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.

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

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

2.4 禁止使用flushall、flushdb

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

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

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

2.5 注意使用del命令

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

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

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

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

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

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

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

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

3、項目實戰(zhàn)避坑操作

3.1 分布式鎖使用的注意點

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

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

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

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

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

long expires = System.currentTimeMillis() + expireTime; //系統(tǒng)時間+設(shè)置的過期時間
String expiresStr = String.valueOf(expires);

// 如果當(dāng)前鎖不存在，返回加鎖成功
if (jedis.setnx(key_resource_id, expiresStr) == 1) {
        return true;
} 
// 如果鎖已經(jīng)存在，獲取鎖的過期時間
String currentValueStr = jedis.get(key_resource_id);

// 如果獲取到的過期時間，小于系統(tǒng)當(dāng)前時間，表示已經(jīng)過期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {

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

這種方案的缺點：

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

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

• 鎖過期的時候，并發(fā)多個客戶端同時請求過來，都執(zhí)行了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  //業(yè)務(wù)處理
    }catch(){
　　}
　　finally {
       jedis.del(key_resource_id); //釋放鎖
    }
}

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

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

• 鎖被別的線程誤刪。

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

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

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

一般也是用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算法 解決鎖過期釋放，業(yè)務(wù)沒執(zhí)行完問題+單機問題

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

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

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

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

3.2 緩存一致性注意點

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

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

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

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

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

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

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

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

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);
}

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

3.4 緩存穿透問題

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

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

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

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

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

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

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

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

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

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

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

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

3.5 緩存雪奔問題

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

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

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

3.6 緩存擊穿問題

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

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

解決方案就有兩種：

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

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

3.7、緩存熱key問題

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

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

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

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

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

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

• 客戶端統(tǒng)計上報；

• 服務(wù)代理層上報

如何解決熱key問題？

• Redis集群擴容：增加分片副本，均衡讀流量；

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

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

4、Redis配置運維

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

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

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

4.2 只使用 db0

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

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

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

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

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

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

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

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

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

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

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

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

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

4.4 開啟 lazy-free 機制

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

以上是“使用Redis時必須注意的要點有哪些”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！