Redis的内存分析（set/get命令集）

为了知道Redis是如何使用内存的，我分析了源码。这篇文章针对的是set/get命令集，也就是key、value都是简单的字符串。除此之外，Redis还支持像hset/hget命令，它们的value是一个字典，留到以后分析。 首先来看看Redis存储数据的关键数据结构： 1. zmalloc （

为了知道Redis是如何使用内存的，我分析了源码。这篇文章针对的是set/get命令集，也就是key、value都是简单的字符串。除此之外，Redis还支持像hset/hget命令，它们的value是一个字典，留到以后分析。

首先来看看Redis存储数据的关键数据结构：

1. zmalloc （见zmalloc.h）

Redis是用zmalloc管理内存的，其底层可以是glibc malloc、jemalloc、tcmalloc，具体由用户选择，目前的版本默认为jemalloc。本文不分析jemalloc，而是从zmalloc这一层开始往上分析。

zmalloc封装了底层内存管理，并为每一段申请的内存增加了一个头部，大小为PREFIX_SIZE = 8字节，这个头部记录了申请内存的大小。因此每一块申请的内存有额外的8字节内存开销。

2. sds （见sds.h)

sds是Redis使用的字符串工具，取代string.h。sds的结构体如下，包含4=4=8字节的头部，buf后面就是字符串的空间。因此每个字符串需要8字节的额外空间。

struct sdshdr {
    unsigned int len;
    unsigned int free;
    char buf[];
};

3. 哈希表（见dict.h)

这是核心数据结构，所有的key value都存在哈希表内。dict是哈希表的元数据，ht[2]数组是实际的哈希表，ht[0]是当前使用的哈希表；当数据太多（超过了ht[0]的数组大小），就分配2倍大的ht[1]，然后逐渐将数据从ht[0]迁移到ht[1]。由于dict结构体是唯一的，它的内存开销可以忽略不计。

dictht是实际的哈希表，包含一个指针数组，数组的每一项是指向dictEntry的指针，被哈希到同一项的数据以链表的方式解决冲突。

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

/* This is our hash table structure. Every dictionary has two of this as we
* implement incremental rehashing, for the old to the new table. */
typedef struct dictht {
    dictEntry **table;
    unsigned long size;
    unsigned long sizemask;
    unsigned long used;
} dictht;

typedef struct dictEntry {
    void *key;
    union {
    void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    struct dictEntry *next;
} dictEntry;

在redis中，key是sds字符串，而value则是robj数据结构。当插入一对key-value，会产生一个dictEntry，key指向一个sds字符串，而v.val指向一个robj。dictEntry的大小为24字节。

4. 对象robj（见redis.h）

robj结构体如下。ptr指向数据；type指明数据的类型（比如可以是sds字符串）；encoding表示是否进行了编码（即压缩字符串，见下文）；lru用于实现lru替换策略，每次查询都会更新lru的值；refcount是引用次数，因为Redis允许共享对象，节约内存。robj结构体的大小为16字节。

#define REDIS_LRU_CLOCK_RESOLUTION 1000 /* LRU clock resolution in ms */
typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */
    int refcount;
    void *ptr;
} robj;

内存分析

每一对key-value，需要一个sds字符串存储key，这需要额外8字节zmalloc头部+8字节sds头部，一共16字节；需要一个robj存储value，robj->ptr实际指向一个sds字符串（假设没有压缩），这需要额外16字节的robj + 8字节zmalloc头部，以及robj->ptr指向的字符串的8字节zmalloc头部和8字节sds头部，一共40字节。

插入哈希表后，需要一个24字节的dictEntry和8字节的zmalloc头部，以及一个指针数组中的8字节指针，一共40字节。

最终，每个key-value对，除去数据本身，一共需要额外 16 +40 +40 = 96字节的元数据。并且这96个字节分属于四个不同的内存区块（这里忽略哈希表指针数组）：

1. 存储key的sds字符串（8+8+keylen）；
2. 存储robj（8+16）；
3. 存储robj->ptr对应的value（8+8+vallen）；
4. 存储dictEntry（8+24）。

其中2、4是定长的小内存，1、3是变长内存。

对于key-value较小的负载，这些元数据开销并不低；以我上篇实验为例，采用了20字节的key和100字节的value，元数据开销占96/(120+96)=44.4%。

以上为set/get命令的分析，hset/hget命令的内存开销应该会更高，留待以后分析。

Redis如何节约内存

Redis通过对字符串压缩、共享对象等方式节约内存：对于每一个字符串value，Redis都尝试一下方法：

1. 如果字符串全部由数字组成，则尝试将其表示为长整形。最多可以将21字节压缩成8字节。因为指针ptr是8字节，数值可以直接存在ptr里面而无需额外内存，又节约了8字节。

2. 如果整型编码成功，且数值在1-10000之间，则使用共享对象，因为1-10000这些对象已经实现创建好了。

3. 如果整型编码不行，但是字符串又

原文地址：Redis的内存分析（set/get命令集）, 感谢原作者分享。