Categories
程式開發

Redis 緩存性能實踐及總結


一、前言

在互聯網應用中,緩存成為高並發架構的關鍵組件。這篇博客主要介紹緩存使用的典型場景、實操案例分析、Redis使用規範及常規Redis 監控。

二、常見緩存對比

常見的緩存方案,有本地緩存,包括HashMap/ConcurrentHashMap、Ehcache、Memcache、Guava Cache等,緩存中間件包括Redis、Tair等。

Redis 緩存性能實踐及總結 1

三、Redis使用場景

1. 計數

Redis實現快速計數及緩存功能。

例如:視頻或直播在線觀看人數,用戶每播放一次,就會自增1。

2. Session集中管理

Session可以存儲在應用服務是JVM中,但這一種方案會有一致性的問題,還有高並發下,會引發JVM內存溢出。 Redis將用戶的Session集中管理,這種情況下只要保證Redis的高可用和擴展性,每次用戶更新或查詢登錄都直接從Redis中信息獲取。

3.限速

例如:業務要求用戶一分鐘內,只能獲取5次驗證碼。

4.排行榜

關係型數據庫在排行榜方面查詢速度普遍偏慢,所以可以藉助redis的SortedSet進行熱點數據的排序。

比如在項目中,如果需要統計主播的吸金排行榜,可以以主播的id作為member, 當天打賞的活動禮物對應的熱度值作為score, 通過zrangebyscore就可以獲取主播活動日榜。

5.分佈式鎖

在實際的多進程並發場景下,使用分佈式鎖來限製程序的並發執行。多用於防止高並發場景下,緩存被擊穿的可能。

分佈式鎖的實際就是”佔坑”,當另一個進程來執行setnx時,發現標識位已經為1,只好放棄或者等待。

四、案例解析

1、【案例】過期設置- set命令會去掉過期時間

Redis所有的數據結構,都可以設置過期時間。如果一個字符串已經設置了過期時間,然後重新設置它,會導致過期時間消失。所以在項目中需要合理評估Redis容量,避免因為頻繁set導致沒有過期策略,間接導致內存被佔滿。

如下是Redis 源碼截圖:

Redis 緩存性能實踐及總結 2

2、【案例】關於Jedis 2.9.0 及以下版本過期設置BUG

發現Jedis在進行expiredAt命令調用時有bug,最終調用的是pexpire命令,這個bug會導致key過期時間很長,導致Redis內存溢出等問題。建議升級到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应该是pexpireAt
}
}.runBinary(key);
}

對比pexpire和pexpireAt:

Redis 緩存性能實踐及總結 3

比如我們當前使用的時間是2018-06-14 17:00:00,它的unix時間戳為1528966800000毫秒,當我們使用PEXPIREAT命令時,由於是過去的時間,相應的key會立即過期。

而我們誤用了PEXPIRE命令時,key不會立即過期,而是等到1528966800000毫秒後才過期,key過期時間會相當長,約幾W天后,從而可能導致Redis內存溢出、服務器崩潰等問題。

3、【案例】緩存被擊穿

緩存的key有過期策略,如果恰好在這個時間點對這個Key有大量的並發請求,這些請求發現緩存過期一般都會從後端DB回源數據並回設到緩存,這個時候大並發的請求可能會瞬間把後端DB壓掛。

業界常用優化方案有兩種:

第一種:使用分佈式鎖,保證高並發下,僅有一個線程能回源後端DB。

第二種:保證高並發的請求到的Redis key始終是有效的,使用非用戶請求回源後端,改成主動回源。一般可以使用異步任務進行緩存的主動刷新。

4、【案例】Redis-standalone架構禁止使用非0庫

Redis執行命令select 0和select 1切換,造成性能損耗。

RedisTemplate在執行execute方法的時候會先獲取鏈接。

Redis 緩存性能實踐及總結 4

執行到RedisConnectionUtils.java,會有一段獲取鏈接的方法。

Redis 緩存性能實踐及總結 5

JedisConnectionFactory.java 會調用JedisConnection構造器,注意這邊的dbIndex就是數據庫編號,如:1

Redis 緩存性能實踐及總結 6

繼續跟進JedisConnection代碼,當選擇庫大於1時,會有select db操作。如果一直使用0庫是不需要額外執行切庫命令的。知道了第一個切庫select 1的地方,那麼select 0是哪來的呢?

Redis 緩存性能實踐及總結 7

其實客戶端使用Redis也會是要釋放鏈接的,只不過RedisTemplate已經幫我們自動釋放了,讓我們再回到一開始RedisTemplate執行execute(…)方法的地方。

Redis 緩存性能實踐及總結 8

下面還是RedisConnectionUtils.java,執行鏈接關閉的代碼。

Redis 緩存性能實踐及總結 9

按代碼註釋的意思,如果選擇庫編號不為0,spring-data-redis框架每次都會執行重置select 0!

Redis 緩存性能實踐及總結 10

筆者在vivo商城業務中,商品詳情頁接口經過上面的調優,性能提高了3倍多。

進一步驗證數據庫切換至少影響性能3倍左右(視具體業務而定)。

Rediscluster集群數據庫,默認0庫,無法選擇其他數據庫,也就避免了這個問題。

5、【案例】當心時間複雜度o(n)Redis命令

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

Redis使用非阻塞IO,並且大部分命令的時間複雜度O(1)。

使用高耗時的命令是非常危險的,會佔用唯一的一個線程的大量處理時間,導致所有的請求都被拖慢。

例如:獲取所有set集合中的元素smembers myset,返回指定Hash中所有的member,時間複雜度O(N)。

緩存的Value集合變大,當高並接口請求時,會從Redis讀取相關數據,每個請求讀取的時間變長,不斷的疊加,導致出現熱點KEY情況,Redis某個分片處於阻塞, CPU使用率達到100%。

6、【案例】緩存熱key

在Redis中,訪問頻率高的key稱為熱點key,當某一熱點key的請求到Server主機時,由於請求量特別大,導致主機資源不足,甚至宕機,影響正常的服務。

熱key問題的產生,有如下兩種原因:

用戶消費的數據遠大於生產的數據,比如熱賣商品或秒殺商品、熱點新聞、熱點評論等,這些典型的讀多寫少的場景會產生熱點問題。請求分片集中,超過單Server的性能極限,比如固定名稱key,哈希落入一台Server,訪問量極大的情況,超過Server極限時,就會導致熱點Key問題的產生。

那麼在實際業務中,如何識別到熱點key呢?

憑藉業務經驗,進行預估哪些是熱key;客戶端統計收集,本地統計或者上報;如果服務端有代理層,可以在代理層進行收集上報;

當我們識別到熱key,如何解決熱key問題?

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

當發現熱key後,將熱key對應數據首先加載到應用服務器本地緩存中,減少對Redis的讀請求。

五、Redis 規範

1、禁止使用非database 0

說明:

Redis-standalone架構,禁止使用Redis中的其他database。

原由:

為以後業務遷移Redis Cluster 保持兼容性.多個database 用select 切換時,更消耗CPU資源。更易自動化運維管理,如scan/dbsize 命令只用於當database。部分Redis Clients 因線程安全問題,不支持單實例多database。

2、Key設計規範

按業務功能命名key前綴,防止key衝突覆蓋,推薦 用冒號分隔,例如,業務名:表名:id:,如live:rank:user:weekly:1:202003。

Key的長度小於30個字符,Key名字本身是String對象,Redis硬編碼限制最大長度512MB。

在Redis緩存場景,推薦Key都設置TTL值,保證不使用的Key能被及時清理或淘汰。

Key設計時禁止包含特殊字符,如空格、換行、單雙引號以及其他轉義字符。

3、Value設計規範

單個Value大小必須控制10KB以內,單實例鍵個數過大,可能導致過期鍵的回收不及時。

set、hash、list等複雜數據類型,要盡量降低數據結構中的元素個數,建議個數不要超過1000。

4、關注命令時間複雜度

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

O(N)命令關注N的數量,如下命令需要對N值在業務層面做控制。

hgetalllrangesmemberszrange

例如:smember命令時間複雜度為O(n),當n持續增加時,會導致Redis CPU 持續飆高,阻塞其他命令的執行;

5、Pipeline使用

說明:

Pipeline是Redis批量提交的一種方式,也就是把多個命令操作建立一次連接發給Redis去執行,會比循環的單次提交性能更優。 Redis客戶端執行一條命令分4個過程:發送命令-> 命令排隊->命令執行-> 返回結果。

Redis 緩存性能實踐及總結 11

常用的mget、mset命令,有效節約RTT(命令執行往返時間),但hgetall並沒有mhgetall,是不支持批量操作的。此時,需要使用Pipeline命令

Redis 緩存性能實踐及總結 12

例如:直播中台項目中,需要同時查詢主播日、週、月排行榜,使用PIPELINE一次提交多個命令,同時返回三個榜單數據。

6、線上禁用命令

禁止使用Monitor

禁止生產環境使用monitor命令,monitor命令在高並發條件下,會存在內存暴增和影響Redis性能的隱患

禁止使用Keys

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

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

禁止使用Flushall、Flushdb

刪除Redis中所有數據庫中的所有記錄,並且該命令是原子性的,不會終止執行,一旦執行,將不會執行失敗。

禁止使用Save

阻塞當前redis服務器,直到持久化操作完成為止,對於內存較大的實例會造成長時間的阻塞。

BGREWRITEAOF

手動AOF,手動持久化對於內存較大的實例會造成長時間的阻塞。

設定檔

Config是客戶端配置方式,不利於Redis運維。建議在Redis配置文件中設置。

六、Redis 監控

1、慢查詢

方法一:slowlog獲取慢查詢日誌

127.0.0.1:{port}> slowlog得到51)1)(整數)47 2)(整數)1533810300 3)(整數)175833 4)1)“ DEL” 2)“ spring:session:expirations:1533810300000” 2) 1)(整數)46 2)(整數)1533810300 3)(整數)117400 4)1)“中小企業”

方法二:更全面的慢查詢可以通過CacheCloud工具監控。

路徑:”應用列表”-點擊相關應用名-點擊”慢查詢”Tab頁。點擊”慢查詢”,重點關注慢查詢個數及相關命令。

2、監控Redis實例綁定的CPU核心使用率

由於Redis是單線程,重點監控Redis實例綁定的CPU核心使用率。

一般CPU資源使用率為10%左右,如果使用率高於20%時,考慮是否使用了RDB持久化。

3、Redis分片負載均衡

當前redis-cluster架構模式,3個master和3個Slave組成的集群,關注Redis-cluster每個分片requests流量均衡情況;

通過命令獲取:redis-cli -p{port} -h{host} –stat

一般情況,超過12W需要告警。

4、關注大key BigKey

通過Redis提供的工具,redis-cli定時掃描相應Redis大Key,進行優化。

具體命令如下:redis-cli -h 127.0.0.1 -p {port} –bigkeys或 redis-memory-for-key -s {IP} -p {port} XXX_KEY

一般超過10K為大key,需要重點關注,建議從業務層面優化。

5、監控Redis佔用內存大小

Info memory 命令查看,避免在高並發場景下,由於分配的MaxMemory被耗盡,帶來的性能問題。

重點關注used_memory_human 配置項對應的value值,增量過高時,需要重點評估。

七、總結

結合具體業務特性,合理評估Redis所需內存容量、選擇數據類型、設置單key大小,才能更好地服務於業務,為業務提供高性能的保障。

作者:Jessica Chen