這篇文章主要講解了“redis使用規(guī)范和監(jiān)控方法是什么”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“Redis使用規(guī)范和監(jiān)控方法是什么”吧！

創(chuàng)新互聯(lián)建站專注于公安網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供公安營(yíng)銷型網(wǎng)站建設(shè)，公安網(wǎng)站制作、公安網(wǎng)頁(yè)設(shè)計(jì)、公安網(wǎng)站官網(wǎng)定制、重慶小程序開(kāi)發(fā)公司服務(wù)，打造公安網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供公安網(wǎng)站排名全網(wǎng)營(yíng)銷落地服務(wù)。

一、前言

在互聯(lián)網(wǎng)應(yīng)用中，緩存成為高并發(fā)架構(gòu)的關(guān)鍵組件。本文主要介紹緩存使用的典型場(chǎng)景、實(shí)操案例分析、Redis使用規(guī)范及常規(guī)Redis監(jiān)控。

二、常見(jiàn)緩存對(duì)比

常見(jiàn)的緩存方案：本地緩存包括HashMap/ConcurrentHashMap、Ehcache、Memcache、Guava Cache等，緩存中間件包括Redis、Tair等。

三、Redis使用場(chǎng)景

1、計(jì)數(shù)

Redis實(shí)現(xiàn)快速計(jì)數(shù)及緩存功能。

例如：視頻或直播在線觀看人數(shù)，用戶每播放一次，就會(huì)自增1。

2、Session集中管理

Session可以存儲(chǔ)在應(yīng)用服務(wù)是JVM中，但這一種方案會(huì)有一致性的問(wèn)題，還有高并發(fā)下，會(huì)引發(fā)JVM內(nèi)存溢出。Redis將用戶的Session集中管理，這種情況下只要保證Redis的高可用和擴(kuò)展性，每次用戶更新或查詢登錄都直接從Redis中信息獲取。

3、限速

例如：高并發(fā)的秒殺活動(dòng)，使用incrby命令實(shí)現(xiàn)原子性遞增。

例如：業(yè)務(wù)要求用戶一分鐘內(nèi)，只能獲取5次驗(yàn)證碼。

4、排行榜

關(guān)系型數(shù)據(jù)庫(kù)在排行榜方面查詢速度普遍偏慢，所以可以借助redis的SortedSet進(jìn)行熱點(diǎn)數(shù)據(jù)的排序。

比如在項(xiàng)目中，如果需要統(tǒng)計(jì)主播的吸金排行榜，可以以主播的id作為member, 當(dāng)天打賞的活動(dòng)禮物對(duì)應(yīng)的熱度值作為 score, 通過(guò)zrangebyscore就可以獲取主播活動(dòng)日榜。

5、分布式鎖

在實(shí)際的多進(jìn)程并發(fā)場(chǎng)景下，使用分布式鎖來(lái)限制程序的并發(fā)執(zhí)行。多用于防止高并發(fā)場(chǎng)景下，緩存被擊穿的可能。

分布式鎖的實(shí)際就是"占坑"，當(dāng)另一個(gè)進(jìn)程來(lái)執(zhí)行setnx時(shí)，發(fā)現(xiàn)標(biāo)識(shí)位已經(jīng)為1，只好放棄或者等待。

四、案例解析

1、過(guò)期設(shè)置- set命令會(huì)去掉過(guò)期時(shí)間

Redis所有的數(shù)據(jù)結(jié)構(gòu)，都可以設(shè)置過(guò)期時(shí)間。如果一個(gè)字符串已經(jīng)設(shè)置了過(guò)期時(shí)間，然后重新設(shè)置它，會(huì)導(dǎo)致過(guò)期時(shí)間消失。所以在項(xiàng)目中需要合理評(píng)估Redis容量，避免因?yàn)轭l繁set導(dǎo)致沒(méi)有過(guò)期策略，間接導(dǎo)致內(nèi)存被占滿。

如下是 Redis 源碼截圖：

2、Jedis 2.9.0及以下版本過(guò)期設(shè)置BUG

發(fā)現(xiàn)Jedis在進(jìn)行expiredAt命令調(diào)用時(shí)有bug，最終調(diào)用的是pexpire命令，這個(gè)bug會(huì)導(dǎo)致key過(guò)期時(shí)間很長(zhǎng)，導(dǎo)致Redis內(nèi)存溢出等問(wèn)題。建議升級(jí)到Jedis 2.9.1及以上版本。

BinaryJedisCluster.java源碼如下：

@Override    public Long pexpireAt(final byte[] key, final long millisecondsTimestamp) {      return new JedisClusterCommand(connectionHandler, maxAttempts) {        @Override        public Long execute(Jedis connection) {          return connection.pexpire(key, millisecondsTimestamp); //此處pexpire應(yīng)該是pexpireAt        }      }.runBinary(key);    }

對(duì)比pexpire和pexpireAt：

比如我們當(dāng)前使用的時(shí)間是2018-06-14 17:00:00，它的unix時(shí)間戳為1528966800000毫秒，當(dāng)我們使用PEXPIREAT命令時(shí)，由于是過(guò)去的時(shí)間，相應(yīng)的key會(huì)立即過(guò)期。

而我們誤用了PEXPIRE命令時(shí)，key不會(huì)立即過(guò)期，而是等到1528966800000毫秒后才過(guò)期，key過(guò)期時(shí)間會(huì)相當(dāng)長(zhǎng)，約幾W天后，從而可能導(dǎo)致Redis內(nèi)存溢出、服務(wù)器崩潰等問(wèn)題。

3、緩存被擊穿

緩存的key有過(guò)期策略，如果恰好在這個(gè)時(shí)間點(diǎn)對(duì)這個(gè)Key有大量的并發(fā)請(qǐng)求，這些請(qǐng)求發(fā)現(xiàn)緩存過(guò)期一般都會(huì)從后端DB回源數(shù)據(jù)并回設(shè)到緩存，這個(gè)時(shí)候大并發(fā)的請(qǐng)求可能會(huì)瞬間把后端DB壓掛。

業(yè)界常用優(yōu)化方案有兩種：

•  第一種：使用分布式鎖，保證高并發(fā)下，僅有一個(gè)線程能回源后端DB；

•  第二種：保證高并發(fā)的請(qǐng)求到的Redis key始終是有效的，使用非用戶請(qǐng)求回源后端，改成主動(dòng)回源。一般可以使用異步任務(wù)進(jìn)行緩存的主動(dòng)刷新。

4、Redis-standalone架構(gòu)禁止使用非0庫(kù)

Redis執(zhí)行命令select 0和select 1切換，造成性能損耗。

RedisTemplate在執(zhí)行execute方法的時(shí)候會(huì)先獲取鏈接。

執(zhí)行到RedisConnectionUtils.java，會(huì)有一段獲取鏈接的方法。

JedisConnectionFactory.java 會(huì)調(diào)用

JedisConnection構(gòu)造器，注意這邊的dbIndex就是數(shù)據(jù)庫(kù)編號(hào)，如：1

繼續(xù)跟進(jìn)JedisConnection代碼，當(dāng)選擇庫(kù)大于1時(shí)，會(huì)有select db操作。如果一直使用0庫(kù)是不需要額外執(zhí)行切庫(kù)命令的。知道了第一個(gè)切庫(kù)select 1的地方，那么select 0是哪來(lái)的呢？

其實(shí)客戶端使用Redis也會(huì)是要釋放鏈接的，只不過(guò)RedisTemplate已經(jīng)幫我們自動(dòng)釋放了，讓我們?cè)倩氐揭婚_(kāi)始RedisTemplate執(zhí)行execute(...)方法的地方。

下面還是RedisConnectionUtils.java，執(zhí)行鏈接關(guān)閉的代碼。

按代碼注釋的意思，如果選擇庫(kù)編號(hào)不為0，spring-data-redis框架每次都會(huì)執(zhí)行重置select 0！

筆者在vivo商城業(yè)務(wù)中，商品詳情頁(yè)接口經(jīng)過(guò)上面的調(diào)優(yōu)，性能提高了3倍多。

進(jìn)一步驗(yàn)證數(shù)據(jù)庫(kù)切換至少影響性能3倍左右（視具體業(yè)務(wù)而定）。

Rediscluster集群數(shù)據(jù)庫(kù)，默認(rèn)0庫(kù)，無(wú)法選擇其他數(shù)據(jù)庫(kù)，也就避免了這個(gè)問(wèn)題。

5、當(dāng)心時(shí)間復(fù)雜度o(n)Redis命令

Redis是單線程的，所以線程安全的。

Redis使用非阻塞IO，并且大部分命令的時(shí)間復(fù)雜度O(1)。

使用高耗時(shí)的命令是非常危險(xiǎn)的，會(huì)占用唯一的一個(gè)線程的大量處理時(shí)間，導(dǎo)致所有的請(qǐng)求都被拖慢。

例如：獲取所有set集合中的元素 smembers myset，返回指定Hash中所有的member，時(shí)間復(fù)雜度O(N)。

緩存的Value集合變大，當(dāng)高并接口請(qǐng)求時(shí)，會(huì)從Redis讀取相關(guān)數(shù)據(jù)，每個(gè)請(qǐng)求讀取的時(shí)間變長(zhǎng)，不斷的疊加，導(dǎo)致出現(xiàn)熱點(diǎn)KEY情況，Redis某個(gè)分片處于阻塞，CPU使用率達(dá)到100%。

6、緩存熱key

在Redis中，訪問(wèn)頻率高的key稱為熱點(diǎn)key，當(dāng)某一熱點(diǎn)key的請(qǐng)求到Server主機(jī)時(shí)，由于請(qǐng)求量特別大，導(dǎo)致主機(jī)資源不足，甚至宕機(jī)，影響正常的服務(wù)。

熱key問(wèn)題的產(chǎn)生，有如下兩種原因：

•  用戶消費(fèi)的數(shù)據(jù)遠(yuǎn)大于生產(chǎn)的數(shù)據(jù)，比如熱賣商品或秒殺商品、熱點(diǎn)新聞、熱點(diǎn)評(píng)論等，這些典型的讀多寫(xiě)少的場(chǎng)景會(huì)產(chǎn)生熱點(diǎn)問(wèn)題；

•  請(qǐng)求分片集中，超過(guò)單Server的性能極限，比如 固定名稱key，哈希落入一臺(tái)Server，訪問(wèn)量極大的情況，超過(guò)Server極限時(shí)，就會(huì)導(dǎo)致熱點(diǎn)Key問(wèn)題的產(chǎn)生。

那么在實(shí)際業(yè)務(wù)中，如何識(shí)別到熱點(diǎn)key呢？

•  憑借業(yè)務(wù)經(jīng)驗(yàn)，進(jìn)行預(yù)估哪些是熱key；

•  客戶端統(tǒng)計(jì)收集，本地統(tǒng)計(jì)或者上報(bào)；

•  如果服務(wù)端有代理層，可以在代理層進(jìn)行收集上報(bào)。

當(dāng)我們識(shí)別到熱key，如何解決熱key問(wèn)題？

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

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

•  使用二級(jí)緩存，即本地緩存。

當(dāng)發(fā)現(xiàn)熱key后，將熱key對(duì)應(yīng)數(shù)據(jù)首先加載到應(yīng)用服務(wù)器本地緩存中，減少對(duì)Redis的讀請(qǐng)求。

五、Redis規(guī)范

1、禁止使用非database 0

說(shuō)明：

Redis-standalone架構(gòu)，禁止使用Redis中的其他database。

原由：

•  為以后業(yè)務(wù)遷移 Redis Cluster 保持兼容性；

•  多個(gè) database 用 select 切換時(shí)，更消耗CPU資源；

•  更易自動(dòng)化運(yùn)維管理，如 scan/dbsize 命令只用于當(dāng)database；

•  部分 Redis Clients 因線程安全問(wèn)題，不支持單實(shí)例多 database。

2、Key設(shè)計(jì)規(guī)范

按業(yè)務(wù)功能命名key前綴，防止key沖突覆蓋，推薦 用冒號(hào)分隔，例如，業(yè)務(wù)名:表名:id:，如 live:rank:user:weekly:1:202003。

Key的長(zhǎng)度小于30個(gè)字符，Key名字本身是String對(duì)象，Redis硬編碼限制最大長(zhǎng)度512MB。

在Redis緩存場(chǎng)景，推薦Key都設(shè)置TTL值，保證不使用的Key能被及時(shí)清理或淘汰。

Key設(shè)計(jì)時(shí)禁止包含特殊字符，如空格、換行、單雙引號(hào)以及其他轉(zhuǎn)義字符。

3、Value設(shè)計(jì)規(guī)范

單個(gè)Value大小必須控制10KB以內(nèi)，單實(shí)例鍵個(gè)數(shù)過(guò)大，可能導(dǎo)致過(guò)期鍵的回收不及時(shí)。

set、hash、list等復(fù)雜數(shù)據(jù)類型，要盡量降低數(shù)據(jù)結(jié)構(gòu)中的元素個(gè)數(shù)，建議個(gè)數(shù)不要超過(guò)1000。

4、關(guān)注命令時(shí)間復(fù)雜度

推薦使用O(1)命令，如get scard等。

O(N)命令關(guān)注N的數(shù)量，如下命令需要對(duì)N值在業(yè)務(wù)層面做控制。

•  hgetall

•  lrange

•  smembers

•  zrange

例如：smember命令時(shí)間復(fù)雜度為O(n)，當(dāng)n持續(xù)增加時(shí)，會(huì)導(dǎo)致 Redis CPU 持續(xù)飆高，阻塞其他命令的執(zhí)行。

5、Pipeline使用

說(shuō)明：Pipeline是Redis批量提交的一種方式,也就是把多個(gè)命令操作建立一次連接發(fā)給Redis去執(zhí)行,會(huì)比循環(huán)的單次提交性能更優(yōu)。

Redis客戶端執(zhí)行一條命令分4個(gè)過(guò)程：發(fā)送命令 -> 命令排隊(duì) ->命令執(zhí)行 -> 返回結(jié)果。

常用的mget、mset命令，有效節(jié)約RTT（命令執(zhí)行往返時(shí)間），但hgetall并沒(méi)有mhgetall，是不支持批量操作的。此時(shí)，需要使用Pipeline命令

例如：直播中臺(tái)項(xiàng)目中，需要同時(shí)查詢主播日、周、月排行榜，使用PIPELINE一次提交多個(gè)命令，同時(shí)返回三個(gè)榜單數(shù)據(jù)。

6、線上禁用命令

•  禁止使用Monitor

  禁止生產(chǎn)環(huán)境使用monitor命令，monitor命令在高并發(fā)條件下，會(huì)存在內(nèi)存暴增和影響Redis性能的隱患

•  禁止使用Keys

  keys操作是遍歷所有的key，如果key非常多的情況下導(dǎo)致慢查詢，會(huì)阻塞其他命令。所以禁止使用keys及keys pattern命令。

  建議線上使用scan命令代替keys命令。

•  禁止使用Flushall、Flushdb

         刪除Redis中所有數(shù)據(jù)庫(kù)中的所有記錄，并且該命令是原子性的，不會(huì)終止執(zhí)行，一旦執(zhí)行，將不會(huì)執(zhí)行失敗。

•  禁止使用Save

        阻塞當(dāng)前redis服務(wù)器，直到持久化操作完成為止，對(duì)于內(nèi)存較大的實(shí)例會(huì)造成長(zhǎng)時(shí)間的阻塞

•  BGREWRITEAOF

        手動(dòng)AOF，手動(dòng)持久化對(duì)于內(nèi)存較大的實(shí)例會(huì)造成長(zhǎng)時(shí)間的阻塞

•  Config

        Config是客戶端配置方式，不利于Redis運(yùn)維。建議在Redis配置文件中設(shè)置。

六、Redis監(jiān)控

1、慢查詢

方法一：slowlog獲取慢查詢?nèi)罩?/p>

127.0.0.1:{port}> slowlog get 5  1) 1) (integer) 47     2) (integer) 1533810300     3) (integer) 175833     4) 1) "DEL"        2) "spring:session:expirations:1533810300000"  2) 1) (integer) 46     2) (integer) 1533810300     3) (integer) 117400     4) 1) "SMEMBERS"

方法二：更全面的慢查詢可以通過(guò)CacheCloud工具監(jiān)控。

路徑："應(yīng)用列表"-點(diǎn)擊相關(guān)應(yīng)用名-點(diǎn)擊"慢查詢"Tab頁(yè)。

點(diǎn)擊"慢查詢"，重點(diǎn)關(guān)注慢查詢個(gè)數(shù)及相關(guān)命令。

2、監(jiān)控Redis實(shí)例綁定的CPU核心使用率

由于Redis是單線程，重點(diǎn)監(jiān)控Redis實(shí)例綁定的CPU核心使用率。

一般CPU資源使用率為10%左右，如果使用率高于20%時(shí)，考慮是否使用了RDB持久化。

3、Redis分片負(fù)載均衡

當(dāng)前redis-cluster架構(gòu)模式，3個(gè)master和3個(gè)Slave組成的集群，關(guān)注 Redis-cluster每個(gè)分片requests流量均衡情況；

通過(guò)命令獲?。?/p>

redis-cli -p{port} -h{host} --stat

一般情況，超過(guò)12W需要告警。

4、關(guān)注大key BigKey

通過(guò)Redis提供的工具，redis-cli定時(shí)掃描相應(yīng)Redis大Key，進(jìn)行優(yōu)化。

具體命令如下：

redis-cli -h 127.0.0.1 -p {port} --bigkeys

或

redis-memory-for-key -s {IP} -p {port} XXX_KEY

一般超過(guò)10K為大key，需要重點(diǎn)關(guān)注，建議從業(yè)務(wù)層面優(yōu)化。

5、監(jiān)控Redis占用內(nèi)存大小

Info memory 命令查看，避免在高并發(fā)場(chǎng)景下，由于分配的MaxMemory被耗盡，帶來(lái)的性能問(wèn)題。

重點(diǎn)關(guān)注 used_memory_human 配置項(xiàng)對(duì)應(yīng)的value值，增量過(guò)高時(shí)，需要重點(diǎn)評(píng)估。

感謝各位的閱讀，以上就是“Redis使用規(guī)范和監(jiān)控方法是什么”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)Redis使用規(guī)范和監(jiān)控方法是什么這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！