一文了解如何發現并解決Redis熱key與大key問題
熱Key問題
什么是熱key？
熱key是服務端的常見問題，指一段時間內某個key的訪問量遠遠超過其他的key，導致大量訪問流量落在某一個redis實例中；或者是帶寬使用率集中在特定的key（例如，對一個包含2000個field的hash key每秒發送大量的hgetall操作請求）；又或者是cpu使用時間占比集中在特定的key（例如，對一個包含10000個field的key每秒發送大量的zrange操作請求）。
以被請求頻率來定義是否是熱key，沒有固定經驗值。某個key被高頻訪問導致系統穩定性變差，都可以定義為熱key。
可能造成的問題
- 熱點緩存會導致流量集中，redis緩存與數據庫被擊穿，從而引發系統雪崩。詳情可以看《 快速了解緩存穿透與緩存雪崩 》。
- 請求分配不均，存在熱key的節點面臨較大的訪問壓力，可能出現該數據分片的連接數被耗盡甚至宕機。（即使采取擴容也會對資源有很大的浪費）
發現方法
由于熱key發生對系統穩定性有巨大危害，所以需要上線前設立故障預案、建立監控和報警機制，以便快速響應故障。
- 優點：簡單直接。
- 缺點：但并不是所有業務都能預估出哪些key是熱key。
- 根據業務經驗，預估哪些是熱key。
- 在客戶端收集。在操作redis之前，加上統計頻次的邏輯，然后將統計數據發送給一個聚合計算的服務進行統計。
- 優點：方案簡單。
- 缺點：無法支持大公司多語言環境的SDK，或者說多語言SDK對齊比較困難。此外SDK的維護升級成本會很高。
- 在proxy層收集。有些服務在請求redis之前會請求一個proxy服務，這種場景可以使用在proxy層收集熱key數據，收集機制類似于在客戶端收集。
- 優點：方案對使用方完全透明；沒有SDK多語言異構和升級成本高的問題。（不理解這個地方的話，可以查看小輝之前的博客《 通用能力抽象選擇SDK組件還是API服務？ 》）
- 缺點：并不是所有場景都會有proxy層。
- redis集群監控。如果出現某個實例qps傾斜，說明可能存在熱key。
- 優點：不需要額外開發。
- 缺點：每次發生狀況需要人工排查，因為熱key只是導致qps傾斜的一種可能。
- redis 4.0版本之后熱點key發現功能。執行redis-cli時加上 –-hotkeys 選項即可。
- 優點：不需要額外開發。
- 缺點：該參數在執行的時候，如果key比較多，執行耗時會非常長，由此導致查詢結果的實時性并不好。
- redis客戶端使用TCP協議與服務端進行交互。通過腳本監聽端口，解析網絡包并進行分析。
- 優點：對原有的業務系統沒有改造。
- 缺點：開發成本高，維護困難，有丟包可能性。
常用的處理方法
如果對所有熱key進行本地緩存，那么本地緩存是否會過大，從而影響應用程序本身的性能開銷。
可能需要保證本地緩存和redis數據的一致性。
- 熱key統計可以使用LFU數據結構并結合上面的發現方法，將最熱topN的key進行統計，然后在client端使用本地緩存，從而降低redis集群對熱key的訪問量，但這種方法帶來兩個問題：
- 將熱key加上前綴或者后綴，把熱key的數量從1個變成實例個數，利用分片特性將這n個key分散在不同節點上，這樣就可以在訪問的時候，采用客戶端負載均衡的方式，隨機選擇一個key進行訪問，將訪問壓力分散到不同的實例中。這個方案有個明顯的缺點，就是緩存的維護成本大：假如有n為100，則更新或者刪除key的時候需要操作100個key。
- 利用讀寫分離，通過主從復制的方式，增加slave節點來實現讀請求的負載均衡。這個方案明顯的缺點就是使用機器硬抗熱key的數據，資源耗費嚴重；而且引入讀寫分離架構，增加節點數量，都會增加系統的復雜度降低穩定性。
大Key問題
什么是大key？
大key是指當redis的字符串類型占用內存過大或非字符串類型元素數量過多。
生產環境中，綜合衡量運維和環境的情況，給大key定義參考值如下：
- string類型的key超過10KB
- hash/set/zset/list等數據結構中元素個數大于5k/整體占用內存大于10MB
不同系統性能條件不同，所以建議這個標準設置保守些，以系統穩定性為第一考量
可能造成的問題
- 內存使用不均勻。例如在redis集群模式中，某個數據分片的內存使用率遠超其他數據分片，無法使數據分片的內存資源達到均衡。另外也可能造成redis內存達到 maxmemory 參數定義的上限導致重要的Key被逐出，甚至引發內存溢出。
- 響應時間上升、超時阻塞。由于redis是單線程架構，操作大key耗時較長，有可能造成redis阻塞。
- 過期時可能阻塞。大key設定了過期時間，當過期時這個key會被刪除。假如redis版本低于4.0沒有非同步刪除機制，就會存在阻塞redis的可能性，并且慢查詢查不到；同樣，內存不足時的key驅逐或者是rename一個大key也會阻塞redis服務。長時間阻塞主庫，可能會引發同步中斷或主從切換。
慢查詢為什么查不到。舉例，如果請求進來且redis服務器正在進行過期鍵掃描，需要等待100毫秒。當客戶端設置的超時時間小于100毫秒，那就會導致連接因為超時而關閉，就會造成異常，這些現象并不能從慢查詢日志中查詢到（因為慢查詢只記錄邏輯處理過程，不包括等待時間）。
- 網絡擁塞。例如：一個大key占用空間是1MB，每秒訪問1000次，就有1000MB的流量，可能造成機器或局域網的帶寬被打滿，同時波及其他服務。
發現方法
使用工具定期掃描，并建立好監控和通知機制。
- 優點：不阻塞服務
- 缺點：信息較少（只有各類型最大的key信息），內容不夠精確（例如hash/list/set/zset都是以元素個數衡量大key，但實際上元素個數多不代表占用內存大）。
- redis-cli --bigkeys 命令。可以用來找到某個實例5種數據類型(string、hash、list、set、zset)最大的key。
- redis-rdb-tools 工具。redis實例上執行bgsave，然后對dump出來的rdb文件進行分析。
- 優點：獲取信息更詳細
- 缺點：需要離線操作，獲取結果時間較長
- Redis4.0之后，新增 memory usage 命令，通過隨機抽樣field的方式估算key的大小（樣本越大，循環次數越多，計算結果越精確，性能消耗也越多）。編寫python腳本，利用 scan 和 memory usage 命令，可以在集群低峰的時候掃描redis，排查大key。
- 優點：獲取信息較準確且及時
- 缺點：python腳本需要注意不能影響線上正常服務，設置好監控和熔斷。
常用的處理方法
- 大key非熱key，如果不是必要的信息，可以直接刪除del或者unlink都可以。
如果是redis4.0之前的版本，建議對于key使用(scan/sscan/hscan/zscan)，將大key逐步刪除（ltrim/zremrangebyscore/hdel/srem）。redis4.0之后，直接使用unlink替換del，會有后臺線程將大key異步刪除。
- 業務拆分，將key的含義更細粒度化，避免大key出現。
- 數據結構上拆分。如果大key是個大json，可以通過mset的方式，將這個key的內容打散到各個實例中，減小大key對數據量傾斜的影響；如果是大list，可以拆成 list_1,list_2,list_N ；其他數據結構同理。（可以考慮增加單獨key存儲大key被拆分的個數或元數據信息）
- 在redis沒有開啟非同步刪除機制的場景下，設置過期時間時，一定要避免大批量鍵同時過期的現象，所以如果有這種情況，最好給過期時間加個隨機范圍，緩解大量鍵同時過期，造成客戶端等待超時的現象。
- 對于長文本，更建議使用文檔型數據庫例如MongoDB等。
- 對一致性要求不高的場景，嘗試使用客戶端緩存。（只解決了redis的阻塞問題，但機器或局域網的帶寬問題沒有改善）
- 對大key的壓縮。相當于用cpu資源來降低網絡io，其中google提出的snappy算法較常用。
- 對于hash等數據結構，需要注意業務是否可以引入定期清理無效field的機制。
