Redis鍵值設計使用的方法是什么

這篇文章主要介紹了Redis鍵值設計使用的方法是什么的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇Redis鍵值設計使用的方法是什么文章都會有所收獲，下面我們一起來看看吧。

Redis使用中不規范的現象

• Redis 存儲的key命名不規范，比較隨意；

• Redis 被當成存儲庫使用，存在數據丟失風險，且無重新加載方案；

• Redis 緩存key，未設置過期時間， 緩存低頻數據占用大量內存， 進而導致服務崩潰；

• Redis 緩存大量big key, 應用獲取時會占用大量網絡帶寬，刪除也容易造成阻塞；

• Redis 客戶端使用不當，導致其它客戶端連接timeout, 原因可能客戶端密碼錯誤，且沒有使用連接池，大量連接重試導致系統端口資源耗光；

• Redis 客戶端命令使用不當，導致大量的慢查詢，影響其它應用業務，比如在業務高峰期時使用 keys* 或flushall 這樣的命令；

Redis 使用業務場景推薦與建議

• 高并發場景：熱點數據緩存， 可提升系統整體響應速度，降低數據庫IO壓力 ；

• 限時場景：利用Redis expire命令設置session過期和續期、手機驗證碼等；

• 排行榜： 利用Redis list 和 sorted sets 數據結構能實現各種復雜的排行榜應用；

• 數據集合操作：利用Redis list、set、sorted set， 方便進行數據計算， 如交集、并集、差集等；

• 連續簽到：可以利用redis的bitmap數據結構實現簽到相關的業務；

• 計數器：利用Redis incr、incrby命令實現api調用次數統計， api限流等場景；

• 分布式鎖：利用 Redis 的 setnx 功能來編寫分布式的鎖, 典型開源組件比如redisson；

如何設計出優雅的key

可以這么說，線上關于redis的性能優化這個問題上，不合理的key的設計經常是引發問題的根因，究其本質，就個人看到的情況來說，大多數同學在對redis使用過程中，對于key的設計幾乎是沒有什么概念的，因為大多數同學使用的場景就是 key/val ，對應的數據結構就是 字符串key/字符串val；

稍微對redis有更深入的了解的同學，在進行存儲時，可能會知道 key的設計盡量短一點，中間最好有層次感，最好以 ： 進行分割 ......

那么如何才能設計出比較優雅的key呢？下面結合小編實際使用中的經驗以及踩過的坑，來具體談談；

一、遵循如下幾個最佳實踐約定

1. 遵循基本格式：[業務名稱]:[數據名]:[id]；

2. key的長度不超過44字節；

3. 不要包含特殊字符；

關于上面幾條建議，這樣做有如下幾點好處：

• 可讀性強，比如當我們設計這樣的key結構， order:user:10，一眼看過去就知道這是關于用戶訂單相關的key；

• 方便維護管理，不同的應用，或者不同的業務采用不同的前綴，在可視化客戶端工具或者命令行中很方便進行key的查找定位；

• 避免key沖突，避免在使用過程中多個人都用userId這樣的值作為key引發的緩存key沖突；

• 更節省內存： key是string類型，底層編碼包含int、embstr和raw三種。embstr在小于44字節使用，采用連續內存空間，內存占用更小；

推薦值：

• 單個key的value小于10KB；

• 對于集合類型的key，建議元素數量小于1000；

二、盡量避免bigkey

1、什么是bigkey呢

BigKey通常以Key的大小和Key中成員的數量來綜合判定，例如：

• Key本身的數據量過大：一個String類型的Key，它的值為5 MB；

• Key中的成員數過多：一個ZSET類型的Key，它的成員數量為10,000個；

• Key中成員的數據量過大：一個Hash類型的Key，它的成員數量雖然只有1,000個但這些成員的Value（值）總大小為100 MB；

2、BigKey的危害

網絡阻塞

• 對BigKey執行讀請求時，少量的QPS就可能導致帶寬使用率被占滿，導致Redis實例，乃至所在物理機變慢；

數據傾斜

• BigKey所在的Redis實例內存使用率遠超其他實例，無法使數據分片的內存資源達到均衡；

Redis阻塞

• 對元素較多的hash、list、zset等做運算會耗時較舊，使主線程被阻塞；

CPU壓力

• 對BigKey的數據序列化和反序列化會導致CPU的使用率飆升，影響Redis實例和本機其它應用；

3、如何發現BigKey

在安裝的機器上執行 redis-cli --bigkeys命令

• 利用redis-cli提供的--bigkeys參數，可以遍歷分析所有key，并返回Key的整體統計信息與每個數據的Top1的big key；

通過scan掃描

• 編寫程序，利用scan掃描Redis中的所有key，利用strlen、hlen等命令判斷key的長度（此處不建議使用MEMORY USAGE）；

使用第三方工具

• 利用第三方工具，如 Redis-Rdb-Tools 分析RDB快照文件，全面分析內存使用情況；

使用網絡監控

• 自定義工具，監控進出Redis的網絡數據，超出預警值時主動告警；

三、使用恰當的數據類型

正如上面所說，很多初次使用redis的同學，對于很多業務場景，都是一個key/val的簡單的結構搞定，而不會深入思考這樣做是否合理，或者說這樣做以后會不會引發相關的性能方面的問題；

對于這個問題，從根本上來說，需要深入了解并掌握redis的常用的數據類型，在這個基礎上，才能針對不同的業務場景，設計出高效的存儲存儲結構數據；

讓我們思考一下，如何緩存用戶對象列表這樣的數據呢？

• 方案1：key為usrId，value為對象的序列化字符串，數據結構類似下面這樣； 

優點：存取方便，簡單粗暴，存取時只需要做下json和對象的互轉即可；

缺點：數據耦合，不夠靈活，一旦對象新增了字段或刪減了字段，緩存重建的成本非常大；

• 方案2：使用一個list結構，緩存用戶ID列表，數據結構如下；

優點：對內存的占用小，操作高效；

缺點：獲取到val之后，需要進一步查庫才能得到完整的對象；

方案3：使用hash結構，緩存對象，數據如下所示；

優點：底層使用ziplist，空間占用小，可以靈活訪問對象的任意字段；

缺點：編碼上相對復雜；

Redis 緩存在實際應用中的使用建議

• 【推薦】對緩存進行預熱。在訪問數據前，應先對緩存進行預熱，避免大量請求直接進入數據存儲層；應根據業務情況劃分合適的冷熱數據，對熱點數據進行預熱。如許可授權信息， apikey等；

• 【推薦】配合使用本地緩存。使用本地緩存能更穩定、更快速地訪問到數據，但在分布式架構下，要慎用本地緩存，避免造成服務器節點帶狀態。同時由于本地緩存直接占用應用服務器的資源，要避免過度占用資源導致應用節點崩潰；

• 【推薦】緩存變更策略，應先更新數據庫，再更新緩存；

• 【推薦】一次業務調用需要訪問多次redis服務端，可采用pipleline或其它批量操作方式；

• 【推薦】大List,Set,Hash,存儲的數量巨大。獲得大量元素時延遲較大阻塞其他命令.建議切割成多個小的list,set,hash；

使用業務規范

不管是redis，還是其他開發中使用到的中間件，具體到開發使用時，最好都應該提前制定出一套合理的規范，這個規范應該是大多數開發人員認可并在實踐中得到檢驗，且能有效規避一些問題的，一旦指定為規范，應該成為指導內部開發人員日常的規則，這里提如下幾點：

• Redis 應該定位為緩存數據， 不可用于存儲大規模數據（不可替代數據庫）；

• Redis 適合讀多寫少場景，如存在高頻寫入，低頻查詢場景，則不推薦使用；

• 在不確定key的存活時間時，最好設置過期時間，控制 key 的生命周期；

• 應該考慮冷熱數據分離，對于查詢， 高頻次業務查詢走Redis，低頻查詢考慮走數據庫；

• Redis 有數據丟失風險，程序處理數據時，應該考慮數據丟失后能自動從數據庫加載并緩存到Redis；

• 謹慎使用O(N)命令， 如list, set, hash 數據結構操作時， hgetall、lrange、smembers、zrange等并非不能使用，優先考慮使用 hscan、sscan、zscan 代替。

關于“Redis鍵值設計使用的方法是什么”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“Redis鍵值設計使用的方法是什么”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。