问题描述

在使用redis scan命令的时候发现这个count经常和实际的数据量对不上，count 3，4，5，出来的都是5个，只有部分是准的。这就有点神奇了。我们先看一下这个命令是干什么的，再看一下能不能从官网或者源码中寻找答案，为啥会出现这种现象。

问题追踪

scan命令

SCAN 命令是 Redis 提供的一种迭代器(iterator)方式，用于遍历数据库中的所有键(key)。该命令可以将遍历过程分成多个步骤，每次迭代只返回一小部分数据，这样可以有效地避免阻塞 Redis 服务器。具体来说，该命令的语法为：

SCAN cursor [MATCH pattern] [COUNT count]

其中，cursor 参数指定了迭代器当前的位置，可以将其看作是一个游标。在第一次调用时，该参数应该设置为 0。MATCH 参数用于指定一个模式(pattern)，只有符合模式的键才会被返回。COUNT 参数指定了每次迭代返回的最大键数。

命令KEYS 功能和SCAN 类似，但是不建议在生产环境使用，它需要遍历整个数据库来查找符合条件的键，因此在大型数据库中使用该命令可能会导致 Redis 服务器阻塞。

实现原理

1 redis的存储结构

typedef struct dict {
    dictType *type;
    void *privdata;
    dictht ht[2];
    long rehashidx; /* rehashing not in progress if rehashidx == -1 */
    unsigned long iterators; /* number of iterators currently running */
} dict;

redis的所有数据都是存到一个dict中去，删除的时候调用dictDelete(dict,key)，添加调用dictAdd(dict, key, val)。其中ht的长度有2个，存了两个哈希表，dict使用第一个哈希表，第二个哈希表是对ht[0]进行rehash操作的时候使用的。我们继续看一下这个dictht哈希表，

typedef struct dictht {      // 总的hash表
    dictEntry **table;       // 存储的数组
    unsigned long size;      // 哈希表大小
    unsigned long sizemask;  // 用于计算index数据的索引index=dictHashKey(d, key) & d->ht[table].sizemask
    unsigned long used;      // 该哈希表中已有结点的数量
} dictht;

typedef struct dictEntry {   // kv条目，存储key和value指针
    void *key;
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    struct dictEntry *next;  // 指向下一个kv条目，形成链表
} dictEntry;

大致的结构如下：

暂时无法在文档外展示此内容

2 redis的scan流程

scan命令就是对这个dictht进行dictScan方法，

// dictScan简化版，不考虑正在rehash的情况
unsigned long dictScan(dict *d,               // 上文提到的dict
                       unsigned long v,       // 游标cursor
                       dictScanFunction *fn,  // 数据收集函数
                       void *privdata)
{
    dictht *t0;
    const dictEntry *de, *next;
    unsigned long m0;

    t0 = &(d->ht[0]);
    m0 = t0->sizemask;

    de = t0->table[v & m0];                // 上文提到的dictEntry
    while (de) {                           // 遍历链表
        next = de->next;
        fn(privdata, de);                  // 把数据放入收集函数
        de = next;
    }

    // 返回下一个游标
    v |= ~m0;
    v = rev(v);
    v++;                    
    v = rev(v);

    return v;
}

从dictScan方法可以看到每次dictScan是scan一个链表，不是scan一个值。

再看一下这个dictScan方法是怎么被调用的

long maxiterations = count*10;

/* We pass two pointers to the callback: the list to which it will
 * add new elements, and the object containing the dictionary so that
 * it is possible to fetch more data in a type-dependent way. */
do {
    cursor = dictScan(ht, cursor, scanCallback, NULL, privdata);
} while (cursor &&
      maxiterations-- &&
      listLength(keys) < (unsigned long)count);

这个dictScan方法最多调用count * 10 次，如果count*10次之后还是len(keys) < count， 这个时候就会出现数据小于count的情况。每次dictScan都是扫描一个链表，所以当链表中的值有多个时，会存在len(keys)>count的情况。

redis 为啥不返回确切的数量，而是选择返回一个忽大忽小的数量，这个是出于性能考虑的，反正这个count的大小对功能来说没有什么影响，没有必要这么处理。

AI回答

上面的人工回答可能描述不够清楚，再补一个当下比较热门的AI回答。

总结

通过Redis的scan命令的count数据对不上，我们顺着流程又梳理redis的存储结构。就是通过无数个这种小设计，从而实现软件的高性能。