写在前面

前方高能！前方高能！前方高能！文章较长，可能需要花费您两个小时的时间，请做好心理准备，但是一旦你准备看下去，我相信您一定会有收获，不枉此行，let’s go!!!

一、简单动态字符串

说明：

Redis没有直接使用C语言传统的字符串表示(以空字符结尾的字符数组， 以下简称C字符串) ， 而是自己构建了一种名为简单动态字符串(simple dynamic string， SDS) 的抽象类型， 并将SDS用作Redis的默认字符串表示。

SDS的定义代码

 struct sdshdr { //记录buf数组中已使用字节的数量 //等于SDS所保存字符串的长度 int len; //记录buf数组中未使用字节的数量 int free; //字节数组， 用于保存字符串 //最后一个字节则保存了空字符'\0',遵循C字符串以空字符结尾的惯例  //不计算在SDS的len属性里面  char buf[];

};

SDS图示说明

C字符串和SDS之间的区别

Redis只会使用C字符串作为字面量， 在大多数情况下， Redis使用SDS(Simple Dynamic String， 简单动态字符串) 作为字符串表示。

重点总结：

·Redis只会使用C字符串作为字面量， 在大多数情况下， Redis使用SDS(Simple Dynamic String， 简单动态字符串) 作为字符串表示。

·比起C字符串， SDS具有以下优点：

1) 常数复杂度获取字符串长度。

2) 杜绝缓冲区溢出。

3) 减少修改字符串长度时所需的内存重分配次数。

4) 二进制安全。

5) 兼容部分C字符串函数。

二、链表

说明

因为Redis使用的C语言并没有内置这种数据结构， 所以Redis构建了自己的链表实现。

链表结构定义

代码节点listNode说明：

typedef struct listNode { //前置节点 struct listNode * prev; //后置节点 struct listNode * next; //节点的值void * value;

}listNode;

节点图示说明：

链表list结构代码说明：

typedef struct list { //表头节点 listNode * head; //表尾节点 listNode * tail; //链表所包含的节点数量unsigned long len;//节点值复制函数void *(*dup)(void *ptr);//节点值释放函数void (*free)(void *ptr);//节点值对比函数int (*match)(void *ptr,void *key);

} list;

list图示说明：

特点：双端、无环、带表头指针和表尾指针、带链表长度计数器、多态

重点总结：

·链表被广泛用于实现Redis的各种功能， 比如列表键、 发布与订阅、 慢查询、 监视器等。

·每个链表节点由一个listNode结构来表示， 每个节点都有一个指向前置节点和后置节点的指针， 所以Redis的链表实现是双端链表。

·每个链表使用一个list结构来表示， 这个结构带有表头节点指针、 表尾节点指针， 以及链表长度等信息。

·因为链表表头节点的前置节点和表尾节点的后置节点都指向NULL， 所以Redis的链表实现是无环链表。

·通过为链表设置不同的类型特定函数， Redis的链表可以用于保存各种不同类型的值。

三、字典

说明：

字典， 又称为符号表(sy mbol table) 、 关联数组(associative array) 或映射(map) ，是一种用于保存键值对(key-value pair) 的抽象数据结构。字典经常作为一种数据结构内置在很多高级编程语言里面， 但Redis所使用的C语言并没有内置这种数据结构， 因此Redis构建了自己的字典实现。

Redis的字典使用哈希表作为底层实现， 一个哈希表里面可以有多个哈希表节点， 而每个哈希表节点就保存了字典中的一个键值对。

Redis字典所使用的哈希表由dict.h/dictht结构定义

 typedef struct dictht { //哈希表数组 dictEntry **table; //哈希表大小 unsigned long size;//哈希表大小掩码， 用于计算索引值//总是等于size-1unsigned long sizemask;//该哈希表已有节点的数量unsigned long used;

} dictht;

hash表的图示：

table属性是一个数组， 数组中的每个元素都是一个指向dict.h/dictEntry结构的指针， 每个dictEntry结构保存着一个键值对。

hash表节点定义

typedef struct dictEntry {     //键     void *key;     //值     union{void *val;     uint64_tu64;     int64_ts64; } v; //指向下个哈希表节点， 形成链表struct dictEntry *next;} dictEntry;

next属性是指向另一个哈希表节点的指针， 这个指针可以将多个哈希值相同的键值对连接在一次， 以此来解决键冲突(collision) 的问题。举个例子， 图4-2就展示了如何通过next指针， 将两个索引值相同的键k1和k0连接在一起。

字典定义代码

typedef struct dict { //类型特定函数dictType *type; //私有数据 void *privdata; //哈希表 dictht ht[2]; // rehash索引 //当rehash不在进行时， 值为-1 in trehashidx; /* rehashing not in progress if rehashidx == -1 */} dict;

type属性和privdata属性是针对不同类型的键值对， 为创建多态字典而设置的：

·type属性是一个指向dictTy pe结构的指针， 每个dictType结构保存了一簇用于操作特定类型键值对的函数， Redis会为用途不同的字典设置不同的类型特定函数。

·而privdata属性则保存了需要传给那些类型特定函数的可选参数

.ht属性是一个包含两个项的数组， 数组中的每个项都是一个dictht哈希表， 一般情况下，字典只使用ht[0]哈希表， ht[1]哈希表只会在对ht[0]哈希表进行rehash时使用。除了ht[1]之外， 另一个和rehash有关的属性就是rehashidx， 它记录了rehash目前的进度， 如果目前没有在进行rehash， 那么它的值为-1。

 typedef struct dictType { //计算哈希值的函数 unsigned int (*hashFunction)(const void *key); //复制键的函数 void *(*keyDup)(void *privdata, const void *key); //复制值的函数void *(*valDup)(void *privdata, const void *obj);//对比键的函数int (*keyCompare)(void *privdata, const void *key1, const void *key2);//销毁键的函数void (*keyDestructor)(void *privdata, void *key);//销毁值的函数void (*valDestructor)(void *privdata, void *obj);

} dictType;

字典定义图示：

哈希算法说明

当要将一个新的键值对添加到字典里面时， 程序需要先根据键值对的键计算出哈希值和索引值， 然后再根据索引值， 将包含新键值对的哈希表节点放到哈希表数组的指定索引上面。

Redis计算哈希值和索引值的方法如下：

#使 用字典设置的哈希函数， 计算键key的哈希值

hash = dict->type->hashFunction(key);

#使用哈希表的sizemask属性和哈希值， 计算出索引值

#根据情况不同， ht[x]可以是ht[0]或者ht[1]

index = hash & dict->ht[x].sizemask;

hash算法举例

举个例子， 对于图4-4所示的字典来说， 如果我们要将一个键值对k0和v0添加到字典里面， 那么程序会先使用语句：

hash = dict->type->hashFunction(k0);

计算键k0的哈希值。

假设计算得出的哈希值为8， 那么程序会继续使用语句：

index = hash&dict->ht[0].sizemask = 8 & 3 = 0;

计算出键k0的索引值0， 这表示包含键值对k0和v0的节点应该被放置到哈希表数组的索引0位置上， 如图4-5所示。

当字典被用作数据库的底层实现， 或者哈希键的底层实现时， Redis使用MurmurHash2算法来计算键的哈希值。MurmurHash算法最初由Austin Appleby于2008年发明， 这种算法的优点在于， 即使输入的键是有规律的， 算法仍能给出一个很好的随机分布性， 并且算法的计算速度也非常快。MurmurHash算法目前的最新版本为MurmurHash3， 而Redis使用的是MurmurHash2， 关于MurmurHash算法的更多信息可以参考该算法的主页：http://code.google.com/p/smhasher/。

解决键冲突

当有两个或以上数量的键被分配到了哈希表数组的同一个索引上面时， 我们称这些键发生了冲突(collision) 。Redis的哈希表使用链地址法(separate chaining) 来解决键冲突， 每个哈希表节点都有一个next指针， 多个哈希表节点可以用next指针构成一个单向链表， 被分配到同一个索引上的多个节点可以用这个单向链表连接起来， 这就解决了键冲突的问题。
举个例子， 假设程序要将键值对k2和v2添加到图4-6所示的哈希表里面， 并且计算得出k2的索引值为2， 那么键k1和k2将产生冲突， 而解决冲突的办法就是使用next指针将键k2和k1所
在的节点连接起来， 如图4-7所示。
因为dictEntry节点组成的链表没有指向链表表尾的指针， 所以为了速度考虑， 程序总是将新节点添加到链表的表头位置(复杂度为O(1) ) ， 排在其他已有节点的前面。

rehash

随着操作的不断执行， 哈希表保存的键值对会逐渐地增多或者减少， 为了让哈希表的负载因子(load factor) 维持在一个合理的范围之内， 当哈希表保存的键值对数量太多或者太少时， 程序需要对哈希表的大小进行相应的扩展或者收缩。
扩展和收缩哈希表的工作可以通过执行rehash(重新散列) 操作来完成， Redis对字典的哈希表执行rehash的步骤如下：

1) 为字典的ht[1]哈希表分配空间， 这个哈希表的空间大小取决于要执行的操作， 以及ht[0]当前包含的键值对数量(也即是ht[0].used属性的值) ：

·如果执行的是扩展操作， 那么ht[1]的大小为第一个大于等于ht[0].used*2的2 ⁿ(2的n次方幂) ；

·如果执行的是收缩操作， 那么ht[1]的大小为第一个大于等于ht[0].used的2 ⁿ。

2) 将保存在ht[0]中的所有键值对rehash到ht[1]上面：rehash指的是重新计算键的哈希值
和索引值， 然后将键值对放置到ht[1]哈希表的指定位置上。

3) 当ht[0]包含的所有键值对都迁移到了ht[1]之后(ht[0]变为空表) ， 释放ht[0]， 将ht[1]设置为ht[0]， 并在ht[1]新创建一个空白哈希表， 为下一次rehash做准备。
举个例子， 假设程序要对图4-8所示字典的ht[0]进行扩展操作， 那么程序将执行以下步骤：

1) ht[0].used当前的值为4， 4*2=8， 而8(2 ³) 恰好是第一个大于等于4的2的n次方， 所以程序会将ht[1]哈希表的大小设置为8。图4-9展示了ht[1]在分配空间之后， 字典的样子。

2) 将ht[0]包含的四个键值对都rehash到ht[1]， 如图4-10所示。

3) 释放ht[0]， 并将ht[1]设置为ht[0]， 然后为ht[1]分配一个空白哈希表， 如图4-11所示。
至此， 对哈希表的扩展操作执行完毕， 程序成功将哈希表的大小从原来的4改为了现在的8。

哈希表的扩展与收缩

当以下条件中的任意一个被满足时， 程序会自动开始对哈希表执行扩展操作：

1) 服务器目前没有在执行BGSAVE命令或者BGREWRITEAOF命令， 并且哈希表的负载
因子大于等于1。

2) 服务器目前正在执行BGSAVE命令或者BGREWRITEAOF命令， 并且哈希表的负载因子大于等于5。其中哈希表的负载因子可以通过公式：

#负载因子=哈希表已保存节点数量/哈希表大小

load_factor = ht[0].used / ht[0].size计算得出。
例如， 对于一个大小为4， 包含4个键值对的哈希表来说， 这个哈希表的负载因子为：load_factor = 4 / 4 = 1

又例如， 对于一个大小为512， 包含256个键值对的哈希表来说， 这个哈希表的负载因子为：load_factor = 256 / 512 = 0.5根据BGSAVE命令或BGREWRITEAOF命令是否正在执行， 服务器执行扩展操作所需的负载因子并不相同， 这是因为在执行BGSAVE命令或BGREWRITEAOF命令的过程中， Redis需要创建当前服务器进程的子进程， 而大多数操作系统都采用写时复制(copy-on-write) 技术来优化子进程的使用效率， 所以在子进程存在期间， 服务器会提高执行扩展操作所需的负载因子， 从而尽可能地避免在子进程存在期间进行哈希表扩展操作， 这可以避免不必要的内存写入操作， 最大限度地节约内存。另一方面， 当哈希表的负载因子小于0.1时， 程序自动开始对哈希表执行收缩操作。

渐进式rehash

扩展或收缩哈希表需要将ht[0]里面的所有键值对rehash到ht[1]里面， 但
是， 这个rehash动作并不是一次性、 集中式地完成的， 而是分多次、 渐进式地完成的。这样做的原因在于， 如果ht[0]里只保存着四个键值对， 那么服务器可以在瞬间就将这些键值对全部rehash到ht[1]；但是， 如果哈希表里保存的键值对数量不是四个， 而是四百万、四千万甚至四亿个键值对， 那么要一次性将这些键值对全部rehash到ht[1]的话， 庞大的计算量可能会导致服务器在一段时间内停止服务。因此， 为了避免rehash对服务器性能造成影响， 服务器不是一次性将ht[0]里面的所有键值对全部rehash到ht[1]， 而是分多次、 渐进式地将ht[0]里面的键值对慢慢地rehash到ht[1]。
以下是哈希表渐进式rehash的详细步骤：

1) 为ht[1]分配空间， 让字典同时持有ht[0]和ht[1]两个哈希表。

2) 在字典中维持一个索引计数器变量rehashidx， 并将它的值设置为0， 表示rehash工作正式开始。

3) 在rehash进行期间， 每次对字典执行添加、 删除、 查找或者更新操作时， 程序除了执行指定的操作以外， 还会顺带将ht[0]哈希表在rehashidx索引上的所有键值对rehash到ht[1]，当rehash工作完成之后， 程序将rehashidx属性的值增一。

4) 随着字典操作的不断执行， 最终在某个时间点上， ht[0]的所有键值对都会被rehash至ht[1]， 这时程序将rehashidx属性的值设为-1， 表示rehash操作已完成。渐进式rehash的好处在于它采取分而治之的方式， 将rehash键值对所需的计算工作均摊到对字典的每个添加、 删除、 查找和更新操作上， 从而避免了集中式rehash而带来的庞大计算量。图4-12至图4-17展示了一次完整的渐进式rehash过程， 注意观察在整个rehash过程中， 字典的rehashidx属性是如何变化的。

渐进式rehash执行期间的哈希表操作因为在进行渐进式rehash的过程中， 字典会同时使用ht[0]和ht[1]两个哈希表， 所以在渐进式rehash进行期间， 字典的删除(delete) 、 查找(find) 、 更新(update) 等操作会在两个哈希表上进行。例如， 要在字典里面查找一个键的话， 程序会先在ht[0]里面进行查找， 如果没找到的话， 就会继续到ht[1]里面进行查找， 诸如此类。另外， 在渐进式rehash执行期间， 新添加到字典的键值对一律会被保存到ht[1]里面， 而ht[0]则不再进行任何添加操作， 这一措施保证了ht[0]包含的键值对数量会只减不增， 并随着rehash操作的执行而最终变成空表。

重点总结

字典被广泛用于实现Redis的各种功能， 其中包括数据库和哈希键。

·Redis中的字典使用哈希表作为底层实现， 每个字典带有两个哈希表， 一个平时使用，另一个仅在进行rehash时使用。

·当字典被用作数据库的底层实现， 或者哈希键的底层实现时， Redis使用MurmurHash2算法来计算键的哈希值。·哈希表使用链地址法来解决键冲突， 被分配到同一个索引上的多个键值对会连接成一个单向链表。

·在对哈希表进行扩展或者收缩操作时， 程序需要将现有哈希表包含的所有键值对rehash到新哈希表里面， 并且这个rehash过程并不是一次性地完成的， 而是渐进式地完成的。

四、跳跃表

说明：

跳跃表(skiplist) 是一种有序数据结构， 它通过在每个节点中维持多个指向其他节点的指针， 从而达到快速访问节点的目的。跳跃表支持平均O(logN) 、 最坏O(N) 复杂度的节点查找， 还可以通过顺序性操作来批量处理节点。在大部分情况下， 跳跃表的效率可以和平衡树相媲美， 并且因为跳跃表的实现比平衡树要来得更为简单， 所以有不少程序都使用跳跃表来代替平衡树。Redis使用跳跃表作为有序集合键的底层实现之一， 如果一个有序集合包含的元素数量比较多， 又或者有序集合中元素的成员(member) 是比较长的字符串时， Redis就会使用跳跃表来作为有序集合键的底层实现。

跳跃表的节点

 typedef struct zskiplistNode { //层 struct zskiplistLevel { //前进指针 struct zskiplistNode *forward; //跨度 unsigned int span; } level[]; //后退指针struct zskiplistNode *backward;//分值double score;//成员对象robj *obj;} zskiplistNode;

跳跃表代码定义

 typedef struct zskiplist { //表头节点和表尾节点 structz skiplistNode *header, *tail; //表中节点的数量 unsigned long length; //表中层数最大的节点的层数int level;} zskiplist;

header和tail指针分别指向跳跃表的表头和表尾节点， 通过这两个指针， 程序定位表头节点和表尾节点的复杂度为O(1) 。通过使用length属性来记录节点的数量， 程序可以在O(1) 复杂度内返回跳跃表的长度。level属性则用于在O(1) 复杂度内获取跳跃表中层高最大的那个节点的层数量， 注意表头节点的层高并不计算在内。

重点总结

·跳跃表是有序集合的底层实现之一。

·Redis的跳跃表实现由zskiplist和zskiplistNode两个结构组成， 其中zskiplist用于保存跳跃表信息(比如表头节点、 表尾节点、 长度) ， 而zskiplistNode则用于表示跳跃表节点。

·每个跳跃表节点的层高都是1至32之间的随机数。·在同一个跳跃表中， 多个节点可以包含相同的分值， 但每个节点的成员对象必须是唯一的。

·跳跃表中的节点按照分值大小进行排序， 当分值相同时， 节点按照成员对象的大小进行排序。

五、整数集合

说明：

整数集合(intset) 是集合键的底层实现之一， 当一个集合只包含整数值元素， 并且这个集合的元素数量不多时(小于512)， Redis就会使用整数集合作为集合键的底层实现。

typedef struct intset {//编码方式uint32_t encoding;//集合包含的元素数量uint32_t length;//保存元素的数组int8_t contents[];

} intset;

升级

每当我们要将一个新元素添加到整数集合里面， 并且新元素的类型比整数集合现有所有元素的类型都要长时， 整数集合需要先进行升级(upgrade) ， 然后才能将新元素添加到整数集合里面。
升级整数集合并添加新元素共分为三步进行：

1) 根据新元素的类型， 扩展整数集合底层数组的空间大小， 并为新元素分配空间。

2) 将底层数组现有的所有元素都转换成与新元素相同的类型， 并将类型转换后的元素
放置到正确的位上， 而且在放置元素的过程中， 需要继续维持底层数组的有序性质不变。

3) 将新元素添加到底层数组里面。

升级的好处

整数集合的升级策略有两个好处， 一个是提升整数集合的灵活性， 另一个是尽可能地节约内存。

重点总结

·整数集合是集合键的底层实现之一。·整数集合的底层实现为数组， 这个数组以有序、 无重复的方式保存集合元素， 在有需要时， 程序会根据新添加元素的类型， 改变这个数组的类型。

·升级操作为整数集合带来了操作上的灵活性， 并且尽可能地节约了内存。

·整数集合只支持升级操作， 不支持降级操作。

六、压缩列表

说明：

压缩列表(ziplist) 是列表键和哈希键的底层实现之一。当一个列表键只包含少量列表项， 并且每个列表项要么就是小整数值， 要么就是长度比较短的字符串， 那么Redis就会使用压缩列表来做列表键的底层实现。

压缩列表构成

压缩列表是Redis为了节约内存而开发的， 是由一系列特殊编码的连续内存块组成的顺序型(sequential) 数据结构。一个压缩列表可以包含任意多个节点(entry) ， 每个节点可以保存一个字节数组或者一个整数值。图7-1展示了压缩列表的各个组成部分， 表7-1则记录了各个组成部分的类型、 长度以及用途。

压缩列表节点的构成

每个压缩列表节点可以保存一个字节数组或者一个整数值， 其中， 字节数组可以是以下
三种长度的其中一种：

·长度小于等于63(2 6–1) 字节的字节数组；

·长度小于等于16383(2 14–1) 字节的字节数组；

·长度小于等于4294967295(2 32–1) 字节的字节数组；
而整数值则可以是以下六种长度的其中一种：·4位长， 介于0至12之间的无符号整数；

·1字节长的有符号整数；

·3字节长的有符号整数；

·int16_t类型整数；

·int32_t类型整数；

·int64_t类型整数。
每个压缩列表节点都由previous_entry_length、 encoding、 content三个部分组成， 如图7-4所示

previous_entry_length

节点的previous_entry _length属性以字节为单位， 记录了压缩列表中前一个节点的长度。previous_entry_length属性的长度可以是1字节或者5字节：

·如果前一节点的长度小于254字节， 那么previous_entry_length属性的长度为1字节：前一节点的长度就保存在这一个字节里面。

·如果前一节点的长度大于等于254字节， 那么previous_entry_length属性的长度为5字节：其中属性的第一字节会被设置为0xFE(十进制值254) ， 而之后的四个字节则用于保存前一节点的长度。
图7-5展示了一个包含一字节长previous_entry_length属性的压缩列表节点， 属性的值为0x05， 表示前一节点的长度为5字节

重点总结

·压缩列表是一种为节约内存而开发的顺序型数据结构。·压缩列表被用作列表键和哈希键的底层实现之一。

·压缩列表可以包含多个节点， 每个节点可以保存一个字节数组或者整数值。

·添加新节点到压缩列表， 或者从压缩列表中删除节点， 可能会引发连锁更新操作， 但这种操作出现的几率并不高。

七、对象

说明

Redis用到的所有主要数据结构， 比如简单动态字符串(SDS) 、 双端链表、 字典、 压缩列表、 整数集合等等。Redis并没有直接使用这些数据结构来实现键值对数据库， 而是基于这些数据结构创建了一个对象系统， 这个系统包含字符串对象、 列表对象、 哈希对象、 集合对象和有序集合对象这五种类型的对象， 每种对象都用到了至少一种我们前面所介绍的数据结构。通过这五种不同类型的对象， Redis可以在执行命令之前， 根据对象的类型来判断一个对象是否可以执行给定的命令。使用对象的另一个好处是， 我们可以针对不同的使用场景， 为对象设置多种不同的数据结构实现， 从而优化对象在不同场景下的使用效率。除此之外， Redis的对象系统还实现了基于引用计数技术的内存回收机制， 当程序不再使用某个对象的时候， 这个对象所占用的内存就会被自动释放；另外， Redis还通过引用计数技术实现了对象共享机制， 这一机制可以在适当的条件下， 通过让多个数据库键共享同一个对象来节约内存。最后， Redis的对象带有访问时间记录信息， 该信息可以用于计算数据库键的空转时长，在服务器启用了maxmemory功能的情况下， 空转时长较大的那些键可能会优先被服务器删除

对象代码定义

 typedef struct redisObject { //类型 unsigned type:4; //编码 unsigned encoding:4; //指向底层实现数据结构的指针void *ptr;// ...} robj;

对象类型

编码和底层实现

各对象类型编码转换条件和时机

字符串对象

int编码的字符串对象和embstr编码的字符串对象在条件满足的情况下， 会被转换为raw编码的字符串对象。对于int编码的字符串对象来说， 如果我们向对象执行了一些命令， 使得这个对象保存的不再是整数值， 而是一个字符串值， 那么字符串对象的编码将从int变为raw。另外， 因为Redis没有为embstr编码的字符串对象编写任何相应的修改程序(只有int编码的字符串对象和raw编码的字符串对象有这些程序) ， 所以embstr编码的字符串对象实际上是只读的。当我们对embstr编码的字符串对象执行任何修改命令时， 程序会先将对象的编码从embstr转换成raw， 然后再执行修改命令。因为这个原因， embstr编码的字符串对象在执行修改命令之后， 总会变成一个raw编码的字符串对象

列表对象

当列表对象可以同时满足以下两个条件时， 列表对象使用ziplist编码：·列表对象保存的所有字符串元素的长度都小于64字节；·列表对象保存的元素数量小于512个；不能满足这两个条件的列表对象需要使用linkedlist编码。注意

以上两个条件的上限值是可以修改的， 具体请看配置文件中关于list-max-ziplist-value选项和list-max-ziplist-entries选项的说明。对于使用ziplist编码的列表对象来说， 当使用ziplist编码所需的两个条件的任意一个不能被满足时， 对象的编码转换操作就会被执行， 原本保存在压缩列表里的所有列表元素都会被转移并保存到双端链表里面， 对象的编码也会从ziplist变为linkedlist。

哈希对象

当哈希对象可以同时满足以下两个条件时， 哈希对象使用ziplist编码：·哈希对象保存的所有键值对的键和值的字符串长度都小于64字节；·哈希对象保存的键值对数量小于512个；不能满足这两个条件的哈希对象需要使用hashtable编码。注意这两个条件的上限值是可以修改的， 具体请看配置文件中关于hash-max-ziplist-value选项和hash-max-ziplist-entries选项的说明。对于使用ziplist编码的列表对象来说， 当使用ziplist编码所需的两个条件的任意一个不能被满足时， 对象的编码转换操作就会被执行， 原本保存在压缩列表里的所有键值对都会被转移并保存到字典里面， 对象的编码也会从ziplist变为hashtable。

集合对象

当集合对象可以同时满足以下两个条件时， 对象使用intset编码：·集合对象保存的所有元素都是整数值；·集合对象保存的元素数量不超过512个。不能满足这两个条件的集合对象需要使用hashtable编码。注意第二个条件的上限值是可以修改的， 具体请看配置文件中关于set-max-intset-entries选项的说明。对于使用intset编码的集合对象来说， 当使用intset编码所需的两个条件的任意一个不能被满足时， 就会执行对象的编码转换操作， 原本保存在整数集合中的所有元素都会被转移并保存到字典里面， 并且对象的编码也会从intset变为hashtable。

有序集合对象

当有序集合对象可以同时满足以下两个条件时， 对象使用ziplist编码：·有序集合保存的元素数量小于128个；·有序集合保存的所有元素成员的长度都小于64字节；不能满足以上两个条件的有序集合对象将使用skiplist编码。注意以上两个条件的上限值是可以修改的， 具体请看配置文件中关于zset-max-ziplist-entries选项和zset-max-ziplist-value选项的说明。对于使用ziplist编码的有序集合对象来说， 当使用ziplist编码所需的两个条件中的任意一个不能被满足时， 就会执行对象的编码转换操作， 原本保存在压缩列表里的所有集合元素都会被转移并保存到zset结构里面， 对象的编码也会从ziplist变为skiplist。

内存回收

因为C语言并不具备自动内存回收功能， 所以Redis在自己的对象系统中构建了一个引用计数(reference counting) 技术实现的内存回收机制， 通过这一机制， 程序可以通过跟踪对象的引用计数信息， 在适当的时候自动释放对象并进行内存回收。每个对象的引用计数信息由redisObject结构的refcount属性记录：

typedef struct redisObject {// ...//引用计数int refcount;// ...} robj;

对象的引用计数信息会随着对象的使用状态而不断变化：

·在创建一个新对象时， 引用计数的值会被初始化为1；

·当对象被一个新程序使用时， 它的引用计数值会被增一；

·当对象不再被一个程序使用时， 它的引用计数值会被减一；

·当对象的引用计数值变为0时， 对象所占用的内存会被释放。
表8-12列出了修改对象引用计数的API， 这些API分别用于增加、 减少、 重置对象的引用计数。

对象共享

目前来说， Redis会在初始化服务器时， 创建一万个字符串对象， 这些对象包含了从0到9999的所有整数值， 当服务器需要用到值为0到9999的字符串对象时， 服务器就会使用这些共享对象， 而不是新创建对象。另外， 这些共享对象不单单只有字符串键可以使用， 那些在数据结构中嵌套了字符串对象的对象(linkedlist编码的列表对象、 hashtable编码的哈希对象、hashtable编码的集合对象，以及zset编码的有序集合对象) 都可以使用这些共享对象。

对象的空转时长

除了前面介绍过的ty pe、 encoding、 ptr和refcount四个属性之外， redisObject结构包含的最后一个属性为lru属性， 该属性记录了对象最后一次被命令程序访问的时间：

typedef struct redisObject {// ...unsigned lru:22;// ...} robj;

OBJECT IDLETIME命令可以打印出给定键的空转时长， 这一空转时长就是通过将当前时间减去键的值对象的lru时间计算得出的OBJECT IDLETIME命令的实现是特殊的， 这个命令在访问键的值对象时， 不会修改值对象的lru属性。除了可以被OBJECT IDLETIME命令打印出来之外， 键的空转时长还有另外一项作用：如果服务器打开了maxmemory选项， 并且服务器用于回收内存的算法为volatile-lru或者allkeys-lru， 那么当服务器占用的内存数超过了maxmemory选项所设置的上限值时， 空转时长较高的那部分键会优先被服务器释放， 从而回收内存。配置文件的maxmemory选项和maxmemory-policy选项的说明介绍了关于这方面的更多信息。

重点总结

·Redis数据库中的每个键值对的键和值都是一个对象。

·Redis共有字符串、 列表、 哈希、 集合、 有序集合五种类型的对象， 每种类型的对象至少都有两种或以上的编码方式， 不同的编码可以在不同的使用场景上优化对象的使用效率。

·服务器在执行某些命令之前， 会先检查给定键的类型能否执行指定的命令， 而检查一个键的类型就是检查键的值对象的类型。

·Redis的对象系统带有引用计数实现的内存回收机制， 当一个对象不再被使用时， 该对象所占用的内存就会被自动释放。

·Redis会共享值为0到9999的字符串对象。·对象会记录自己的最后一次被访问的时间， 这个时间可以用于计算对象的空转时间。

如果您已阅读到此，感谢您对公众号里文章的认可，请动动你可爱的小指头关注此公众号，每天都有硬核技术文章推送，就算离开也能找到回家的路