对象的类型与编码
Redis 使用对象来表示数据库中的键和值， 每次当我们在 Redis 的数据库中新创建一个键值对时， 我们至少会创建两个对象， 一个对象用作键值对的键（键对象）， 另一个对象用作键值对的值（值对象）。
typedef struct redisObject {
// 类型
unsigned type:4;
// 编码
unsigned encoding:4;
// 指向底层实现数据结构的指针
void *ptr;
// 引用计数器用于垃圾回收
int refount;
//空转时长，当前时间-上次活跃的时间
unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */
} robj;
字符串对象
字符串对象的编码可以是 int 、 raw 或者 embstr 。如果一个字符串对象保存的是整数值， 并且这个整数值可以用 long 类型来表示， 那么字符串对象会将整数值保存在字符串对象结构的 ptr 属性里面（将 void* 转换成 long ）， 并将字符串对象的编码设置为 int 。 如果字符串对象保存的是一个字符串值， 并且这个字符串值的长度小于等于 39 字节， 那么字符串对象将使用 embstr 编码的方式来保存这个字符串值。
embstr 编码是专门用于保存短字符串的一种优化编码方式， 这种编码和 raw 编码一样， 都使用 redisObject 结构和 sdshdr 结构来表示字符串对象， 但 raw 编码会调用两次内存分配函数来分别创建 redisObject 结构和 sdshdr 结构， 而 embstr 编码则通过调用一次内存分配函数来分配一块连续的空间， 空间中依次包含 redisObject 和 sdshdr 两个结构， 如图 8-3 所示。
embstr 编码将创建字符串对象所需的内存分配次数从 raw 编码的两次降低为一次。 释放 embstr 编码的字符串对象只需要调用一次内存释放函数， 而释放 raw 编码的字符串对象需要调用两次内存释放函数。 因为 embstr 编码的字符串对象的所有数据都保存在一块连续的内存里面， 所以这种编码的字符串对象比起 raw 编码的字符串对象能够更好地利用缓存带来的优势。
编码转换条件
int 编码的字符串对象和 embstr 编码的字符串对象在条件满足的情况下， 会被转换为 raw 编码的字符串对象。
对于 int 编码的字符串对象来说， 如果我们向对象执行了一些命令， 使得这个对象保存的不再是整数值， 而是一个字符串值， 那么字符串对象的编码将从 int 变为 raw 。
在下面的示例中， 我们通过 APPEND 命令， 向一个保存整数值的字符串对象追加了一个字符串值， 因为追加操作只能对字符串值执行， 所以程序会先将之前保存的整数值 10086 转换为字符串值 "10086" ， 然后再执行追加操作， 操作的执行结果就是一个 raw 编码的、保存了字符串值的字符串对象：
列表对象
列表对象的编码可以是 ziplist 或者 linkedlist 。
ziplist 编码的列表对象使用压缩列表作为底层实现， 每个压缩列表节点（entry）保存了一个列表元素。 举个例子， 如果我们执行以下 RPUSH 命令， 那么服务器将创建一个列表对象作为 numbers 键的值：
举个例子， 如果前面所说的 numbers 键创建的列表对象使用的不是 ziplist 编码， 而是 linkedlist 编码， 那么 numbers 键的值对象将是图 8-6 所示的样子。
编码转换条件
当列表对象可以同时满足以下两个条件时， 列表对象使用 ziplist 编码：
列表对象保存的所有字符串元素的长度都小于 64 字节； 列表对象保存的元素数量小于 512 个； 不能满足这两个条件的列表对象需要使用 linkedlist 编码。
以上两个条件的上限值是可以修改的， 具体请看配置文件中关于 list-max-ziplist-value 选项和 list-max-ziplist-entries 选项的说明。
哈希对象
哈希对象的编码可以是 ziplist 或者 hashtable 。
ziplist 编码的哈希对象使用压缩列表作为底层实现， 每当有新的键值对要加入到哈希对象时， 程序会先将保存了键的压缩列表节点推入到压缩列表表尾， 然后再将保存了值的压缩列表节点推入到压缩列表表尾， 因此：
保存了同一键值对的两个节点总是紧挨在一起， 保存键的节点在前， 保存值的节点在后； 先添加到哈希对象中的键值对会被放在压缩列表的表头方向， 而后来添加到哈希对象中的键值对会被放在压缩列表的表尾方向。 举个例子， 如果我们执行以下 HSET 命令， 那么服务器将创建一个列表对象作为 profile 键的值：
字典的每个键都是一个字符串对象， 对象中保存了键值对的键； 字典的每个值都是一个字符串对象， 对象中保存了键值对的值。 举个例子， 如果前面 profile 键创建的不是 ziplist 编码的哈希对象， 而是 hashtable 编码的哈希对象， 那么这个哈希对象应该会是图 8-11 所示的样子。
编码转换条件
当哈希对象可以同时满足以下两个条件时， 哈希对象使用 ziplist 编码：
哈希对象保存的所有键值对的键和值的字符串长度都小于 64 字节； 哈希对象保存的键值对数量小于 512 个； 不能满足这两个条件的哈希对象需要使用 hashtable 编码。
这两个条件的上限值是可以修改的， 具体请看配置文件中关于 hash-max-ziplist-value 选项和 hash-max-ziplist-entries 选项的说明。
集合对象
集合对象的编码可以是 intset 或者 hashtable 。
intset 编码的集合对象使用整数集合作为底层实现， 集合对象包含的所有元素都被保存在整数集合里面。
举个例子， 以下代码将创建一个如图 8-12 所示的 intset 编码集合对象：
举个例子， 以下代码将创建一个如图 8-13 所示的 hashtable 编码集合对象：
编码转换
当集合对象可以同时满足以下两个条件时， 对象使用 intset 编码：
集合对象保存的所有元素都是整数值； 集合对象保存的元素数量不超过 512 个； 不能满足这两个条件的集合对象需要使用 hashtable 编码。
第二个条件的上限值是可以修改的， 具体请看配置文件中关于 set-max-intset-entries 选项的说明。
有序集合对象
有序集合的编码可以是 ziplist 或者 skiplist 。
ziplist 编码的有序集合对象使用压缩列表作为底层实现， 每个集合元素使用两个紧挨在一起的压缩列表节点来保存， 第一个节点保存元素的成员（member）， 而第二个元素则保存元素的分值（score）。
压缩列表内的集合元素按分值从小到大进行排序， 分值较小的元素被放置在靠近表头的方向， 而分值较大的元素则被放置在靠近表尾的方向。
举个例子， 如果我们执行以下 ZADD 命令， 那么服务器将创建一个有序集合对象作为 price 键的值：
typedef struct zset {
zskiplist *zsl;
dict *dict;
} zset;
编码转换条件
当有序集合对象可以同时满足以下两个条件时， 对象使用 ziplist 编码：
有序集合保存的元素数量小于 128 个； 有序集合保存的所有元素成员的长度都小于 64 字节； 不能满足以上两个条件的有序集合对象将使用 skiplist 编码。
以上两个条件的上限值是可以修改的， 具体请看配置文件中关于 zset-max-ziplist-entries 选项和 zset-max-ziplist-value 选项的说明。
类型检查
从上面发生类型错误的代码示例可以看出， 为了确保只有指定类型的键可以执行某些特定的命令， 在执行一个类型特定的命令之前， Redis 会先检查输入键的类型是否正确， 然后再决定是否执行给定的命令。
类型特定命令所进行的类型检查是通过 redisObject 结构的 type 属性来实现的：
在执行一个类型特定命令之前， 服务器会先检查输入数据库键的值对象是否为执行命令所需的类型， 如果是的话， 服务器就对键执行指定的命令； 否则， 服务器将拒绝执行命令， 并向客户端返回一个类型错误。 举个例子， 对于 LLEN 命令来说：
在执行 LLEN 命令之前， 服务器会先检查输入数据库键的值对象是否为列表类型， 也即是， 检查值对象 redisObject 结构 type 属性的值是否为 REDIS_LIST ， 如果是的话， 服务器就对键执行 LLEN 命令； 否则的话， 服务器就拒绝执行命令并向客户端返回一个类型错误； 图 8-18 展示了这一类型检查过程。
多态命令的实现
Redis 除了会根据值对象的类型来判断键是否能够执行指定命令之外， 还会根据值对象的编码方式， 选择正确的命令实现代码来执行命令。
举个例子， 在前面介绍列表对象的编码时我们说过， 列表对象有 ziplist 和 linkedlist 两种编码可用， 其中前者使用压缩列表 API 来实现列表命令， 而后者则使用双端链表 API 来实现列表命令。
现在， 考虑这样一个情况， 如果我们对一个键执行 LLEN 命令， 那么服务器除了要确保执行命令的是列表键之外， 还需要根据键的值对象所使用的编码来选择正确的 LLEN 命令实现：
如果列表对象的编码为 ziplist ， 那么说明列表对象的实现为压缩列表， 程序将使用 ziplistLen 函数来返回列表的长度； 如果列表对象的编码为 linkedlist ， 那么说明列表对象的实现为双端链表， 程序将使用 listLength 函数来返回双端链表的长度； 借用面向对象方面的术语来说， 我们可以认为 LLEN 命令是多态（polymorphism）的： 只要执行 LLEN 命令的是列表键， 那么无论值对象使用的是 ziplist 编码还是 linkedlist 编码， 命令都可以正常执行。
图 8-19 展示了 LLEN 命令从类型检查到根据编码选择实现函数的整个执行过程， 其他类型特定命令的执行过程也是类似的。
内存回收
因为 C 语言并不具备自动的内存回收功能， 所以 Redis 在自己的对象系统中构建了一个引用计数（reference counting）技术实现的内存回收机制， 通过这一机制， 程序可以通过跟踪对象的引用计数信息， 在适当的时候自动释放对象并进行内存回收。
每个对象的引用计数信息由 redisObject 结构的 refcount 属性记录：
对象的引用计数信息会随着对象的使用状态而不断变化：
在创建一个新对象时， 引用计数的值会被初始化为 1 ； 当对象被一个新程序使用时， 它的引用计数值会被增一； 当对象不再被一个程序使用时， 它的引用计数值会被减一； 当对象的引用计数值变为 0 时， 对象所占用的内存会被释放。
对象共享
目前来说， Redis 会在初始化服务器时， 创建一万个字符串对象， 这些对象包含了从 0 到 9999 的所有整数值， 当服务器需要用到值为 0 到 9999 的字符串对象时， 服务器就会使用这些共享对象， 而不是新创建对象。
创建共享字符串对象的数量可以通过修改 redis.h/REDIS_SHARED_INTEGERS 常量来修改。
为什么 Redis 不共享包含字符串的对象？
当服务器考虑将一个共享对象设置为键的值对象时， 程序需要先检查给定的共享对象和键想创建的目标对象是否完全相同， 只有在共享对象和目标对象完全相同的情况下， 程序才会将共享对象用作键的值对象， 而一个共享对象保存的值越复杂， 验证共享对象和目标对象是否相同所需的复杂度就会越高， 消耗的 CPU 时间也会越多：
如果共享对象是保存整数值的字符串对象， 那么验证操作的复杂度为 O(1) ；
如果共享对象是保存字符串值的字符串对象， 那么验证操作的复杂度为 O(N) ；
如果共享对象是包含了多个值（或者对象的）对象， 比如列表对象或者哈希对象， 那么验证操作的复杂度将会是 O(N^2) 。
因此， 尽管共享更复杂的对象可以节约更多的内存， 但受到 CPU 时间的限制， Redis 只对包含整数值的字符串对象进行共享。
对象的空转时长
除了前面介绍过的 type 、 encoding 、 ptr 和 refcount 四个属性之外， redisObject 结构包含的最后一个属性为 lru 属性， 该属性记录了对象最后一次被命令程序访问的时间：
重点回顾
- Redis 数据库中的每个键值对的键和值都是一个对象。
- Redis 共有字符串、列表、哈希、集合、有序集合五种类型的对象， 每种类型的对象至少都有两种或以上的编码方式， 不同的编码可以在不同的使用场景上优化对象的使用效率。
- 服务器在执行某些命令之前， 会先检查给定键的类型能否执行指定的命令， 而检查一个键的类型就是检查键的值对象的类型。
- Redis 的对象系统带有引用计数实现的内存回收机制， 当一个对象不再被使用时， 该对象所占用的内存就会被自动释放。
- Redis 会共享值为 0 到 9999 的字符串对象。
- 对象会记录自己的最后一次被访问的时间， 这个时间可以用于计算对象的空转时间。
