为了知道Redis是如何使用内存的,我分析了源码。这篇文章针对的是set/get命令集,也就是key、value都是简单的字符串。除此之外,Redis还支持像hset/hget命令,它们的value是一个字典,留到以后分析。 首先来看看Redis存储数据的关键数据结构: 1. zmalloc (
为了知道Redis是如何使用内存的,我分析了源码。这篇文章针对的是set/get命令集,也就是key、value都是简单的字符串。除此之外,Redis还支持像hset/hget命令,它们的value是一个字典,留到以后分析。
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个字节分属于四个不同的内存区块(这里忽略哈希表指针数组):
其中2、4是定长的小内存,1、3是变长内存。
对于key-value较小的负载,这些元数据开销并不低;以我上篇实验为例,采用了20字节的key和100字节的value,元数据开销占96/(120+96)=44.4%。
以上为set/get命令的分析,hset/hget命令的内存开销应该会更高,留待以后分析。
Redis通过对字符串压缩、共享对象等方式节约内存:对于每一个字符串value,Redis都尝试一下方法:
1. 如果字符串全部由数字组成,则尝试将其表示为长整形。最多可以将21字节压缩成8字节。因为指针ptr是8字节,数值可以直接存在ptr里面而无需额外内存,又节约了8字节。
2. 如果整型编码成功,且数值在1-10000之间,则使用共享对象,因为1-10000这些对象已经实现创建好了。
3. 如果整型编码不行,但是字符串又
原文地址:Redis的内存分析(set/get命令集), 感谢原作者分享。