Redis为什么要避免big key

避免 big key

Redis 执行命令是单线程的，这意味着 Redis 操作「big key」有阻塞的风险。

big key 通常指的是 Redis 存储的 value 过大。包括：

• 单个 value 过大。如 200M 大小的 String。

• 集合元素过多。如 List、Hash、Set、ZSet 中有几百、上千万数据。

举个例子，假设我们有一个 200M 大小的 String key，名称为「foo」。

执行如下命令

127.0.0.1:6379> GET foo

当返回结果时，Redis 会分配 200m 的内存，并执行 memcpy 拷贝。

void _addReplyProtoToList(client *c, const char *s, size_t len) {
    ...
    if (len) {
        /* Create a new node, make sure it is allocated to at
         * least PROTO_REPLY_CHUNK_BYTES */
        size_t size = len < PROTO_REPLY_CHUNK_BYTES? PROTO_REPLY_CHUNK_BYTES: len;
        // 分配内存（例子中为 200m）
        tail = zmalloc(size + sizeof(clientReplyBlock));
        /* take over the allocation's internal fragmentation */
        tail->size = zmalloc_usable_size(tail) - sizeof(clientReplyBlock);
        tail->used = len;
        // 内存拷贝
        memcpy(tail->buf, s, len);
        listAddNodeTail(c->reply, tail);
        c->reply_bytes += tail->size;

        closeClientOnOutputBufferLimitReached(c, 1);
    }}

而 Redis 输出 buf 为 16k

// server.h#define PROTO_REPLY_CHUNK_BYTES (16*1024) /* 16k output buffer */typedef struct client {
    ...
    char buf[PROTO_REPLY_CHUNK_BYTES];} client;

这意味着 Redis 无法单次返回响应数据，需要注册「可写事件」，从而触发多次 write 系统调用。

这里有两个耗时点：

• 分配大内存（也可能释放内存，如 DEL 命令）

• 触发多次可写事件（频繁执行系统调用，如 write、epoll_wait）

那么，如何找出 big key 呢？

如果 slow log 出现了简单命令，如 GET、SET、DEL，大概率是出现了 big key。

127.0.0.1:6379> SLOWLOG GET
    3) (integer) 201323  // 单位微妙
    4) 1) "GET"
       2) "foo"

其次，可以通过 Redis 分析工具来查找 big key。

$ redis-cli --bigkeys -i 0.1
...
[00.00%] Biggest string found so far '"foo"' with 209715200 bytes

-------- summary -------

Sampled 1 keys in the keyspace!
Total key length in bytes is 3 (avg len 3.00)

Biggest string found '"foo"' has 209715200 bytes

1 strings with 209715200 bytes (100.00% of keys, avg size 209715200.00)
0 lists with 0 items (00.00% of keys, avg size 0.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)

对于 big key，有以下几点建议：

1.业务中尽量避免 big key 出现。当出现 big key 时，你要判断这样设计是否合理，又或者是出现了 bug。

2.将 big key 拆分为多个小 key。

3.使用替代命令。

• 如果 Redis 版本大于 4.0，可使用 UNLINK 命令替代 DEL。Redis 版本大于 6.0，可开启 lazy-free 机制。将释放内存操作，放到后台线程执行。

• LRANGE、HGETALL 等替换为 LSCAN、HSCAN 分次获取。

但我还是建议在业务中避免 big key。