當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

Redis进阶-Redis键值设计及BigKey问题

發布時間：2025/3/21 数据库 67 豆豆

生活随笔收集整理的這篇文章主要介紹了 Redis进阶-Redis键值设计及BigKey问题小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

(2)【建議】：簡潔性

保證語義的前提下，控制key的長度，當key較多時，內存占用也不容忽視，例如：
user:{uid}:friends:messages:{mid} 簡化為 u:{uid}🇫🇷m:{mid}

我們知道，Redis 的一個字符串最大512M，一個二級數據結構（比如 hash、list、set 、zset）可以存儲2^32-1 個元素，約40億個元素。但是不是以為著我們可以任意存儲元素呢？時刻牢記，在讀寫這個角度上，目前Redis還是單線程的。

其實不然，按照經驗來說，如何定義bigKey 呢?

一般來說，string類型控制在10KB以內，hash、list、set、zset元素個數不要超過5000。當然了這不是絕對的，請依據場景，靈活處理。

我們來看個反例：一個hash 存儲用戶信息，我有100萬用戶，我全都放到一個key里。。。。這不管從哪個角度看，bigkey無疑。

一般來說，bigkey的產生都是由于程序設計不當，或者對于數據規模預料不清楚造成的，來看幾個例子：

社交類：粉絲列表，如果某些明星的粉絲數據，如果不精心設計下，一個明星的粉絲百萬很少了吧，你都把這百萬的粉絲數據放到一個key中存儲，毫無疑問是bigkey
統計類：比如按天存儲某項功能或者網站的用戶集合，用戶很少，倒是沒多大問題，一旦用戶多了起來，必是bigkey
緩存類：將數據從數據庫加載出來以后序列化放到Redis里，這個方式非常常用，但有兩個地方需要注意，第一，是不是有必要把所有字段都緩存；第二，有沒有相關關聯的數據，不要為了圖方便把相關數據都存一個key下，產生bigkey。

核心思想：分治拆分

拆
big list： list1、list2、…listN
big hash：可以講數據分段存儲，比如一個大的key，假設存了1百萬的用戶數據，可以拆分成 200個key，每個key下面存放5000個用戶數據
如果bigkey不可避免，也要思考一下要不要每次把所有元素都取出來(例如有時候僅僅需要
hmget，而不是hgetall)，刪除也是一樣，盡量使用優雅的方式來處理
【推薦】：選擇適合的數據類型

例如：實體類型(要合理控制和使用數據結構，但也要注意節省內存和性能之間的平衡)
反例：
set user:1:name tom set user:1:age 19 set user:1:favor football
正例:
hmset user:1 name tom age 19 favor football
【推薦】：控制key的生命周期，redis不是垃圾桶

建議使用expire設置過期時間(條件允許可以打散過期時間，防止集中過期)。

對于非字符串的bigkey,比如 hash list set zset , 不要使用del 刪除，請使用 hscan 、sscan、zscan方式漸進式刪除。

同時要注意防止bigkey過期時間自動刪除問題(例如一個100萬的hash設置1小時過期，會觸發del操作，造成阻塞）

導致redis阻塞

這個也很好理解：我們知道Redis 官方號稱10萬QPS，我們通常打不到這個值，但是大幾萬的QPS還是沒問題的，這也就意味著 redis 的執行速度 1秒幾萬條，速度相當的快的。假設你有個bigKey , 操作一次耗時1秒，那Redis 單線程在這1秒鐘就只能處理你這個Key, 后面堵了一堆請求。。。。并且你的應用序列化和反序列化這種大key , 也消耗CPU 。
導致網絡擁塞

假設我們的交換機，千兆網絡（小b），那么實際帶寬 1024 / 8 = 128M . 假設你的這個key的大小 500KB，客戶端并發 1000獲取這個key，那么就意味著 1000 * 500KB = 500M ,那就是每秒產生500M的流量。先不說你的Redis能不能處理的過來這個并發下的bigKey，單說你的這個千兆網絡，你說你這個網絡I/O能扛得住嗎？一般服務器會采用單機多實例的方式來部署，也就是說一個bigkey可能會對其他實例也造成影響，其后果不堪設想。

以上是生活随笔為你收集整理的Redis进阶-Redis键值设计及BigKey问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。