redis内存分析

为了知道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个字节分属于四个不同的内存区块（这里忽略哈希表指针数组）： 

　　存储key的sds字符串（8+8+keylen）； 

　　存储robj（8+16）； 

　　存储robj->ptr对应的value（8+8+vallen）； 

　　存储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. 如果整型编码不行，但是字符串又<=39字节，就使用嵌入式字符串。就是将字符串直接放在robj的后面。这种方式并不直接节约内存，但是它将上述4个内存区块减少为3个，减少了外部碎片问题。 

原文地址：http://fumin.hustbackup.cn/?p=1172