一、前言

在互聯網應用中，緩存成為高并發架構的關鍵組件。本文主要介紹緩存使用的典型場景、實操案例分析、Redis使用規范及常規Redis監控。

二、常見緩存對比

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

三、Redis使用場景

1、計數

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

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

2、Session集中管理

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

3、限速

例如：高并發的秒殺活動，使用incrby命令實現原子性遞增。

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

4、排行榜

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

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

5、分布式鎖

在實際的多進程并發場景下，使用分布式鎖來限制程序的并發執行。多用于防止高并發場景下，緩存被擊穿的可能。

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

四、案例解析

1、過期設置- set命令會去掉過期時間

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

如下是 Redis 源碼截圖：

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<Long>(connectionHandler, maxAttempts) {  
      @Override  
      public Long execute(Jedis connection) {  
        return connection.pexpire(key, millisecondsTimestamp); //此處pexpire應該是pexpireAt  
      }  
    }.runBinary(key);  
  } 

對比pexpire和pexpireAt：

比如我們當前使用的時間是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方法的時候會先獲取鏈接。

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

JedisConnectionFactory.java 會調用

JedisConnection構造器，注意這邊的dbIndex就是數據庫編號，如：1

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

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

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

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

筆者在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值在業務層面做控制。

•  hgetall
•  lrange
•  smembers
•  zrange

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

5、Pipeline使用

說明：Pipeline是Redis批量提交的一種方式,也就是把多個命令操作建立一次連接發給Redis去執行,會比循環的單次提交性能更優。

Redis客戶端執行一條命令分4個過程：發送命令 -> 命令排隊 ->命令執行 -> 返回結果。

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

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

6、線上禁用命令

•  禁止使用Monitor

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

•  禁止使用Keys

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

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

•  禁止使用Flushall、Flushdb

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

•  禁止使用Save

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

•  BGREWRITEAOF

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

•  Config

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

六、Redis監控

1、慢查詢

方法一：slowlog獲取慢查詢日志 

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" 

方法二：更全面的慢查詢可以通過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大小，才能更好地服務于業務，為業務提供高性能的保障。