本文是对reids对象系统的一个简单梳理,作为个人备忘。
redis 是由c实现的一个kv内存数据库。key 与value 都在内存中创建并维护，不难看出，redis 一定有着一套自己的内存管理机制。无论是key 还是value,自redis 中都是以redisObject 的形式存在，因此下面先介绍redisObject。
1.redisObject概述
redisObject 的数据结构定义如下：
typedef struct redisObject {
unsigned type:4;
unsigned encoding:4;
unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
* LFU data (least significant 8 bits frequency
* and most significant 16 bits decreas time). */
int refcount;
void *ptr;
} robj;
结构中各个成员含义如下：
type
记录了对象的类型，众所周知redis中存在5种数据类型如下：
| 常量 | 类型 |
|---|---|
| OBJ_STRING(0) | 字符串(string) |
| OBJ_LIST(1) | 列表(list) |
| OBJ_HASH(4) | 哈希(hash) |
| OBJ_SET(2) | 集合(set) |
| OBJ_ZSET(3) | 有序集合(zset) |
encoding
代表了给定对象当前采用的具体的数据结构。其取值如下：
#define OBJ_ENCODING_RAW 0 /* 原始字符串 */
#define OBJ_ENCODING_INT 1 /* 整数字符串 */
#define OBJ_ENCODING_EMBSTR 8 /* 紧凑型字符串 */
#define OBJ_ENCODING_QUICKLIST 9 /* 压缩列表链表 */
#define OBJ_ENCODING_LINKEDLIST 4 /*双端链表*/
#define OBJ_ENCODING_ZIPLIST 5 /* 压缩列表*/
#define OBJ_ENCODING_HT 2 /*hashtable*/
#define OBJ_ENCODING_ZIPMAP 3 /*zipmap*/
#define OBJ_ENCODING_INTSET 6 /* 整数集合*/
#define OBJ_ENCODING_SKIPLIST 7 /* 跳跃表 */
refcount
对象的引用计数。不难知道，refcount =0 代表这个对象可以被释放掉。
lru
记录对象上次被访问的时间点。
ptr
最后ptr指针指向了对象的具体数据结构。
2.redis对象的内存内存结构
2.1 字符串
字符串有三种编码格式分别为
#define OBJ_ENCODING_RAW 0 /* 原始字符串 */
#define OBJ_ENCODING_INT 1 /* 整数字符串 */
#define OBJ_ENCODING_EMBSTR 8 /* 紧凑型字符串 */
原始字符串模式下 redisObject->ptr 指向的是一个普通的sds字符串。
如果当前字符串是一个整数时，会直接用ptr变量本身保存整数(前提是整数值不会导致溢出)。
紧凑型字符串编码是专门用于保存短字符串。
这种情况下sds字符串对象在内存排布上与redisObject对象是连续的。这种设计思想在python的dict结构中有类似的体现。
2.2 列表
列表目前有三种编码形式
#define OBJ_ENCODING_QUICKLIST 9 /* 压缩列表链表 */
#define OBJ_ENCODING_LINKEDLIST 4 /*双端链表*/
#define OBJ_ENCODING_ZIPLIST 5 /* 压缩列表*/
双端链表模式下,对象内存布局如下:
image
可见双端链表的每个节点都是一个字符串对象。
压缩列表模式下：对象内存布局如下：
image
注意:采用ziplist编码时，内存布局如下，在ziplist中，每个节点中保存的是经过简单包装的原始字符串(“three”)或者数字(123)，而非redisObject结构，或者sdshdr结构
压缩列表链表模式，相当于前两者的综合，在redis3 以上的版本中取代了单纯的双向链表作为元素较多时的列表实现
image
2.3 哈希表
哈希表的编码有两种：
#define OBJ_ENCODING_ZIPLIST 5 /* 压缩列表*/
#define OBJ_ENCODING_HT 2 /*hashtable*/
采用hashtable 编码时，内存布局如下
image
ptr直接指向一个redis哈希表结构。
采用压缩列表时，键值对存放在前后连续排放的entry中。
image
2.4 集合
在很多系统中，set与map往往采用相同的数据结构去实现。redis中的集合体层结构也与哈希表一样，正常情况下都采用一个hashtable 去实现
当编码为hashtable时，集合对象的ptr 指向了一个value=nil的hashtable。
与哈希表不同的是，在元素较少时，集合对象采用了整数集合结构去做体层实现而不是采用压缩列表
2.5 有序集合
有序集合编码有如下两种:
#define OBJ_ENCODING_SKIPLIST 7 /* 跳跃表 */
#define OBJ_ENCODING_ZIPLIST 5 /* 压缩列表*/
在压缩列表编码格式下,元素与分值存放在前后连续排放的entry中。
image
而在跳跃表编码格式下，redis同时采用了跳跃表和哈希表来对数据进行保存。这样做的目的，在于将查询给定元素的分值这一操作的时间复杂度降为o(1),同时又用跳跃表去维护分值的有序性。这个做法类似于lru的实现。
image
3.redis对象的内存管理
3.1 垃圾回收
redis 内存对象的垃圾回收，采用的是引用计数去维护。之所以可以采用这正简单的机制，原因在于redis对象之间没有深层次的嵌套，因此也就不存在循环引用的隐患。
3.2 内存共享优化
redis 在初始化服务器时，会创建10000个字符串对象，包含了0-9999的所有整数值，当服务器需要用到0-9999的字符串对象时，服务器就会共享这些对象，而不是创建新对象，这点是与python 的机制是一样的。
网友评论