Redis学习笔记

最新推荐文章于 2024-09-20 18:57:31 发布
最新推荐文章于 2024-09-20 18:57:31 发布
阅读量240 收藏
点赞数
分类专栏： 数据库 文章标签： redis
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43971373/article/details/119681918
版权

一、Redis简介

redis以内存作为数据存储介质，读写数据的效率极高。
redis跟memcache不同的是，储存在redis中的数据是持久化的，断电或重启，数据也不会丢失。
redis的存储分为内存存储、磁盘存储和log文件。
redis可以从磁盘重新将数据加载到内存中，也可以通过配置文件对其进行配置，因此，redis才能实现持久化。
redis支持主从模式，可以配置集群，更利于支撑大型的项目。

众多语言都支持redis，因为redis交换数据快，在服务器中常用来存储一些需要频繁调取的数据，节省内存开销，也极大的提升了速度。将一些热点数据存储到redis中，要用的时候，直接从内存取，极大的提高了速度和节约了服务器的开销。
会话缓存（最常用）、消息队列（支付）、活动排行榜或计数、发布，订阅消息（消息通知）、商品列表评论列表。

Redis包含字符串String、哈希表Hash、列表List、集合Set、有序集合ZSet五种数据类型。

二、Redis数据结构

2.1. 简单动态字符串

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

在 Redis 里面， C 字符串只会作为字符串字面量（string literal）， 用在一些无须对字符串值进行修改的地方， 比如打印日志。

当 Redis 需要的不仅仅是一个字符串字面量， 而是一个可以被修改的字符串值时， Redis 就会使用 SDS 来表示字符串值： 比如在 Redis 的数据库里面， 包含字符串值的键值对在底层都是由 SDS 实现的。

除了用来保存数据库中的字符串值之外， SDS 还被用作缓冲区（buffer）： AOF 模块中的 AOF 缓冲区， 以及客户端状态中的输入缓冲区， 都是由 SDS 实现的， 在之后介绍 AOF 持久化和客户端状态的时候， 我们会看到 SDS 在这两个模块中的应用。

2.1.1 SDS定义
struct sdshdr {

    // 记录 buf 数组中已使用字节的数量
    // 等于 SDS 所保存字符串的长度
    int len;

    // 记录 buf 数组中未使用字节的数量
    int free;

    // 字节数组，用于保存字符串
    char buf[];

};

free 属性的值为 0 ， 表示这个 SDS 没有分配任何未使用空间。
len 属性的值为 5 ， 表示这个 SDS 保存了一个五字节长的字符串。
buf 属性是一个 char 类型的数组， 数组的前五个字节分别保存了 ‘R’ 、 ‘e’ 、 ‘d’ 、 ‘i’ 、 ‘s’ 五个字符， 而最后一个字节则保存了空字符 ‘\0’ 。

图 2-2 展示了另一个 SDS 示例:
这个 SDS 和之前展示的 SDS 一样， 都保存了字符串值 “Redis” 。
这个 SDS 和之前展示的 SDS 的区别在于， 这个 SDS 为 buf 数组分配了五字节未使用空间， 所以它的 free 属性的值为 5 （图中使用五个空格来表示五字节的未使用空间）。

2.1.2 SDS与C字符串的区别

  1. 常数复杂度获取字符串长度
    根据传统， C 语言使用长度为 N+1 的字符数组来表示长度为 N 的字符串， 并且字符数组的最后一个元素总是空字符 ‘\0’ 。
    C字符串获取字符串长度需要遍历找到第一个 ‘\0’ ，时间复杂度是O(N )，因为字符串键在底层使用 SDS 来实现，SDS保存了len属性，所以即使我们对一个非常长的字符串键反复执行 STRLEN 命令， 也不会对系统性能造成任何影响， 因为 STRLEN 命令的复杂度仅为 O(1) 。

  2. 杜绝缓冲区溢出
    除了获取字符串长度的复杂度高之外， C 字符串不记录自身长度带来的另一个问题是容易造成缓冲区溢出（buffer overflow）。strcat函数是不做缓冲区检查的，需要程序员使用前自己判断长度。
    与 C 字符串不同， SDS 的空间分配策略完全杜绝了发生缓冲区溢出的可能性： 当 SDS API 需要对 SDS 进行修改时， API 会先检查 SDS 的空间是否满足修改所需的要求， 如果不满足的话， API 会自动将 SDS 的空间扩展至执行修改所需的大小， 然后才执行实际的修改操作， 所以使用 SDS 既不需要手动修改 SDS 的空间大小， 也不会出现前面所说的缓冲区溢出问题。

  3. 减少修改字符串时带来的内存重分配次数
    正如前两个小节所说， 因为 C 字符串并不记录自身的长度， 所以对于一个包含了 N 个字符的 C 字符串来说， 这个 C 字符串的底层实现总是一个 N+1 个字符长的数组（额外的一个字符空间用于保存空字符）。
    因为 C 字符串的长度和底层数组的长度之间存在着这种关联性， 所以每次增长或者缩短一个 C 字符串， 程序都总要对保存这个 C 字符串的数组进行一次内存重分配操作：
    如果程序执行的是增长字符串的操作， 比如拼接操作（append）， 那么在执行这个操作之前， 程序需要先通过内存重分配来扩展底层数组的空间大小 —— 如果忘了这一步就会产生缓冲区溢出。
    如果程序执行的是缩短字符串的操作， 比如截断操作（trim）， 那么在执行这个操作之后， 程序需要通过内存重分配来释放字符串不再使用的那部分空间 —— 如果忘了这一步就会产生内存泄漏。
    因为内存重分配涉及复杂的算法， 并且可能需要执行系统调用， 所以它通常是一个比较耗时的操作：
    在一般程序中， 如果修改字符串长度的情况不太常出现， 那么每次修改都执行一次内存重分配是可以接受的。
    但是 Redis 作为数据库， 经常被用于速度要求严苛、数据被频繁修改的场合， 如果每次修改字符串的长度都需要执行一次内存重分配的话， 那么光是执行内存重分配的时间就会占去修改字符串所用时间的一大部分， 如果这种修改频繁地发生的话， 可能还会对性能造成影响。
    为了避免 C 字符串的这种缺陷， SDS 通过未使用空间解除了字符串长度和底层数组长度之间的关联： 在 SDS 中， buf 数组的长度不一定就是字符数量加一， 数组里面可以包含未使用的字节， 而这些字节的数量就由 SDS 的 free 属性记录。
    通过未使用空间，SDS 实现了空间预分配和惰性空间释放两种优化策略。

    1. 空间预分配
      空间预分配用于优化 SDS 的字符串增长操作： 当 SDS 的 API 对一个 SDS 进行修改， 并且需要对 SDS 进行空间扩展的时候， 程序不仅会为 SDS 分配修改所必须要的空间， 还会为 SDS 分配额外的未使用空间。
      如果对 SDS 进行修改之后， SDS 的长度（也即是 len 属性的值）将小于 1 MB ， 那么程序分配和 len 属性同样大小的未使用空间， 这时 SDS len 属性的值将和 free 属性的值相同。 举个例子， 如果进行修改之后， SDS 的 len 将变成 13 字节， 那么程序也会分配 13 字节的未使用空间， SDS 的 buf 数组的实际长度将变成 13 + 13 + 1 = 27 字节（额外的一字节用于保存空字符）。
      如果对 SDS 进行修改之后， SDS 的长度将大于等于 1 MB ， 那么程序会分配 1 MB 的未使用空间。 举个例子， 如果进行修改之后， SDS 的 len 将变成 30 MB ， 那么程序会分配 1 MB 的未使用空间， SDS 的 buf 数组的实际长度将为 30 MB + 1 MB + 1 byte 。

    2. 惰性空间释放
      惰性空间释放用于优化 SDS 的字符串缩短操作： 当 SDS 的 API 需要缩短 SDS 保存的字符串时， 程序并不立即使用内存重分配来回收缩短后多出来的字节， 而是使用 free 属性将这些字节的数量记录起来， 并等待将来使用。

  4. 二进制安全
    C 字符串中的字符必须符合某种编码（比如 ASCII）， 并且除了字符串的末尾之外， 字符串里面不能包含空字符， 否则最先被程序读入的空字符将被误认为是字符串结尾 —— 这些限制使得 C 字符串只能保存文本数据， 而不能保存像图片、音频、视频、压缩文件这样的二进制数据。
    举个例子， 如果有一种使用空字符来分割多个单词的特殊数据格式， 如图 2-17 所示， 那么这种格式就不能使用 C 字符串来保存， 因为 C 字符串所用的函数只会识别出其中的"Redis"， 而忽略之后的"Cluster"。

    虽然数据库一般用于保存文本数据， 但使用数据库来保存二进制数据的场景也不少见， 因此， 为了确保 Redis 可以适用于各种不同的使用场景， SDS 的 API 都是二进制安全的（binary-safe）： 所有 SDS API 都会以处理二进制的方式来处理 SDS 存放在 buf 数组里的数据， 程序不会对其中的数据做任何限制、过滤、或者假设 —— 数据在写入时是什么样的， 它被读取时就是什么样。
    这也是我们将 SDS 的 buf 属性称为字节数组的原因 —— Redis 不是用这个数组来保存字符， 而是用它来保存一系列二进制数据。
    比如说， 使用 SDS 来保存之前提到的特殊数据格式就没有任何问题， 因为 SDS 使用 len 属性的值而不是空字符来判断字符串是否结束， 如图 2-18 所示。

    通过使用二进制安全的 SDS ， 而不是 C 字符串， 使得 Redis 不仅可以保存文本数据， 还可以保存任意格式的二进制数据。

2.1.3 SDS与C字符串对比
C 字符串SDS
获取字符串长度的复杂度为 O(N) 。获取字符串长度的复杂度为 O(1) 。
API 是不安全的，可能会造成缓冲区溢出。API 是安全的，不会造成缓冲区溢出。
修改字符串长度 N 次必然需要执行 N 次内存重分配。修改字符串长度 N 次最多需要执行 N 次内存重分配。
只能保存文本数据。可以保存文本或者二进制数据。
可以使用所有 <string.h> 库中的函数。可以使用一部分 <string.h> 库中的函数。

2.2 链表

2.2.1 链表的定义

链表提供了高效的节点重排能力， 以及顺序性的节点访问方式， 并且可以通过增删节点来灵活地调整链表的长度。

typedef struct listNode {

    // 前置节点
    struct listNode *prev;

    // 后置节点
    struct listNode *next;

    // 节点的值
    void *value;

} listNode;

多个 listNode 可以通过 prev 和 next 指针组成双端链表， 如图 3-1 所示。

虽然仅仅使用多个 listNode 结构就可以组成链表， 但使用 adlist.h/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 结构为链表提供了表头指针 head 、表尾指针 tail ， 以及链表长度计数器 len ， 而 dup 、 free 和 match 成员则是用于实现多态链表所需的类型特定函数：

dup 函数用于复制链表节点所保存的值；
free 函数用于释放链表节点所保存的值；
match 函数则用于对比链表节点所保存的值和另一个输入值是否相等。

2.2.2 链表的特性

双端： 链表节点带有 prev 和 next 指针， 获取某个节点的前置节点和后置节点的复杂度都是 O(1) 。
无环： 表头节点的 prev 指针和表尾节点的 next 指针都指向 NULL ， 对链表的访问以 NULL 为终点。
带表头指针和表尾指针： 通过 list 结构的 head 指针和 tail 指针， 程序获取链表的表头节点和表尾节点的复杂度为 O(1) 。
带链表长度计数器： 程序使用 list 结构的 len 属性来对 list 持有的链表节点进行计数， 程序获取链表中节点数量的复杂度为 O(1) 。
多态： 链表节点使用 void* 指针来保存节点值， 并且可以通过 list 结构的 dup 、 free 、 match 三个属性为节点值设置类型特定函数， 所以链表可以用于保存各种不同类型的值。

2.3 字典

2.3.1 字典的定义

字典， 又称符号表（symbol table）、关联数组（associative array）或者映射（map）， 是一种用于保存键值对（key-value pair）的抽象数据结构。

在字典中， 一个键（key）可以和一个值（value）进行关联（或者说将键映射为值）， 这些关联的键和值就被称为键值对。

字典中的每个键都是独一无二的， 程序可以在字典中根据键查找与之关联的值， 或者通过键来更新值， 又或者根据键来删除整个键值对， 等等。

字典经常作为一种数据结构内置在很多高级编程语言里面， 但 Redis 所使用的 C 语言并没有内置这种数据结构， 因此 Redis 构建了自己的字典实现。

字典在 Redis 中的应用相当广泛， 比如 Redis 的数据库就是使用字典来作为底层实现的， 对数据库的增、删、查、改操作也是构建在对字典的操作之上的。

举个例子， 当我们执行命令：

redis> SET msg "hello world"
OK

在数据库中创建一个键为 “msg” ， 值为 “hello world” 的键值对时， 这个键值对就是保存在代表数据库的字典里面的。

除了用来表示数据库之外， 字典还是哈希键的底层实现之一： 当一个哈希键包含的键值对比较多， 又或者键值对中的元素都是比较长的字符串时， Redis 就会使用字典作为哈希键的底层实现。

举个例子， website 是一个包含 10086 个键值对的哈希键， 这个哈希键的键都是一些数据库的名字， 而键的值就是数据库的主页网址：

redis> HLEN website
(integer) 10086

redis> HGETALL website
1) "Redis"
2) "Redis.io"
3) "MariaDB"
4) "MariaDB.org"
5) "MongoDB"
6) "MongoDB.org"
# ...

website 键的底层实现就是一个字典， 字典中包含了 10086 个键值对：

其中一个键值对的键为 “Redis” ， 值为 “Redis.io” 。
另一个键值对的键为 “MariaDB” ， 值为 “MariaDB.org” ；
还有一个键值对的键为 “MongoDB” ， 值为 “MongoDB.org” ；

2.3.2 字典的实现
2.3.2.1 哈希表节点
typedef struct dictEntry {

    // 键
    void *key;

    // 值
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
    } v;

    // 指向下个哈希表节点，形成链表
    struct dictEntry *next;
    
} dictEntry;

key 属性保存着键值对中的键， 而 v 属性则保存着键值对中的值， 其中键值对的值可以是一个指针， 或者是一个 uint64_t 整数， 又或者是一个 int64_t 整数。

next 属性是指向另一个哈希表节点的指针， 这个指针可以将多个哈希值相同的键值对连接在一次， 以此来解决键冲突（collision）的问题。

举个例子， 图 4-2 就展示了如何通过 next 指针， 将两个索引值相同的键 k1 和 k0 连接在一起。

2.3.2.2 哈希表

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

typedef struct dictht {

    // 哈希表数组
    dictEntry **table;

    // 哈希表大小
    unsigned long size;

    // 哈希表大小掩码，用于计算索引值
    // 总是等于 size - 1
    unsigned long sizemask;

    // 该哈希表已有节点的数量
    unsigned long used;

} dictht;

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

size 属性记录了哈希表的大小， 也即是 table 数组的大小， 而 used 属性则记录了哈希表目前已有节点（键值对）的数量。

sizemask 属性的值总是等于 size - 1 ， 这个属性和哈希值一起决定一个键应该被放到 table 数组的哪个索引上面。

图 4-1 展示了一个大小为 4 的空哈希表 （没有包含任何键值对）。

2.3.2.3 字典
typedef struct dict {

    // 类型特定函数
    dictType *type;

    // 私有数据
    void *privdata;

    // 哈希表
    dictht ht[2];

    // rehash 索引
    // 当 rehash 不在进行时，值为 -1
    int rehashidx; /* rehashing not in progress if rehashidx == -1 */

} dict;

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

type 属性是一个指向 dictType 结构的指针， 每个 dictType 结构保存了一簇用于操作特定类型键值对的函数， Redis 会为用途不同的字典设置不同的类型特定函数。
而 privdata 属性则保存了需要传给那些类型特定函数的可选参数。

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;

ht 属性是一个包含两个项的数组， 数组中的每个项都是一个 dictht 哈希表， 一般情况下， 字典只使用 ht[0] 哈希表， ht[1] 哈希表只会在对 ht[0] 哈希表进行 rehash 时使用。

除了 ht[1] 之外， 另一个和 rehash 有关的属性就是 rehashidx ： 它记录了 rehash 目前的进度， 如果目前没有在进行 rehash ， 那么它的值为 -1 。

图 4-3 展示了一个普通状态下（没有进行 rehash）的字典：

2.3.3 哈希算法

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

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

// 使用字典设置的哈希函数，计算键 key 的哈希值
hash = dict->type->hashFunction(key);

// 使用哈希表的 sizemask 属性和哈希值，计算出索引值
// 根据情况不同， ht[x] 可以是 ht[0] 或者 ht[1]
index = hash & dict->ht[x].sizemask;

举个例子， 对于图 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 年发明， 这种算法的优点在于， 即使输入的键是有规律的， 算法仍能给出一个很好的随机分布性， 并且算法的计算速度也非常快。

2.3.4 解决键冲突

当有两个或以上数量的键被分配到了哈希表数组的同一个索引上面时， 我们称这些键发生了冲突（collision）。

Redis 的哈希表使用链地址法（separate chaining）来解决键冲突： 每个哈希表节点都有一个 next 指针， 多个哈希表节点可以用 next 指针构成一个单向链表， 被分配到同一个索引上的多个节点可以用这个单向链表连接起来， 这就解决了键冲突的问题。

举个例子， 假设程序要将键值对 k2 和 v2 添加到图 4-6 所示的哈希表里面， 并且计算得出 k2 的索引值为 2 ， 那么键 k1 和 k2 将产生冲突， 而解决冲突的办法就是使用 next 指针将键 k2 和 k1 所在的节点连接起来， 如图 4-7 所示。

因为 dictEntry 节点组成的链表没有指向链表表尾的指针， 所以为了速度考虑， 程序总是将新节点添加到链表的表头位置（复杂度为 O(1)）， 排在其他已有节点的前面。

2.3.5 rehash

随着操作的不断执行， 哈希表保存的键值对会逐渐地增多或者减少， 为了让哈希表的负载因子（load factor）维持在一个合理的范围之内， 当哈希表保存的键值对数量太多或者太少时， 程序需要对哈希表的大小进行相应的扩展或者收缩。

扩展和收缩哈希表的工作可以通过执行 rehash （重新散列）操作来完成， Redis 对字典的哈希表执行 rehash 的步骤如下：

为字典的 ht[1] 哈希表分配空间， 这个哈希表的空间大小取决于要执行的操作， 以及 ht[0] 当前包含的键值对数量 （也即是 ht[0].used 属性的值）：
如果执行的是扩展操作， 那么 ht[1] 的大小为第一个大于等于 ht[0].used * 2 的 2^n （2 的 n 次方幂）；
如果执行的是收缩操作， 那么 ht[1] 的大小为第一个大于等于 ht[0].used 的 2^n 。
将保存在 ht[0] 中的所有键值对 rehash 到 ht[1] 上面： rehash 指的是重新计算键的哈希值和索引值， 然后将键值对放置到 ht[1] 哈希表的指定位置上。
当 ht[0] 包含的所有键值对都迁移到了 ht[1] 之后 （ht[0] 变为空表）， 释放 ht[0] ， 将 ht[1] 设置为 ht[0] ， 并在 ht[1] 新创建一个空白哈希表， 为下一次 rehash 做准备。
举个例子， 假设程序要对图 4-8 所示字典的 ht[0] 进行扩展操作， 那么程序将执行以下步骤：

ht[0].used 当前的值为 4 ， 4 * 2 = 8 ， 而 8 （2^3）恰好是第一个大于等于 4 的 2 的 n 次方， 所以程序会将 ht[1] 哈希表的大小设置为 8 。 图 4-9 展示了 ht[1] 在分配空间之后， 字典的样子。
将 ht[0] 包含的四个键值对都 rehash 到 ht[1] ， 如图 4-10 所示。
释放 ht[0] ，并将 ht[1] 设置为 ht[0] ，然后为 ht[1] 分配一个空白哈希表，如图 4-11 所示。
至此， 对哈希表的扩展操作执行完毕， 程序成功将哈希表的大小从原来的 4 改为了现在的 8 。

哈希表的扩展与收缩
当以下条件中的任意一个被满足时， 程序会自动开始对哈希表执行扩展操作：
服务器目前没有在执行 BGSAVE 命令或者 BGREWRITEAOF 命令， 并且哈希表的负载因子大于等于 1 ；
服务器目前正在执行 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时， 程序自动开始对哈希表执行收缩操作。

2.3.6 渐进式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 的详细步骤：

为 ht[1] 分配空间， 让字典同时持有 ht[0] 和 ht[1] 两个哈希表。
在字典中维持一个索引计数器变量 rehashidx ， 并将它的值设置为 0 ， 表示 rehash 工作正式开始。
在 rehash 进行期间， 每次对字典执行添加、删除、查找或者更新操作时， 程序除了执行指定的操作以外， 还会顺带将 ht[0] 哈希表在 rehashidx 索引上的所有键值对 rehash 到 ht[1] ， 当 rehash 工作完成之后， 程序将 rehashidx 属性的值增一。
随着字典操作的不断执行， 最终在某个时间点上， 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 操作的执行而最终变成空表。

2.4 跳跃表

2.4.1 skiplist的定义

跳跃表（skiplist）是一种有序数据结构， 它通过在每个节点中维持多个指向其他节点的指针， 从而达到快速访问节点的目的。

跳跃表支持平均 O(log N) 最坏 O(N) 复杂度的节点查找， 还可以通过顺序性操作来批量处理节点。

在大部分情况下， 跳跃表的效率可以和平衡树相媲美， 并且因为跳跃表的实现比平衡树要来得更为简单， 所以有不少程序都使用跳跃表来代替平衡树。

Redis 使用跳跃表作为有序集合键的底层实现之一： 如果一个有序集合包含的元素数量比较多， 又或者有序集合中元素的成员（member）是比较长的字符串时， Redis 就会使用跳跃表来作为有序集合键的底层实现。

举个例子， fruit-price 是一个有序集合键， 这个有序集合以水果名为成员， 水果价钱为分值， 保存了 130 款水果的价钱：

redis> ZRANGE fruit-price 0 2 WITHSCORES
1) "banana"
2) "5"
3) "cherry"
4) "6.5"
5) "apple"
6) "8"

redis> ZCARD fruit-price
(integer) 130

fruit-price 有序集合的所有数据都保存在一个跳跃表里面， 其中每个跳跃表节点（node）都保存了一款水果的价钱信息， 所有水果按价钱的高低从低到高在跳跃表里面排序：

跳跃表的第一个元素的成员为 “banana” ， 它的分值为 5 ；
跳跃表的第二个元素的成员为 “cherry” ， 它的分值为 6.5 ；
跳跃表的第三个元素的成员为 “apple” ， 它的分值为 8 ；
诸如此类。

和链表、字典等数据结构被广泛地应用在 Redis 内部不同， Redis 只在两个地方用到了跳跃表， 一个是实现有序集合键， 另一个是在集群节点中用作内部数据结构， 除此之外， 跳跃表在 Redis 里面没有其他用途。

2.4.2 跳跃表的实现

Redis 的跳跃表由 redis.h/zskiplistNode 和 redis.h/zskiplist 两个结构定义， 其中 zskiplistNode 结构用于表示跳跃表节点， 而 zskiplist 结构则用于保存跳跃表节点的相关信息， 比如节点的数量， 以及指向表头节点和表尾节点的指针， 等等。

图 5-1 展示了一个跳跃表示例， 位于图片最左边的是 zskiplist 结构， 该结构包含以下属性：
header ：指向跳跃表的表头节点。
tail ：指向跳跃表的表尾节点。
level ：记录目前跳跃表内，层数最大的那个节点的层数（表头节点的层数不计算在内）。
length ：记录跳跃表的长度，也即是，跳跃表目前包含节点的数量（表头节点不计算在内）。
位于 zskiplist 结构右方的是四个 zskiplistNode 结构， 该结构包含以下属性：

层（level）：节点中用 L1 、 L2 、 L3 等字样标记节点的各个层， L1 代表第一层， L2 代表第二层，以此类推。每个层都带有两个属性：前进指针和跨度。前进指针用于访问位于表尾方向的其他节点，而跨度则记录了前进指针所指向节点和当前节点的距离。在上面的图片中，连线上带有数字的箭头就代表前进指针，而那个数字就是跨度。当程序从表头向表尾进行遍历时，访问会沿着层的前进指针进行。
后退（backward）指针：节点中用 BW 字样标记节点的后退指针，它指向位于当前节点的前一个节点。后退指针在程序从表尾向表头遍历时使用。
分值（score）：各个节点中的 1.0 、 2.0 和 3.0 是节点所保存的分值。在跳跃表中，节点按各自所保存的分值从小到大排列。
成员对象（obj）：各个节点中的 o1 、 o2 和 o3 是节点所保存的成员对象。
注意表头节点和其他节点的构造是一样的： 表头节点也有后退指针、分值和成员对象， 不过表头节点的这些属性都不会被用到， 所以图中省略了这些部分， 只显示了表头节点的各个层。

本节接下来的内容将对 zskiplistNode 和 zskiplist 两个结构进行更详细的介绍。

2.4.2.1 跳跃表节点
typedef struct zskiplistNode {

    // 后退指针
    struct zskiplistNode *backward;

    // 分值
    double score;

    // 成员对象
    robj *obj;

    // 层
    struct zskiplistLevel {

        // 前进指针
        struct zskiplistNode *forward;

        // 跨度
        unsigned int span;

    } level[];

} zskiplistNode;
  1. 层
    跳跃表节点的level数组可以包含多个元素， 每个元素都包含一个指向其他节点的指针， 程序可以通过这些层来加快访问其他节点的速度， 一般来说， 层的数量越多， 访问其他节点的速度就越快。
    每次创建一个新跳跃表节点的时候， 程序都根据幂次定律 （power law，越大的数出现的概率越小） 随机生成一个介于1和32之间的值作为level数组的大小， 这个大小就是层的“高度”。
    图 5-2 分别展示了三个高度为1层、3层和5层的节点， 因为 C 语言的数组索引总是从0开始的， 所以节点的第一层是level[0]， 而第二层是level[1]， 以此类推。
  2. 前进指针
    每个层都有一个指向表尾方向的前进指针（level[i].forward 属性）， 用于从表头向表尾方向访问节点。
    图 5-3 用虚线表示出了程序从表头向表尾方向， 遍历跳跃表中所有节点的路径：

    迭代程序首先访问跳跃表的第一个节点（表头）， 然后从第四层的前进指针移动到表中的第二个节点。
    在第二个节点时， 程序沿着第二层的前进指针移动到表中的第三个节点。
    在第三个节点时， 程序同样沿着第二层的前进指针移动到表中的第四个节点。
    当程序再次沿着第四个节点的前进指针移动时， 它碰到一个 NULL ， 程序知道这时已经到达了跳跃表的表尾， 于是结束这次遍历。
  3. 跨度
    层的跨度（level[i].span 属性）用于记录两个节点之间的距离：
    两个节点之间的跨度越大， 它们相距得就越远。
    指向 NULL 的所有前进指针的跨度都为 0 ， 因为它们没有连向任何节点。
    初看上去， 很容易以为跨度和遍历操作有关， 但实际上并不是这样 —— 遍历操作只使用前进指针就可以完成了， 跨度实际上是用来计算排位（rank）的： 在查找某个节点的过程中， 将沿途访问过的所有层的跨度累计起来， 得到的结果就是目标节点在跳跃表中的排位。
    举个例子， 图 5-4 用虚线标记了在跳跃表中查找分值为 3.0 、 成员对象为 o3 的节点时， 沿途经历的层： 查找的过程只经过了一个层， 并且层的跨度为 3 ， 所以目标节点在跳跃表中的排位为 3 。

    再举个例子， 图 5-5 用虚线标记了在跳跃表中查找分值为 2.0 、 成员对象为 o2 的节点时， 沿途经历的层： 在查找节点的过程中， 程序经过了两个跨度为 1 的节点， 因此可以计算出， 目标节点在跳跃表中的排位为 2 。
  4. 后退指针
    节点的后退指针（backward 属性）用于从表尾向表头方向访问节点： 跟可以一次跳过多个节点的前进指针不同， 因为每个节点只有一个后退指针， 所以每次只能后退至前一个节点。
    图 5-6 用虚线展示了如果从表尾向表头遍历跳跃表中的所有节点： 程序首先通过跳跃表的 tail 指针访问表尾节点， 然后通过后退指针访问倒数第二个节点， 之后再沿着后退指针访问倒数第三个节点， 再之后遇到指向 NULL 的后退指针， 于是访问结束。
  5. 分值和成员
    节点的分值（score 属性）是一个 double 类型的浮点数， 跳跃表中的所有节点都按分值从小到大来排序。
    节点的成员对象（obj 属性）是一个指针， 它指向一个字符串对象， 而字符串对象则保存着一个 SDS 值。
    在同一个跳跃表中， 各个节点保存的成员对象必须是唯一的， 但是多个节点保存的分值却可以是相同的： 分值相同的节点将按照成员对象在字典序中的大小来进行排序， 成员对象较小的节点会排在前面（靠近表头的方向）， 而成员对象较大的节点则会排在后面（靠近表尾的方向）。
    举个例子， 在图 5-7 所示的跳跃表中， 三个跳跃表节点都保存了相同的分值 10086.0 ， 但保存成员对象 o1 的节点却排在保存成员对象 o2 和 o3 的节点之前， 而保存成员对象 o2 的节点又排在保存成员对象 o3 的节点之前， 由此可见， o1 、 o2 、 o3 三个成员对象在字典中的排序为 o1 <= o2 <= o3 。
2.4.2.2 跳跃表

虽然仅靠多个跳跃表节点就可以组成一个跳跃表， 如图 5-8 所示。

但通过使用一个 zskiplist 结构来持有这些节点， 程序可以更方便地对整个跳跃表进行处理， 比如快速访问跳跃表的表头节点和表尾节点， 又或者快速地获取跳跃表节点的数量（也即是跳跃表的长度）等信息， 如图 5-9 所示。

zskiplist 结构的定义如下：

typedef struct zskiplist {

    // 表头节点和表尾节点
    struct zskiplistNode *header, *tail;

    // 表中节点的数量
    unsigned long length;

    // 表中层数最大的节点的层数
    int level;

} zskiplist;

header 和 tail 指针分别指向跳跃表的表头和表尾节点， 通过这两个指针， 程序定位表头节点和表尾节点的复杂度为 O(1) 。

通过使用 length 属性来记录节点的数量， 程序可以在 O(1) 复杂度内返回跳跃表的长度。

level 属性则用于在 O(1) 复杂度内获取跳跃表中层高最大的那个节点的层数量， 注意表头节点的层高并不计算在内。

2.5 整数集合

2.5.1 整数集合的定义

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

举个例子， 如果我们创建一个只包含五个元素的集合键， 并且集合中的所有元素都是整数值， 那么这个集合键的底层实现就会是整数集合：

redis> SADD numbers 1 3 5 7 9
(integer) 5

redis> OBJECT ENCODING numbers
"intset"
2.5.2 整数集合的实现

整数集合（intset）是 Redis 用于保存整数值的集合抽象数据结构， 它可以保存类型为 int16_t 、 int32_t 或者 int64_t 的整数值， 并且保证集合中不会出现重复元素。

每个 intset.h/intset 结构表示一个整数集合：

typedef struct intset {

    // 编码方式
    uint32_t encoding;

    // 集合包含的元素数量
    uint32_t length;

    // 保存元素的数组
    int8_t contents[];

} intset;

contents 数组是整数集合的底层实现： 整数集合的每个元素都是 contents 数组的一个数组项（item）， 各个项在数组中按值的大小从小到大有序地排列， 并且数组中不包含任何重复项。

length 属性记录了整数集合包含的元素数量， 也即是 contents 数组的长度。

虽然 intset 结构将 contents 属性声明为 int8_t 类型的数组， 但实际上 contents 数组并不保存任何 int8_t 类型的值 —— contents 数组的真正类型取决于 encoding 属性的值：

如果 encoding 属性的值为 INTSET_ENC_INT16 ， 那么 contents 就是一个 int16_t 类型的数组， 数组里的每个项都是一个 int16_t 类型的整数值 （最小值为 -32,768 ，最大值为 32,767 ）。
如果 encoding 属性的值为 INTSET_ENC_INT32 ， 那么 contents 就是一个 int32_t 类型的数组， 数组里的每个项都是一个 int32_t 类型的整数值 （最小值为 -2,147,483,648 ，最大值为 2,147,483,647 ）。
如果 encoding 属性的值为 INTSET_ENC_INT64 ， 那么 contents 就是一个 int64_t 类型的数组， 数组里的每个项都是一个 int64_t 类型的整数值 （最小值为 -9,223,372,036,854,775,808 ，最大值为 9,223,372,036,854,775,807 ）。
图 6-1 展示了一个整数集合示例：

encoding 属性的值为 INTSET_ENC_INT16 ， 表示整数集合的底层实现为 int16_t 类型的数组， 而集合保存的都是 int16_t 类型的整数值。
length 属性的值为 5 ， 表示整数集合包含五个元素。
contents 数组按从小到大的顺序保存着集合中的五个元素。
因为每个集合元素都是 int16_t 类型的整数值， 所以 contents 数组的大小等于 sizeof(int16_t) * 5 = 16 * 5 = 80 位。

图 6-2 展示了另一个整数集合示例：

encoding 属性的值为 INTSET_ENC_INT64 ， 表示整数集合的底层实现为 int64_t 类型的数组， 而数组中保存的都是 int64_t 类型的整数值。
length 属性的值为 4 ， 表示整数集合包含四个元素。
contents 数组按从小到大的顺序保存着集合中的四个元素。
因为每个集合元素都是 int64_t 类型的整数值， 所以 contents 数组的大小为 sizeof(int64_t) * 4 = 64 * 4 = 256 位。

虽然 contents 数组保存的四个整数值中， 只有 -2675256175807981027 是真正需要用 int64_t 类型来保存的， 而其他的 1 、 3 、 5 三个值都可以用 int16_t 类型来保存， 不过根据整数集合的升级规则， 当向一个底层为 int16_t 数组的整数集合添加一个 int64_t 类型的整数值时， 整数集合已有的所有元素都会被转换成 int64_t 类型， 所以 contents 数组保存的四个整数值都是 int64_t 类型的， 不仅仅是 -2675256175807981027 。

2.5.3 升级

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

升级整数集合并添加新元素共分为三步进行：

根据新元素的类型， 扩展整数集合底层数组的空间大小， 并为新元素分配空间。
将底层数组现有的所有元素都转换成与新元素相同的类型， 并将类型转换后的元素放置到正确的位上， 而且在放置元素的过程中， 需要继续维持底层数组的有序性质不变。
将新元素添加到底层数组里面。
举个例子， 假设现在有一个 INTSET_ENC_INT16 编码的整数集合， 集合中包含三个 int16_t 类型的元素， 如图 6-3 所示。

因为每个元素都占用 16 位空间， 所以整数集合底层数组的大小为 3 * 16 = 48 位， 图 6-4 展示了整数集合的三个元素在这 48 位里的位置。

现在， 假设我们要将类型为 int32_t 的整数值 65535 添加到整数集合里面， 因为 65535 的类型 int32_t 比整数集合当前所有元素的类型都要长， 所以在将 65535 添加到整数集合之前， 程序需要先对整数集合进行升级。

升级首先要做的是， 根据新类型的长度， 以及集合元素的数量（包括要添加的新元素在内）， 对底层数组进行空间重分配。

整数集合目前有三个元素， 再加上新元素 65535 ， 整数集合需要分配四个元素的空间， 因为每个 int32_t 整数值需要占用 32 位空间， 所以在空间重分配之后， 底层数组的大小将是 32 * 4 = 128 位， 如图 6-5 所示。

虽然程序对底层数组进行了空间重分配， 但数组原有的三个元素 1 、 2 、 3 仍然是 int16_t 类型， 这些元素还保存在数组的前 48 位里面， 所以程序接下来要做的就是将这三个元素转换成 int32_t 类型， 并将转换后的元素放置到正确的位上面， 而且在放置元素的过程中， 需要维持底层数组的有序性质不变。

首先， 因为元素 3 在 1 、 2 、 3 、 65535 四个元素中排名第三， 所以它将被移动到 contents 数组的索引 2 位置上， 也即是数组 64 位至 95 位的空间内， 如图 6-6 所示。

接着， 因为元素 2 在 1 、 2 、 3 、 65535 四个元素中排名第二， 所以它将被移动到 contents 数组的索引 1 位置上， 也即是数组的 32 位至 63 位的空间内， 如图 6-7 所示。

之后， 因为元素 1 在 1 、 2 、 3 、 65535 四个元素中排名第一， 所以它将被移动到 contents 数组的索引 0 位置上， 也即是数组的 0 位至 31 位的空间内， 如图 6-8 所示。

然后， 因为元素 65535 在 1 、 2 、 3 、 65535 四个元素中排名第四， 所以它将被添加到 contents 数组的索引 3 位置上， 也即是数组的 96 位至 127 位的空间内， 如图 6-9 所示。

最后， 程序将整数集合 encoding 属性的值从 INTSET_ENC_INT16 改为 INTSET_ENC_INT32 ， 并将 length 属性的值从 3 改为 4 ， 设置完成之后的整数集合如图 6-10 所示。

因为每次向整数集合添加新元素都可能会引起升级， 而每次升级都需要对底层数组中已有的所有元素进行类型转换， 所以向整数集合添加新元素的时间复杂度为 O(N) 。

其他类型的升级操作， 比如从 INTSET_ENC_INT16 编码升级为 INTSET_ENC_INT64 编码， 或者从 INTSET_ENC_INT32 编码升级为 INTSET_ENC_INT64 编码， 升级的过程都和上面展示的升级过程类似。

升级之后新元素的摆放位置
因为引发升级的新元素的长度总是比整数集合现有所有元素的长度都大， 所以这个新元素的值要么就大于所有现有元素， 要么就小于所有现有元素：

在新元素小于所有现有元素的情况下， 新元素会被放置在底层数组的最开头（索引 0 ）；
在新元素大于所有现有元素的情况下， 新元素会被放置在底层数组的最末尾（索引 length-1 ）。

2.5.4 升级的好处

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

2.5.4.1 提升灵活性

因为 C 语言是静态类型语言， 为了避免类型错误， 我们通常不会将两种不同类型的值放在同一个数据结构里面。

比如说， 我们一般只使用 int16_t 类型的数组来保存 int16_t 类型的值， 只使用 int32_t 类型的数组来保存 int32_t 类型的值， 诸如此类。

但是， 因为整数集合可以通过自动升级底层数组来适应新元素， 所以我们可以随意地将 int16_t 、 int32_t 或者 int64_t 类型的整数添加到集合中， 而不必担心出现类型错误， 这种做法非常灵活。

2.5.4.2 节约内存

当然， 要让一个数组可以同时保存 int16_t 、 int32_t 、 int64_t 三种类型的值， 最简单的做法就是直接使用 int64_t 类型的数组作为整数集合的底层实现。 不过这样一来， 即使添加到整数集合里面的都是 int16_t 类型或者 int32_t 类型的值， 数组都需要使用 int64_t 类型的空间去保存它们， 从而出现浪费内存的情况。

而整数集合现在的做法既可以让集合能同时保存三种不同类型的值， 又可以确保升级操作只会在有需要的时候进行， 这可以尽量节省内存。

比如说， 如果我们一直只向整数集合添加 int16_t 类型的值， 那么整数集合的底层实现就会一直是 int16_t 类型的数组， 只有在我们要将 int32_t 类型或者 int64_t 类型的值添加到集合时， 程序才会对数组进行升级。

2.5.5 降级

整数集合不支持降级操作， 一旦对数组进行了升级， 编码就会一直保持升级后的状态。

举个例子， 对于图 6-11 所示的整数集合来说， 即使我们将集合里唯一一个真正需要使用 int64_t 类型来保存的元素 4294967295 删除了， 整数集合的编码仍然会维持 INTSET_ENC_INT64 ， 底层数组也仍然会是 int64_t 类型的， 如图 6-12 所示。

2.6 压缩列表

2.6.1 压缩列表的定义

压缩列表（ziplist）是列表键和哈希键的底层实现之一。

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

比如说， 执行以下命令将创建一个压缩列表实现的列表键：

redis> RPUSH lst 1 3 5 10086 "hello" "world"
(integer) 6

redis> OBJECT ENCODING lst
"ziplist"

因为列表键里面包含的都是 1 、 3 、 5 、 10086 这样的小整数值， 以及 “hello” 、 “world” 这样的短字符串。

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

举个例子， 执行以下命令将创建一个压缩列表实现的哈希键：

redis> HMSET profile "name" "Jack" "age" 28 "job" "Programmer"
OK

redis> OBJECT ENCODING profile
"ziplist"

因为哈希键里面包含的所有键和值都是小整数值或者短字符串。

2.6.2 压缩列表的构成

压缩列表是 Redis 为了节约内存而开发的， 由一系列特殊编码的连续内存块组成的顺序型（sequential）数据结构。

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

图 7-1 展示了压缩列表的各个组成部分， 表 7-1 则记录了各个组成部分的类型、长度、以及用途。

表 7-1 压缩列表各个组成部分的详细说明

属性类型长度用途
zlbytesuint32_t4 字节记录整个压缩列表占用的内存字节数：在对压缩列表进行内存重分配， 或者计算 zlend 的位置时使用。
zltailuint32_t4 字节记录压缩列表表尾节点距离压缩列表的起始地址有多少字节： 通过这个偏移量，程序无须遍历整个压缩列表就可以确定表尾节点的地址。
zllenuint16_t2 字节记录了压缩列表包含的节点数量： 当这个属性的值小于 UINT16_MAX （65535）时， 这个属性的值就是压缩列表包含节点的数量； 当这个值等于 UINT16_MAX 时， 节点的真实数量需要遍历整个压缩列表才能计算得出。
entryX列表节点不定压缩列表包含的各个节点，节点的长度由节点保存的内容决定。
zlenduint8_t1 字节特殊值 0xFF （十进制 255 ），用于标记压缩列表的末端。

图 7-2 展示了一个压缩列表示例：

列表 zlbytes 属性的值为 0x50 （十进制 80）， 表示压缩列表的总长为 80 字节。
列表 zltail 属性的值为 0x3c （十进制 60）， 这表示如果我们有一个指向压缩列表起始地址的指针 p ， 那么只要用指针 p 加上偏移量 60 ， 就可以计算出表尾节点 entry3 的地址。
列表 zllen 属性的值为 0x3 （十进制 3）， 表示压缩列表包含三个节点。

图 7-3 展示了另一个压缩列表示例：

列表 zlbytes 属性的值为 0xd2 （十进制 210）， 表示压缩列表的总长为 210 字节。
列表 zltail 属性的值为 0xb3 （十进制 179）， 这表示如果我们有一个指向压缩列表起始地址的指针 p ， 那么只要用指针 p 加上偏移量 179 ， 就可以计算出表尾节点 entry5 的地址。
列表 zllen 属性的值为 0x5 （十进制 5）， 表示压缩列表包含五个节点。

2.6.3 压缩列表节点的构成

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

长度小于等于 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 所示。

2.6.3.1 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 字节。

图 7-6 展示了一个包含五字节长 previous_entry_length 属性的压缩节点， 属性的值为 0xFE00002766 ， 其中值的最高位字节 0xFE 表示这是一个五字节长的 previous_entry_length 属性， 而之后的四字节 0x00002766 （十进制值 10086 ）才是前一节点的实际长度。

因为节点的 previous_entry_length 属性记录了前一个节点的长度， 所以程序可以通过指针运算， 根据当前节点的起始地址来计算出前一个节点的起始地址。

举个例子， 如果我们有一个指向当前节点起始地址的指针 c ， 那么我们只要用指针 c 减去当前节点 previous_entry_length 属性的值， 就可以得出一个指向前一个节点起始地址的指针 p ， 如图 7-7 所示。

压缩列表的从表尾向表头遍历操作就是使用这一原理实现的： 只要我们拥有了一个指向某个节点起始地址的指针， 那么通过这个指针以及这个节点的 previous_entry_length 属性， 程序就可以一直向前一个节点回溯， 最终到达压缩列表的表头节点。

图 7-8 展示了一个从表尾节点向表头节点进行遍历的完整过程：

首先，我们拥有指向压缩列表表尾节点 entry4 起始地址的指针 p1 （指向表尾节点的指针可以通过指向压缩列表起始地址的指针加上 zltail 属性的值得出）；
通过用 p1 减去 entry4 节点 previous_entry_length 属性的值， 我们得到一个指向 entry4 前一节点 entry3 起始地址的指针 p2 ；
通过用 p2 减去 entry3 节点 previous_entry_length 属性的值， 我们得到一个指向 entry3 前一节点 entry2 起始地址的指针 p3 ；
通过用 p3 减去 entry2 节点 previous_entry_length 属性的值， 我们得到一个指向 entry2 前一节点 entry1 起始地址的指针 p4 ， entry1 为压缩列表的表头节点；
最终， 我们从表尾节点向表头节点遍历了整个列表。




2.6.3.2 encoding

节点的 encoding 属性记录了节点的 content 属性所保存数据的类型以及长度：

一字节、两字节或者五字节长， 值的最高位为 00 、 01 或者 10 的是字节数组编码： 这种编码表示节点的 content 属性保存着字节数组， 数组的长度由编码除去最高两位之后的其他位记录；
一字节长， 值的最高位以 11 开头的是整数编码： 这种编码表示节点的 content 属性保存着整数值， 整数值的类型和长度由编码除去最高两位之后的其他位记录；
表 7-2 记录了所有可用的字节数组编码， 而表 7-3 则记录了所有可用的整数编码。 表格中的下划线 _ 表示留空， 而 b 、 x 等变量则代表实际的二进制数据， 为了方便阅读， 多个字节之间用空格隔开。

表 7-2 字节数组编码

编码编码长度content 属性保存的值
00bbbbbb1 字节长度小于等于 63 字节的字节数组。
01bbbbbb xxxxxxxx2 字节长度小于等于 16383 字节的字节数组。
10______ aaaaaaaa bbbbbbbb cccccccc dddddddd5 字节长度小于等于 4294967295 的字节数组。

表 7-3 整数编码

编码编码长度content 属性保存的值
110000001 字节int16_t 类型的整数。
110100001 字节int32_t 类型的整数。
111000001 字节int64_t 类型的整数。
111100001 字节24 位有符号整数。
111111101 字节8 位有符号整数。
1111xxxx1 字节使用这一编码的节点没有相应的 content 属性， 因为编码本身的 xxxx 四个位已经保存了一个介于 0 和 12 之间的值， 所以它无须 content 属性。
2.6.3.3 content

节点的 content 属性负责保存节点的值， 节点值可以是一个字节数组或者整数， 值的类型和长度由节点的 encoding 属性决定。

图 7-9 展示了一个保存字节数组的节点示例：

编码的最高两位 00 表示节点保存的是一个字节数组；
编码的后六位 001011 记录了字节数组的长度 11 ；
content 属性保存着节点的值 “hello world” 。

图 7-10 展示了一个保存整数值的节点示例：

编码 11000000 表示节点保存的是一个 int16_t 类型的整数值；
content 属性保存着节点的值 10086 。

2.6.4 连锁更新

前面说过， 每个节点的 previous_entry_length 属性都记录了前一个节点的长度：

如果前一节点的长度小于 254 字节， 那么 previous_entry_length 属性需要用 1 字节长的空间来保存这个长度值。
如果前一节点的长度大于等于 254 字节， 那么 previous_entry_length 属性需要用 5 字节长的空间来保存这个长度值。
现在， 考虑这样一种情况： 在一个压缩列表中， 有多个连续的、长度介于 250 字节到 253 字节之间的节点 e1 至 eN ， 如图 7-11 所示。

因为 e1 至 eN 的所有节点的长度都小于 254 字节， 所以记录这些节点的长度只需要 1 字节长的 previous_entry_length 属性， 换句话说， e1 至 eN 的所有节点的 previous_entry_length 属性都是 1 字节长的。

这时， 如果我们将一个长度大于等于 254 字节的新节点 new 设置为压缩列表的表头节点， 那么 new 将成为 e1 的前置节点， 如图 7-12 所示。

因为 e1 的 previous_entry_length 属性仅长 1 字节， 它没办法保存新节点 new 的长度， 所以程序将对压缩列表执行空间重分配操作， 并将 e1 节点的 previous_entry_length 属性从原来的 1 字节长扩展为 5 字节长。

现在， 麻烦的事情来了 —— e1 原本的长度介于 250 字节至 253 字节之间， 在为 previous_entry_length 属性新增四个字节的空间之后， e1 的长度就变成了介于 254 字节至 257 字节之间， 而这种长度使用 1 字节长的 previous_entry_length 属性是没办法保存的。

因此， 为了让 e2 的 previous_entry_length 属性可以记录下 e1 的长度， 程序需要再次对压缩列表执行空间重分配操作， 并将 e2 节点的 previous_entry_length 属性从原来的 1 字节长扩展为 5 字节长。

正如扩展 e1 引发了对 e2 的扩展一样， 扩展 e2 也会引发对 e3 的扩展， 而扩展 e3 又会引发对 e4 的扩展……为了让每个节点的 previous_entry_length 属性都符合压缩列表对节点的要求， 程序需要不断地对压缩列表执行空间重分配操作， 直到 eN 为止。

Redis 将这种在特殊情况下产生的连续多次空间扩展操作称之为“连锁更新”（cascade update）， 图 7-13 展示了这一过程。





除了添加新节点可能会引发连锁更新之外， 删除节点也可能会引发连锁更新。

考虑图 7-14 所示的压缩列表， 如果 e1 至 eN 都是大小介于 250 字节至 253 字节的节点， big 节点的长度大于等于 254 字节（需要 5 字节的 previous_entry_length 来保存）， 而 small 节点的长度小于 254 字节（只需要 1 字节的 previous_entry_length 来保存）， 那么当我们将 small 节点从压缩列表中删除之后， 为了让 e1 的 previous_entry_length 属性可以记录 big 节点的长度， 程序将扩展 e1 的空间， 并由此引发之后的连锁更新。

因为连锁更新在最坏情况下需要对压缩列表执行 N 次空间重分配操作， 而每次空间重分配的最坏复杂度为 O(N) ， 所以连锁更新的最坏复杂度为 O(N^2) 。

要注意的是， 尽管连锁更新的复杂度较高， 但它真正造成性能问题的几率是很低的：

首先， 压缩列表里要恰好有多个连续的、长度介于 250 字节至 253 字节之间的节点， 连锁更新才有可能被引发， 在实际中， 这种情况并不多见；
其次， 即使出现连锁更新， 但只要被更新的节点数量不多， 就不会对性能造成任何影响： 比如说， 对三五个节点进行连锁更新是绝对不会影响性能的；
因为以上原因， ziplistPush 等命令的平均复杂度仅为 O(N) ， 在实际中， 我们可以放心地使用这些函数， 而不必担心连锁更新会影响压缩列表的性能。

三、Redis对象

3.1 对象

在上一节里， 我们陆续介绍了 Redis 用到的所有主要数据结构， 比如简单动态字符串（SDS）、双端链表、字典、压缩列表、整数集合， 等等。

Redis 并没有直接使用这些数据结构来实现键值对数据库， 而是基于这些数据结构创建了一个对象系统， 这个系统包含字符串对象、列表对象、哈希对象、集合对象和有序集合对象这五种类型的对象， 每种对象都用到了至少一种我们前面所介绍的数据结构。

通过这五种不同类型的对象， Redis 可以在执行命令之前， 根据对象的类型来判断一个对象是否可以执行给定的命令。 使用对象的另一个好处是， 我们可以针对不同的使用场景， 为对象设置多种不同的数据结构实现， 从而优化对象在不同场景下的使用效率。

除此之外， Redis 的对象系统还实现了基于引用计数技术的内存回收机制： 当程序不再使用某个对象的时候， 这个对象所占用的内存就会被自动释放； 另外， Redis 还通过引用计数技术实现了对象共享机制， 这一机制可以在适当的条件下， 通过让多个数据库键共享同一个对象来节约内存。

最后， Redis 的对象带有访问时间记录信息， 该信息可以用于计算数据库键的空转时长， 在服务器启用了 maxmemory 功能的情况下， 空转时长较大的那些键可能会优先被服务器删除。

本章接下来将逐一介绍以上提到的 Redis 对象系统的各个特性。

3.2 对象的类型与编码

Redis 使用对象来表示数据库中的键和值， 每次当我们在 Redis 的数据库中新创建一个键值对时， 我们至少会创建两个对象， 一个对象用作键值对的键（键对象）， 另一个对象用作键值对的值（值对象）。

举个例子， 以下 SET 命令在数据库中创建了一个新的键值对， 其中键值对的键是一个包含了字符串值 “msg” 的对象， 而键值对的值则是一个包含了字符串值 “hello world” 的对象：

redis> SET msg "hello world"
OK

Redis 中的每个对象都由一个 redisObject 结构表示， 该结构中和保存数据有关的三个属性分别是 type 属性、 encoding 属性和 ptr 属性：

typedef struct redisObject {

    // 类型
    unsigned type:4;

    // 编码
    unsigned encoding:4;

    // 指向底层实现数据结构的指针
    void *ptr;

    // ...

} robj;
3.2.1 对象的类型

对象的 type 属性记录了对象的类型， 这个属性的值可以是表 8-1 列出的常量的其中一个。
表 8-1 对象的类型

类型常量对象的名称
REDIS_STRING字符串对象
REDIS_LIST列表对象
REDIS_HASH哈希对象
REDIS_SET集合对象
REDIS_ZSET有序集合对象

对于 Redis 数据库保存的键值对来说， 键总是一个字符串对象， 而值则可以是字符串对象、列表对象、哈希对象、集合对象或者有序集合对象的其中一种， 因此：

当我们称呼一个数据库键为“字符串键”时， 我们指的是“这个数据库键所对应的值为字符串对象”；
当我们称呼一个键为“列表键”时， 我们指的是“这个数据库键所对应的值为列表对象”，
诸如此类。

TYPE 命令的实现方式也与此类似， 当我们对一个数据库键执行 TYPE 命令时， 命令返回的结果为数据库键对应的值对象的类型， 而不是键对象的类型：

# 键为字符串对象，值为字符串对象

redis> SET msg "hello world"
OK

redis> TYPE msg
string

# 键为字符串对象，值为列表对象

redis> RPUSH numbers 1 3 5
(integer) 6

redis> TYPE numbers
list

# 键为字符串对象，值为哈希对象

redis> HMSET profile name Tome age 25 career Programmer
OK

redis> TYPE profile
hash

# 键为字符串对象，值为集合对象

redis> SADD fruits apple banana cherry
(integer) 3

redis> TYPE fruits
set

# 键为字符串对象，值为有序集合对象

redis> ZADD price 8.5 apple 5.0 banana 6.0 cherry
(integer) 3

redis> TYPE price
zset

表 8-2 不同类型值对象的 TYPE 命令输出

对象对象 type 属性的值TYPE 命令的输出
字符串对象REDIS_STRING“string”
列表对象REDIS_LIST“list”
哈希对象REDIS_HASH“hash”
集合对象REDIS_SET“set”
有序集合对象REDIS_ZSET“zset”
3.2.2 编码和底层实现

对象的 ptr 指针指向对象的底层实现数据结构， 而这些数据结构由对象的 encoding 属性决定。

encoding 属性记录了对象所使用的编码， 也即是说这个对象使用了什么数据结构作为对象的底层实现， 这个属性的值可以是表 8-3 列出的常量的其中一个。
表 8-3 对象的编码

编码常量编码所对应的底层数据结构
REDIS_ENCODING_INTlong 类型的整数
REDIS_ENCODING_EMBSTRembstr 编码的简单动态字符串
REDIS_ENCODING_RAW简单动态字符串
REDIS_ENCODING_HT字典
REDIS_ENCODING_LINKEDLIST双端链表
REDIS_ENCODING_ZIPLIST压缩列表
REDIS_ENCODING_INTSET整数集合
REDIS_ENCODING_SKIPLIST跳跃表和字典

表 8-4 不同类型和编码的对象

类型编码对象
REDIS_STRINGREDIS_ENCODING_INT使用整数值实现的字符串对象。
REDIS_STRINGREDIS_ENCODING_EMBSTR使用 embstr 编码的简单动态字符串实现的字符串对象。
REDIS_STRINGREDIS_ENCODING_RAW使用简单动态字符串实现的字符串对象。
REDIS_LISTREDIS_ENCODING_ZIPLIST使用压缩列表实现的列表对象。
REDIS_LISTREDIS_ENCODING_LINKEDLIST使用双端链表实现的列表对象。
REDIS_HASHREDIS_ENCODING_ZIPLIST使用压缩列表实现的哈希对象。
REDIS_HASHREDIS_ENCODING_HT使用字典实现的哈希对象。
REDIS_SETREDIS_ENCODING_INTSET使用整数集合实现的集合对象。
REDIS_SETREDIS_ENCODING_HT使用字典实现的集合对象。
REDIS_ZSETREDIS_ENCODING_ZIPLIST使用压缩列表实现的有序集合对象。
REDIS_ZSETREDIS_ENCODING_SKIPLIST使用跳跃表和字典实现的有序集合对象。

使用 OBJECT ENCODING 命令可以查看一个数据库键的值对象的编码：

redis> SET msg "hello wrold"
OK

redis> OBJECT ENCODING msg
"embstr"

redis> SET story "long long long long long long ago ..."
OK

redis> OBJECT ENCODING story
"raw"

redis> SADD numbers 1 3 5
(integer) 3

redis> OBJECT ENCODING numbers
"intset"

redis> SADD numbers "seven"
(integer) 1

redis> OBJECT ENCODING numbers
"hashtable"

表 8-5 列出了不同编码的对象所对应的 OBJECT ENCODING 命令输出。
表 8-5 OBJECT ENCODING 对不同编码的输出

对象所使用的底层数据结构编码常量OBJECT ENCODING 命令输出
整数REDIS_ENCODING_INT“int”
embstr 编码的简单动态字符串（SDS）REDIS_ENCODING_EMBSTR“embstr”
简单动态字符串REDIS_ENCODING_RAW“raw”
字典REDIS_ENCODING_HT“hashtable”
双端链表REDIS_ENCODING_LINKEDLIST“linkedlist”
压缩列表REDIS_ENCODING_ZIPLIST“ziplist”
整数集合REDIS_ENCODING_INTSET“intset”
跳跃表和字典REDIS_ENCODING_SKIPLIST“skiplist”

通过 encoding 属性来设定对象所使用的编码， 而不是为特定类型的对象关联一种固定的编码， 极大地提升了 Redis 的灵活性和效率， 因为 Redis 可以根据不同的使用场景来为一个对象设置不同的编码， 从而优化对象在某一场景下的效率。

举个例子， 在列表对象包含的元素比较少时， Redis 使用压缩列表作为列表对象的底层实现：

因为压缩列表比双端链表更节约内存， 并且在元素数量较少时， 在内存中以连续块方式保存的压缩列表比起双端链表可以更快被载入到缓存中；
随着列表对象包含的元素越来越多， 使用压缩列表来保存元素的优势逐渐消失时， 对象就会将底层实现从压缩列表转向功能更强、也更适合保存大量元素的双端链表上面；
其他类型的对象也会通过使用多种不同的编码来进行类似的优化。

在接下来的内容中， 我们将分别介绍 Redis 中的五种不同类型的对象， 说明这些对象底层所使用的编码方式， 列出对象从一种编码转换成另一种编码所需的条件， 以及同一个命令在多种不同编码上的实现方法。

3.3 字符串对象

字符串对象的编码可以是 int 、 raw 或者 embstr 。

如果一个字符串对象保存的是整数值， 并且这个整数值可以用 long 类型来表示， 那么字符串对象会将整数值保存在字符串对象结构的 ptr 属性里面（将 void* 转换成 long ）， 并将字符串对象的编码设置为 int 。

举个例子， 如果我们执行以下 SET 命令， 那么服务器将创建一个如图 8-1 所示的 int 编码的字符串对象作为 number 键的值：

redis> SET number 10086
OK

redis> OBJECT ENCODING number
"int"

如果字符串对象保存的是一个字符串值， 并且这个字符串值的长度大于 39 字节， 那么字符串对象将使用一个简单动态字符串（SDS）来保存这个字符串值， 并将对象的编码设置为 raw 。

举个例子， 如果我们执行以下命令， 那么服务器将创建一个如图 8-2 所示的 raw 编码的字符串对象作为 story 键的值：

redis> SET story "Long, long, long ago there lived a king ..."
OK

redis> STRLEN story
(integer) 43

redis> OBJECT ENCODING story
"raw"

如果字符串对象保存的是一个字符串值， 并且这个字符串值的长度小于等于 39 字节， 那么字符串对象将使用 embstr 编码的方式来保存这个字符串值。

embstr 编码是专门用于保存短字符串的一种优化编码方式， 这种编码和 raw 编码一样， 都使用 redisObject 结构和 sdshdr 结构来表示字符串对象， 但 raw 编码会调用两次内存分配函数来分别创建 redisObject 结构和 sdshdr 结构， 而 embstr 编码则通过调用一次内存分配函数来分配一块连续的空间， 空间中依次包含 redisObject 和 sdshdr 两个结构， 如图 8-3 所示。

embstr 编码的字符串对象在执行命令时， 产生的效果和 raw 编码的字符串对象执行命令时产生的效果是相同的， 但使用 embstr 编码的字符串对象来保存短字符串值有以下好处：

embstr 编码将创建字符串对象所需的内存分配次数从 raw 编码的两次降低为一次。
释放 embstr 编码的字符串对象只需要调用一次内存释放函数， 而释放 raw 编码的字符串对象需要调用两次内存释放函数。
因为 embstr 编码的字符串对象的所有数据都保存在一块连续的内存里面， 所以这种编码的字符串对象比起 raw 编码的字符串对象能够更好地利用缓存带来的优势。
作为例子， 以下命令创建了一个 embstr 编码的字符串对象作为 msg 键的值， 值对象的样子如图 8-4 所示：

redis> SET msg "hello"
OK

redis> OBJECT ENCODING msg
"embstr"

最后要说的是， 可以用 long double 类型表示的浮点数在 Redis 中也是作为字符串值来保存的： 如果我们要保存一个浮点数到字符串对象里面， 那么程序会先将这个浮点数转换成字符串值， 然后再保存起转换所得的字符串值。

举个例子， 执行以下代码将创建一个包含 3.14 的字符串表示 “3.14” 的字符串对象：

redis> SET pi 3.14
OK

redis> OBJECT ENCODING pi
"embstr"

在有需要的时候， 程序会将保存在字符串对象里面的字符串值转换回浮点数值， 执行某些操作， 然后再将执行操作所得的浮点数值转换回字符串值， 并继续保存在字符串对象里面。

举个例子， 如果我们执行以下代码的话：

redis> INCRBYFLOAT pi 2.0
"5.14"

redis> OBJECT ENCODING pi
"embstr"

那么程序首先会取出字符串对象里面保存的字符串值 “3.14” ， 将它转换回浮点数值 3.14 ， 然后把 3.14 和 2.0 相加得出的值 5.14 转换成字符串 “5.14” ， 并将这个 “5.14” 保存到字符串对象里面。

表 8-6 总结并列出了字符串对象保存各种不同类型的值所使用的编码方式。
表 8-6 字符串对象保存各类型值的编码方式

值编码
可以用 long 类型保存的整数。int
可以用 long double 类型保存的浮点数。embstr 或者 raw
字符串值， 或者因为长度太大而没办法用 long 类型表示的整数， 又或者因为长度太大而没办法用 long double 类型表示的浮点数。embstr 或者 raw

编码的转换
int 编码的字符串对象和 embstr 编码的字符串对象在条件满足的情况下， 会被转换为 raw 编码的字符串对象。

对于 int 编码的字符串对象来说， 如果我们向对象执行了一些命令， 使得这个对象保存的不再是整数值， 而是一个字符串值， 那么字符串对象的编码将从 int 变为 raw 。

在下面的示例中， 我们通过 APPEND 命令， 向一个保存整数值的字符串对象追加了一个字符串值， 因为追加操作只能对字符串值执行， 所以程序会先将之前保存的整数值 10086 转换为字符串值 “10086” ， 然后再执行追加操作， 操作的执行结果就是一个 raw 编码的、保存了字符串值的字符串对象：

redis> SET number 10086
OK

redis> OBJECT ENCODING number
"int"

redis> APPEND number " is a good number!"
(integer) 23

redis> GET number
"10086 is a good number!"

redis> OBJECT ENCODING number
"raw"

另外， 因为 Redis 没有为 embstr 编码的字符串对象编写任何相应的修改程序 （只有 int 编码的字符串对象和 raw 编码的字符串对象有这些程序）， 所以 embstr 编码的字符串对象实际上是只读的： 当我们对 embstr 编码的字符串对象执行任何修改命令时， 程序会先将对象的编码从 embstr 转换成 raw ， 然后再执行修改命令； 因为这个原因， embstr 编码的字符串对象在执行修改命令之后， 总会变成一个 raw 编码的字符串对象。

以下代码展示了一个 embstr 编码的字符串对象在执行 APPEND 命令之后， 对象的编码从 embstr 变为 raw 的例子：

redis> SET msg "hello world"
OK

redis> OBJECT ENCODING msg
"embstr"

redis> APPEND msg " again!"
(integer) 18

redis> OBJECT ENCODING msg
"raw"

3.4 列表对象

列表对象的编码可以是 ziplist 或者 linkedlist 。

ziplist 编码的列表对象使用压缩列表作为底层实现， 每个压缩列表节点（entry）保存了一个列表元素。

举个例子， 如果我们执行以下 RPUSH 命令， 那么服务器将创建一个列表对象作为 numbers 键的值：

redis> RPUSH numbers 1 "three" 5
(integer) 3

如果 numbers 键的值对象使用的是 ziplist 编码， 这个这个值对象将会是图 8-5 所展示的样子。

另一方面， linkedlist 编码的列表对象使用双端链表作为底层实现， 每个双端链表节点（node）都保存了一个字符串对象， 而每个字符串对象都保存了一个列表元素。

举个例子， 如果前面所说的 numbers 键创建的列表对象使用的不是 ziplist 编码， 而是 linkedlist 编码， 那么 numbers 键的值对象将是图 8-6 所示的样子。

注意， linkedlist 编码的列表对象在底层的双端链表结构中包含了多个字符串对象， 这种嵌套字符串对象的行为在稍后介绍的哈希对象、集合对象和有序集合对象中都会出现， 字符串对象是 Redis 五种类型的对象中唯一一种会被其他四种类型对象嵌套的对象。

为了简化字符串对象的表示， 我们在图 8-6 使用了一个带有 StringObject 字样的格子来表示一个字符串对象， 而 StringObject 字样下面的是字符串对象所保存的值。

比如说， 图 8-7 代表的就是一个包含了字符串值 “three” 的字符串对象， 它是 8-8 的简化表示。

编码转换
当列表对象可以同时满足以下两个条件时， 列表对象使用 ziplist 编码：

列表对象保存的所有字符串元素的长度都小于 64 字节；
列表对象保存的元素数量小于 512 个；
不能满足这两个条件的列表对象需要使用 linkedlist 编码。

注意
以上两个条件的上限值是可以修改的， 具体请看配置文件中关于 list-max-ziplist-value 选项和 list-max-ziplist-entries 选项的说明。

对于使用 ziplist 编码的列表对象来说， 当使用 ziplist 编码所需的两个条件的任意一个不能被满足时， 对象的编码转换操作就会被执行： 原本保存在压缩列表里的所有列表元素都会被转移并保存到双端链表里面， 对象的编码也会从 ziplist 变为 linkedlist 。

以下代码展示了列表对象因为保存了长度太大的元素而进行编码转换的情况：

# 所有元素的长度都小于 64 字节
redis> RPUSH blah "hello" "world" "again"
(integer) 3

redis> OBJECT ENCODING blah
"ziplist"

# 将一个 65 字节长的元素推入列表对象中
redis> RPUSH blah "wwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww"
(integer) 4

# 编码已改变
redis> OBJECT ENCODING blah
"linkedlist"

除此之外， 以下代码展示了列表对象因为保存的元素数量过多而进行编码转换的情况：

# 列表对象包含 512 个元素
redis> EVAL "for i=1,512 do redis.call('RPUSH', KEYS[1], i) end" 1 "integers"
(nil)

redis> LLEN integers
(integer) 512

redis> OBJECT ENCODING integers
"ziplist"

# 再向列表对象推入一个新元素，使得对象保存的元素数量达到 513 个
redis> RPUSH integers 513
(integer) 513

# 编码已改变
redis> OBJECT ENCODING integers
"linkedlist"

3.5 哈希对象

哈希对象的编码可以是 ziplist 或者 hashtable 。

ziplist 编码的哈希对象使用压缩列表作为底层实现， 每当有新的键值对要加入到哈希对象时， 程序会先将保存了键的压缩列表节点推入到压缩列表表尾， 然后再将保存了值的压缩列表节点推入到压缩列表表尾， 因此：

保存了同一键值对的两个节点总是紧挨在一起， 保存键的节点在前， 保存值的节点在后；
先添加到哈希对象中的键值对会被放在压缩列表的表头方向， 而后来添加到哈希对象中的键值对会被放在压缩列表的表尾方向。
举个例子， 如果我们执行以下 HSET 命令， 那么服务器将创建一个列表对象作为 profile 键的值：

redis> HSET profile name "Tom"
(integer) 1

redis> HSET profile age 25
(integer) 1

redis> HSET profile career "Programmer"
(integer) 1

如果 profile 键的值对象使用的是 ziplist 编码， 那么这个值对象将会是图 8-9 所示的样子， 其中对象所使用的压缩列表如图 8-10 所示。

另一方面， hashtable 编码的哈希对象使用字典作为底层实现， 哈希对象中的每个键值对都使用一个字典键值对来保存：

字典的每个键都是一个字符串对象， 对象中保存了键值对的键；
字典的每个值都是一个字符串对象， 对象中保存了键值对的值。
举个例子， 如果前面 profile 键创建的不是 ziplist 编码的哈希对象， 而是 hashtable 编码的哈希对象， 那么这个哈希对象应该会是图 8-11 所示的样子。

编码转换
当哈希对象可以同时满足以下两个条件时， 哈希对象使用 ziplist 编码：

哈希对象保存的所有键值对的键和值的字符串长度都小于 64 字节；
哈希对象保存的键值对数量小于 512 个；
不能满足这两个条件的哈希对象需要使用 hashtable 编码。

注意
这两个条件的上限值是可以修改的， 具体请看配置文件中关于 hash-max-ziplist-value 选项和 hash-max-ziplist-entries 选项的说明。

对于使用 ziplist 编码的列表对象来说， 当使用 ziplist 编码所需的两个条件的任意一个不能被满足时， 对象的编码转换操作就会被执行： 原本保存在压缩列表里的所有键值对都会被转移并保存到字典里面， 对象的编码也会从 ziplist 变为 hashtable 。

以下代码展示了哈希对象因为键值对的键长度太大而引起编码转换的情况：

# 哈希对象只包含一个键和值都不超过 64 个字节的键值对
redis> HSET book name "Mastering C++ in 21 days"
(integer) 1

redis> OBJECT ENCODING book
"ziplist"

# 向哈希对象添加一个新的键值对，键的长度为 66 字节
redis> HSET book long_long_long_long_long_long_long_long_long_long_long_description "content"
(integer) 1

# 编码已改变
redis> OBJECT ENCODING book
"hashtable"

除了键的长度太大会引起编码转换之外， 值的长度太大也会引起编码转换， 以下代码展示了这种情况的一个示例：

# 哈希对象只包含一个键和值都不超过 64 个字节的键值对
redis> HSET blah greeting "hello world"
(integer) 1

redis> OBJECT ENCODING blah
"ziplist"

# 向哈希对象添加一个新的键值对，值的长度为 68 字节
redis> HSET blah story "many string ... many string ... many string ... many string ... many"
(integer) 1

# 编码已改变
redis> OBJECT ENCODING b

最后， 以下代码展示了哈希对象因为包含的键值对数量过多而引起编码转换的情况：

# 创建一个包含 512 个键值对的哈希对象
redis> EVAL "for i=1, 512 do redis.call('HSET', KEYS[1], i, i) end" 1 "numbers"
(nil)

redis> HLEN numbers
(integer) 512

redis> OBJECT ENCODING numbers
"ziplist"

# 再向哈希对象添加一个新的键值对，使得键值对的数量变成 513 个
redis> HMSET numbers "key" "value"
OK

redis> HLEN numbers
(integer) 513

# 编码改变
redis> OBJECT ENCODING numbers
"hashtable"

3.6 集合对象

集合对象的编码可以是 intset 或者 hashtable 。

intset 编码的集合对象使用整数集合作为底层实现， 集合对象包含的所有元素都被保存在整数集合里面。

举个例子， 以下代码将创建一个如图 8-12 所示的 intset 编码集合对象：

redis> SADD numbers 1 3 5
(integer) 3

另一方面， hashtable 编码的集合对象使用字典作为底层实现， 字典的每个键都是一个字符串对象， 每个字符串对象包含了一个集合元素， 而字典的值则全部被设置为 NULL 。

举个例子， 以下代码将创建一个如图 8-13 所示的 hashtable 编码集合对象：

redis> SADD fruits "apple" "banana" "cherry"
(integer) 3

编码的转换
当集合对象可以同时满足以下两个条件时， 对象使用 intset 编码：

集合对象保存的所有元素都是整数值；
集合对象保存的元素数量不超过 512 个；
不能满足这两个条件的集合对象需要使用 hashtable 编码。

注意
第二个条件的上限值是可以修改的， 具体请看配置文件中关于 set-max-intset-entries 选项的说明。

对于使用 intset 编码的集合对象来说， 当使用 intset 编码所需的两个条件的任意一个不能被满足时， 对象的编码转换操作就会被执行： 原本保存在整数集合中的所有元素都会被转移并保存到字典里面， 并且对象的编码也会从 intset 变为 hashtable 。

举个例子， 以下代码创建了一个只包含整数元素的集合对象， 该对象的编码为 intset ：

redis> SADD numbers 1 3 5
(integer) 3

redis> OBJECT ENCODING numbers
"intset"

不过， 只要我们向这个只包含整数元素的集合对象添加一个字符串元素， 集合对象的编码转移操作就会被执行：

redis> SADD numbers "seven"
(integer) 1

redis> OBJECT ENCODING numbers
"hashtable"

除此之外， 如果我们创建一个包含 512 个整数元素的集合对象， 那么对象的编码应该会是 intset ：

redis> EVAL "for i=1, 512 do redis.call('SADD', KEYS[1], i) end" 1 integers
(nil)

redis> SCARD integers
(integer) 512

redis> OBJECT ENCODING integers
"intset"

但是， 只要我们再向集合添加一个新的整数元素， 使得这个集合的元素数量变成 513 ， 那么对象的编码转换操作就会被执行：

redis> SADD integers 10086
(integer) 1

redis> SCARD integers
(integer) 513

redis> OBJECT ENCODING integers
"hashtable"

3.7 有序集合对象

有序集合的编码可以是 ziplist 或者 skiplist 。

ziplist 编码的有序集合对象使用压缩列表作为底层实现， 每个集合元素使用两个紧挨在一起的压缩列表节点来保存， 第一个节点保存元素的成员（member）， 而第二个元素则保存元素的分值（score）。

压缩列表内的集合元素按分值从小到大进行排序， 分值较小的元素被放置在靠近表头的方向， 而分值较大的元素则被放置在靠近表尾的方向。

举个例子， 如果我们执行以下 ZADD 命令， 那么服务器将创建一个有序集合对象作为 price 键的值：

redis> ZADD price 8.5 apple 5.0 banana 6.0 cherry
(integer) 3

如果 price 键的值对象使用的是 ziplist 编码， 那么这个值对象将会是图 8-14 所示的样子， 而对象所使用的压缩列表则会是 8-15 所示的样子。

skiplist 编码的有序集合对象使用 zset 结构作为底层实现， 一个 zset 结构同时包含一个字典和一个跳跃表：

typedef struct zset {

    zskiplist *zsl;

    dict *dict;

} zset;

zset 结构中的 zsl 跳跃表按分值从小到大保存了所有集合元素， 每个跳跃表节点都保存了一个集合元素： 跳跃表节点的 object 属性保存了元素的成员， 而跳跃表节点的 score 属性则保存了元素的分值。 通过这个跳跃表， 程序可以对有序集合进行范围型操作， 比如 ZRANK 、 ZRANGE 等命令就是基于跳跃表 API 来实现的。

除此之外， zset 结构中的 dict 字典为有序集合创建了一个从成员到分值的映射， 字典中的每个键值对都保存了一个集合元素： 字典的键保存了元素的成员， 而字典的值则保存了元素的分值。 通过这个字典， 程序可以用 O(1) 复杂度查找给定成员的分值， ZSCORE 命令就是根据这一特性实现的， 而很多其他有序集合命令都在实现的内部用到了这一特性。

有序集合每个元素的成员都是一个字符串对象， 而每个元素的分值都是一个 double 类型的浮点数。 值得一提的是， 虽然 zset 结构同时使用跳跃表和字典来保存有序集合元素， 但这两种数据结构都会通过指针来共享相同元素的成员和分值， 所以同时使用跳跃表和字典来保存集合元素不会产生任何重复成员或者分值， 也不会因此而浪费额外的内存。

为什么有序集合需要同时使用跳跃表和字典来实现？
在理论上来说， 有序集合可以单独使用字典或者跳跃表的其中一种数据结构来实现， 但无论单独使用字典还是跳跃表， 在性能上对比起同时使用字典和跳跃表都会有所降低。
举个例子， 如果我们只使用字典来实现有序集合， 那么虽然以 O(1) 复杂度查找成员的分值这一特性会被保留， 但是， 因为字典以无序的方式来保存集合元素， 所以每次在执行范围型操作 —— 比如 ZRANK 、 ZRANGE 等命令时， 程序都需要对字典保存的所有元素进行排序， 完成这种排序需要至少 O(N log N) 时间复杂度， 以及额外的 O(N) 内存空间 （因为要创建一个数组来保存排序后的元素）。
另一方面， 如果我们只使用跳跃表来实现有序集合， 那么跳跃表执行范围型操作的所有优点都会被保留， 但因为没有了字典， 所以根据成员查找分值这一操作的复杂度将从 O(1) 上升为 O(log N) 。
因为以上原因， 为了让有序集合的查找和范围型操作都尽可能快地执行， Redis 选择了同时使用字典和跳跃表两种数据结构来实现有序集合。

举个例子， 如果前面 price 键创建的不是 ziplist 编码的有序集合对象， 而是 skiplist 编码的有序集合对象， 那么这个有序集合对象将会是图 8-16 所示的样子， 而对象所使用的 zset 结构将会是图 8-17 所示的样子。

注意
为了展示方便， 图 8-17 在字典和跳跃表中重复展示了各个元素的成员和分值， 但在实际中， 字典和跳跃表会共享元素的成员和分值， 所以并不会造成任何数据重复， 也不会因此而浪费任何内存。

编码的转换
当有序集合对象可以同时满足以下两个条件时， 对象使用 ziplist 编码：

有序集合保存的元素数量小于 128 个；
有序集合保存的所有元素成员的长度都小于 64 字节；
不能满足以上两个条件的有序集合对象将使用 skiplist 编码。

注意
以上两个条件的上限值是可以修改的， 具体请看配置文件中关于 zset-max-ziplist-entries 选项和 zset-max-ziplist-value 选项的说明。

对于使用 ziplist 编码的有序集合对象来说， 当使用 ziplist 编码所需的两个条件中的任意一个不能被满足时， 程序就会执行编码转换操作， 将原本储存在压缩列表里面的所有集合元素转移到 zset 结构里面， 并将对象的编码从 ziplist 改为 skiplist 。

以下代码展示了有序集合对象因为包含了过多元素而引发编码转换的情况：

# 对象包含了 128 个元素
redis> EVAL "for i=1, 128 do redis.call('ZADD', KEYS[1], i, i) end" 1 numbers
(nil)

redis> ZCARD numbers
(integer) 128

redis> OBJECT ENCODING numbers
"ziplist"

# 再添加一个新元素
redis> ZADD numbers 3.14 pi
(integer) 1

# 对象包含的元素数量变为 129 个
redis> ZCARD numbers
(integer) 129

# 编码已改变
redis> OBJECT ENCODING numbers
"skiplist"

以下代码则展示了有序集合对象因为元素的成员过长而引发编码转换的情况：

# 向有序集合添加一个成员只有三字节长的元素
redis> ZADD blah 1.0 www
(integer) 1

redis> OBJECT ENCODING blah
"ziplist"

# 向有序集合添加一个成员为 66 字节长的元素
redis> ZADD blah 2.0 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
(integer) 1

# 编码已改变
redis> OBJECT ENCODING blah
"skiplist"

3.8 类型检查与命令多态

Redis 中用于操作键的命令基本上可以分为两种类型。

其中一种命令可以对任何类型的键执行， 比如说 DEL 命令、 EXPIRE 命令、 RENAME 命令、 TYPE 命令、 OBJECT 命令， 等等。

举个例子， 以下代码就展示了使用 DEL 命令来删除三种不同类型的键：

# 字符串键
redis> SET msg "hello"
OK

# 列表键
redis> RPUSH numbers 1 2 3
(integer) 3

# 集合键
redis> SADD fruits apple banana cherry
(integer) 3

redis> DEL msg
(integer) 1

redis> DEL numbers
(integer) 1

redis> DEL fruits

而另一种命令只能对特定类型的键执行， 比如说：

SET 、 GET 、 APPEND 、 STRLEN 等命令只能对字符串键执行；
HDEL 、 HSET 、 HGET 、 HLEN 等命令只能对哈希键执行；
RPUSH 、 LPOP 、 LINSERT 、 LLEN 等命令只能对列表键执行；
SADD 、 SPOP 、 SINTER 、 SCARD 等命令只能对集合键执行；
ZADD 、 ZCARD 、 ZRANK 、 ZSCORE 等命令只能对有序集合键执行；
诸如此类。

举个例子， 我们可以用 SET 命令创建一个字符串键， 然后用 GET 命令和 APPEND 命令操作这个键， 但如果我们试图对这个字符串键执行只有列表键才能执行的 LLEN 命令， 那么 Redis 将向我们返回一个类型错误：

redis> SET msg "hello world"
OK

redis> GET msg
"hello world"

redis> APPEND msg " again!"
(integer) 18

redis> GET msg
"hello world again!"

redis> LLEN msg
(error) WRONGTYPE Operation against a key holding the wrong kind of 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命令从类型检查到根据编码选择实现函数的整个执行过程， 其他类型特定命令的执行过程也是类似的。

实际上， 我们可以将 DEL 、 EXPIRE 、 TYPE 等命令也称为多态命令， 因为无论输入的键是什么类型， 这些命令都可以正确地执行。

DEL 、 EXPIRE 等命令和 LLEN 等命令的区别在于， 前者是基于类型的多态 —— 一个命令可以同时用于处理多种不同类型的键， 而后者是基于编码的多态 —— 一个命令可以同时用于处理多种不同编码。

3.9 内存回收

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

每个对象的引用计数信息由redisObject结构的refcount属性记录：

typedef struct redisObject {

    // ...

    // 引用计数
    int refcount;

    // ...

} robj;

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

在创建一个新对象时， 引用计数的值会被初始化为 1 ；
当对象被一个新程序使用时， 它的引用计数值会被增一；
当对象不再被一个程序使用时， 它的引用计数值会被减一；
当对象的引用计数值变为 0 时， 对象所占用的内存会被释放。
表 8-12 列出了修改对象引用计数的 API ， 这些 API 分别用于增加、减少、重置对象的引用计数。

表 8-12 修改对象引用计数的 API

函数作用
incrRefCount将对象的引用计数值增一。
decrRefCount将对象的引用计数值减一， 当对象的引用计数值等于 0 时， 释放对象。
resetRefCount将对象的引用计数值设置为 0 ， 但并不释放对象， 这个函数通常在需要重新设置对象的引用计数值时使用。

对象的整个生命周期可以划分为创建对象、操作对象、释放对象三个阶段。

作为例子， 以下代码展示了一个字符串对象从创建到释放的整个过程：

// 创建一个字符串对象 s ，对象的引用计数为 1
robj *s = createStringObject(...)

// 对象 s 执行各种操作 ...

// 将对象 s 的引用计数减一，使得对象的引用计数变为 0
// 导致对象 s 被释放
decrRefCount(s)

其他不同类型的对象也会经历类似的过程。

3.10 对象共享

除了用于实现引用计数内存回收机制之外， 对象的引用计数属性还带有对象共享的作用。

举个例子， 假设键 A 创建了一个包含整数值 100 的字符串对象作为值对象， 如图 8-20 所示。

如果这时键 B 也要创建一个同样保存了整数值 100 的字符串对象作为值对象， 那么服务器有以下两种做法：

为键 B 新创建一个包含整数值 100 的字符串对象；
让键 A 和键 B 共享同一个字符串对象；
以上两种方法很明显是第二种方法更节约内存。

在 Redis 中， 让多个键共享同一个值对象需要执行以下两个步骤：

将数据库键的值指针指向一个现有的值对象；
将被共享的值对象的引用计数增一。
举个例子， 图 8-21 就展示了包含整数值 100 的字符串对象同时被键 A 和键 B 共享之后的样子， 可以看到， 除了对象的引用计数从之前的 1 变成了 2 之外， 其他属性都没有变化。

共享对象机制对于节约内存非常有帮助， 数据库中保存的相同值对象越多， 对象共享机制就能节约越多的内存。

比如说， 假设数据库中保存了整数值 100 的键不只有键 A 和键 B 两个， 而是有一百个， 那么服务器只需要用一个字符串对象的内存就可以保存原本需要使用一百个字符串对象的内存才能保存的数据。

目前来说， Redis 会在初始化服务器时， 创建一万个字符串对象， 这些对象包含了从 0 到 9999 的所有整数值， 当服务器需要用到值为 0 到 9999 的字符串对象时， 服务器就会使用这些共享对象， 而不是新创建对象。

注意
创建共享字符串对象的数量可以通过修改 redis.h/REDIS_SHARED_INTEGERS 常量来修改。

举个例子， 如果我们创建一个值为 100 的键 A ， 并使用 OBJECT REFCOUNT 命令查看键 A 的值对象的引用计数， 我们会发现值对象的引用计数为 2 ：

redis> SET A 100
OK

redis> OBJECT REFCOUNT A
(integer) 2

引用这个值对象的两个程序分别是持有这个值对象的服务器程序， 以及共享这个值对象的键 A ， 如图 8-22 所示。

如果这时我们再创建一个值为 100 的键 B ， 那么键 B 也会指向包含整数值 100 的共享对象， 使得共享对象的引用计数值变为 3 ：

redis> SET B 100
OK

redis> OBJECT REFCOUNT A
(integer) 3

redis> OBJECT REFCOUNT B
(integer) 3

图 8-23 展示了共享值对象的三个程序。

另外， 这些共享对象不单单只有字符串键可以使用， 那些在数据结构中嵌套了字符串对象的对象（linkedlist 编码的列表对象、 hashtable 编码的哈希对象、 hashtable 编码的集合对象、以及 zset 编码的有序集合对象）都可以使用这些共享对象。

为什么 Redis 不共享包含字符串的对象？

当服务器考虑将一个共享对象设置为键的值对象时， 程序需要先检查给定的共享对象和键想创建的目标对象是否完全相同， 只有在共享对象和目标对象完全相同的情况下， 程序才会将共享对象用作键的值对象， 而一个共享对象保存的值越复杂， 验证共享对象和目标对象是否相同所需的复杂度就会越高， 消耗的 CPU 时间也会越多：

如果共享对象是保存整数值的字符串对象， 那么验证操作的复杂度为 O(1) ；
如果共享对象是保存字符串值的字符串对象， 那么验证操作的复杂度为 O(N) ；
如果共享对象是包含了多个值（或者对象的）对象， 比如列表对象或者哈希对象， 那么验证操作的复杂度将会是 O(N^2) 。
因此， 尽管共享更复杂的对象可以节约更多的内存， 但受到 CPU 时间的限制， Redis 只对包含整数值的字符串对象进行共享。

3.11 对象的空转时长

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

typedef struct redisObject {

    // ...

    unsigned lru:22;

    // ...

} robj;

OBJECT IDLETIME 命令可以打印出给定键的空转时长， 这一空转时长就是通过将当前时间减去键的值对象的 lru 时间计算得出的：

redis> SET msg "hello world"
OK

# 等待一小段时间
redis> OBJECT IDLETIME msg
(integer) 20

# 等待一阵子
redis> OBJECT IDLETIME msg
(integer) 180

# 访问 msg 键的值
redis> GET msg
"hello world"

# 键处于活跃状态，空转时长为 0
redis> OBJECT IDLETIME msg
(integer) 0

注意
OBJECT IDLETIME 命令的实现是特殊的， 这个命令在访问键的值对象时， 不会修改值对象的 lru 属性。

除了可以被 OBJECT IDLETIME 命令打印出来之外， 键的空转时长还有另外一项作用： 如果服务器打开了 maxmemory 选项， 并且服务器用于回收内存的算法为 volatile-lru 或者 allkeys-lru ， 那么当服务器占用的内存数超过了 maxmemory 选项所设置的上限值时， 空转时长较高的那部分键会优先被服务器释放， 从而回收内存。

配置文件的 maxmemory 选项和 maxmemory-policy 选项的说明介绍了关于这方面的更多信息。

3.12 重点回顾

  1. Redis 数据库中的每个键值对的键和值都是一个对象。
  2. Redis 共有字符串、列表、哈希、集合、有序集合五种类型的对象， 每种类型的对象至少都有两种或以上的编码方式， 不同的编码可以在不同的使用场景上优化对象的使用效率。
  3. 服务器在执行某些命令之前， 会先检查给定键的类型能否执行指定的命令， 而检查一个键的类型就是检查键的值对象的类型。
  4. Redis 的对象系统带有引用计数实现的内存回收机制， 当一个对象不再被使用时， 该对象所占用的内存就会被自动释放。
  5. Redis 会共享值为 0 到 9999 的字符串对象。
  6. 对象会记录自己的最后一次被访问的时间， 这个时间可以用于计算对象的空转时间。

3.13 各数据类型最大存储量

根据Redis官方文档：https://redis.io/topics/data-types。

  1. StringsA
    String value can be at max 512 Megabytes in length.
  2. Lists
    The max length of a list is 2^32 - 1 elements (4294967295, more than 4 billion of elements per list).
  3. Sets
    The max number of members in a set is 2^32 - 1 (4294967295, more than 4 billion of members per set).
  4. Sorted sets
    Redis Sorted Sets are, similarly to Redis Sets, non repeating collections of Strings.
  5. Hashes
    Every hash can store up to 2^32 - 1 field-value pairs (more than 4 billion).

总结：String一个key、value最大512M，其它类型最多可以放无符号int类型的最大值个数。

四、Redis集群

Redis有三种集群模式，分别是主从模式、Sentinel模式和Cluster模式。

4.1 主从模式

主从模式是三种模式中最简单的，在主从复制中，数据库分为两类：主数据库(master)和从数据库(slave)。

4.1.1 特点
  1. 主数据库可以进行读写操作，当读写操作导致数据变化时会自动将数据同步给从数据库。
  2. 从数据库一般都是只读的，并且接收主数据库同步过来的数据。
  3. 一个master可以拥有多个slave，但是一个slave只能对应一个master。
  4. slave挂了不影响其他slave的读和master的读和写，重新启动后会将数据从master同步过来。
  5. master挂了以后，不影响slave的读，但redis不再提供写服务，master重启后redis将重新对外提供写服务。
  6. master挂了以后，不会在slave节点中重新选一个master。
4.1.2 工作机制
  1. 当slave启动后，主动向master发送SYNC命令。
  2. master接收到SYNC命令后在后台保存快照（RDB持久化）和缓存保存快照这段时间的命令，然后将保存的快照文件和缓存的命令发送给slave。
  3. slave接收到快照文件和命令后加载快照文件和缓存的执行命令。
  4. 复制初始化后，master每次接收到的写命令都会同步发送给slave，保证主从数据一致性。

4.2 Sentinel模式

主从模式的弊端就是不具备高可用性，当master挂掉以后，Redis将不能再对外提供写入操作，因此哨兵sentinel应运而生。

4.2.1特点
  1. sentinel模式是建立在主从模式的基础上，如果只有一个Redis节点，sentinel就没有任何意义。
  2. 当master挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master。
  3. 当master重新启动后，它将不再是master而是做为slave接收新的master的同步数据。
  4. sentinel因为也是一个进程有挂掉的可能，所以sentinel也会启动多个形成一个sentinel集群。
  5. 多sentinel配置的时候，sentinel之间也会自动监控。
  6. 当主从模式配置密码时，sentinel也会同步将配置信息修改到配置文件中，不需要担心。
  7. 一个sentinel或sentinel集群可以管理多个主从Redis，多个sentinel也可以监控同一个redis。
  8. sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也挂了。
4.2.2 工作机制
  1. 每个sentinel以每秒钟一次的频率向它所知的master，slave以及其他sentinel实例发送一个 PING 命令。
  2. 如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被sentinel标记为主观下线。
  3. 如果一个master被标记为主观下线，则正在监视这个master的所有sentinel要以每秒一次的频率确认master的确进入了主观下线状态。
  4. 当有足够数量的sentinel（大于等于配置文件指定的值）在指定的时间范围内确认master的确进入了主观下线状态， 则master会被标记为客观下线。
  5. 在一般情况下， 每个sentinel会以每 10 秒一次的频率向它已知的所有master，slave发送 INFO 命令。
  6. 当master被sentinel标记为客观下线时，sentinel向下线的master的所有slave发送 INFO 命令的频率会从 10 秒一次改为 1 秒一次。
  7. 若没有足够数量的sentinel同意master已经下线，master的客观下线状态就会被移除。
  8. 若master重新向sentinel的 PING 命令返回有效回复，master的主观下线状态就会被移除。

当使用sentinel模式的时候，客户端就不要直接连接Redis，而是连接sentinel的ip和port，由sentinel来提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，sentinel就会感知并将新的master节点提供给使用者。

4.3 Cluster模式

sentinel模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存放不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实例中。cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。

cluster可以说是sentinel和主从模式的结合体，通过cluster可以实现主从和master重选功能，所以如果配置两个副本三个分片的话，就需要六个Redis实例。因为Redis的数据是根据一定规则分配到cluster的不同机器的，当数据量过大时，可以新增机器进行扩容。

使用集群，只需要将redis配置文件中的cluster-enable配置打开即可。每个集群中至少需要三个主数据库才能正常运行，新增节点非常方便。

4.3.1 特点
  1. 多个redis节点网络互联，数据共享。
  2. 所有的节点都是一主一从（也可以是一主多从），其中从服务器不提供服务，仅作为备用。
  3. 不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为。
  4. 支持在线增加、删除节点。
  5. 客户端可以连接任何一个主节点进行读写。
4.3.2 工作机制
4.3.2.1 redis cluster的hash slot算法

redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot。
redis cluster中每个master都会持有部分slot，比如有3个master，那么可能每个master持有5000多个hash slot。
hash slot让node的增加和移除很简单，增加一个master，就将其他master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他master上去。

4.3.2.2 redis cluster多master的写入

在redis cluster写入数据的时候，其实是你可以将请求发送到任意一个master上去执行。
但是，每个master都会计算这个key对应的CRC16值，然后对16384个hashslot取模，找到key对应的hashslot，找到hashslot对应的master。
如果对应的master就在自己本地的话，set mykey1 v1，mykey1这个key对应的hashslot就在自己本地，那么自己就处理掉了。
但是如果计算出来的hashslot在其他master上，那么就会给客户端返回一个moved error，告诉你，你得到哪个master上去执行这条写入的命令。

4.3.2.3 gossip协议

gossip协议包含多种消息，包括ping，pong，meet，fail，等等。
meet: 某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信。
redis-trib.rb add-node其实内部就是发送了一个gossip meet消息，给新加入的节点，通知那个节点去加入我们的集群。
ping: 每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过ping交换元数据。
每个节点每秒都会频繁发送ping给其他的集群，ping，频繁的互相之间交换数据，互相进行元数据的更新。
pong: 返回ping和meet，包含自己的状态和其他信息，也可以用于信息广播和更新。
fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。

4.3.2.4 ping消息深入

ping很频繁，而且要携带一些元数据，所以可能会加重网络负担。
每个节点每秒会执行10次ping，每次会选择5个最久没有通信的其他节点。
当然如果发现某个节点通信延时达到了cluster_node_timeout / 2，那么立即发送ping，避免数据交换延时过长，落后的时间太长了。
比如说，两个节点之间都10分钟没有交换数据了，那么整个集群处于严重的元数据不一致的情况，就会有问题。
所以cluster_node_timeout可以调节，如果调节比较大，那么会降低发送的频率。
每次ping，一个是带上自己节点的信息，还有就是带上1/10其他节点的信息，发送出去，进行数据交换。
至少包含3个其他节点的信息，最多包含总节点-2个其他节点的信息

4.3.2.5 基于重定向的客户端
  1. 请求重定向
    客户端可能会挑选任意一个redis实例去发送命令，每个redis实例接收到命令，都会计算key对应的hash slot
    如果在本地就在本地处理，否则返回moved给客户端，让客户端进行重定向。
    cluster keyslot mykey，可以查看一个key对应的hash slot是什么。
    用redis-cli的时候，可以加入-c参数，支持自动的请求重定向，redis-cli接收到moved之后，会自动重定向到对应的节点执行命令。
  2. 计算hash slot
    计算hash slot的算法，就是根据key计算CRC16值，然后对16384取模，拿到对应的hash slot。
    用hash tag可以手动指定key对应的slot，同一个hash tag下的key，都会在一个hash slot中，比如set mykey1:{100}和set mykey2:{100}。
  3. hash slot查找
    节点间通过gossip协议进行数据交换，就知道每个hash slot在哪个节点上。
4.3.2.5 smart jedis
  1. 什么是smart jedis
    基于重定向的客户端，很消耗网络IO，因为大部分情况下，可能都会出现一次请求重定向，才能找到正确的节点。
    所以大部分的客户端，比如java redis客户端，就是jedis，都是smart的。
    本地维护一份hashslot -> node的映射表，缓存，大部分情况下，直接走本地缓存就可以找到hashslot -> node，不需要通过节点进行moved重定向。
  2. JedisCluster的工作原理
    在JedisCluster初始化的时候，就会随机选择一个node，初始化hashslot -> node映射表，同时为每个节点创建一个JedisPool连接池。
    每次基于JedisCluster执行操作，首先JedisCluster都会在本地计算key的hashslot，然后在本地映射表找到对应的节点。
    如果那个node正好还是持有那个hashslot，那么就ok; 如果说进行了reshard这样的操作，可能hashslot已经不在那个node上了，就会返回moved。
    如果JedisCluter API发现对应的节点返回moved，那么利用该节点的元数据，更新本地的hashslot -> node映射表缓存。
    重复上面几个步骤，直到找到对应的节点，如果重试超过5次，那么就报错，JedisClusterMaxRedirectionException。
    jedis老版本，可能会出现在集群某个节点故障还没完成自动切换恢复时，频繁更新hash slot，频繁ping节点检查活跃，导致大量网络IO开销。
    jedis最新版本，对于这些过度的hash slot更新和ping，都进行了优化，避免了类似问题。
  3. hashslot迁移和ask重定向
    如果hash slot正在迁移，那么会返回ask重定向给jedis。
    jedis接收到ask重定向之后，会重新定位到目标节点去执行，但是因为ask发生在hash slot迁移过程中，所以JedisCluster API收到ask是不会更新hashslot本地缓存。
    已经可以确定说，hashslot已经迁移完了，moved是会更新本地hashslot->node映射表缓存的。
4.3.2.6 高可用性与主备切换原理

redis cluster的高可用的原理，几乎跟哨兵是类似的

  1. 判断节点宕机
    如果一个节点认为另外一个节点宕机，那么就是pfail，主观宕机。
    如果多个节点都认为另外一个节点宕机了，那么就是fail，客观宕机，跟哨兵的原理几乎一样，sdown，odown。
    在cluster-node-timeout内，某个节点一直没有返回pong，那么就被认为pfail。
    如果一个节点认为某个节点pfail了，那么会在gossip ping消息中，ping给其他节点，如果超过半数的节点都认为pfail了，那么就会变成fail。
  2. 从节点过滤
    对宕机的master node，从其所有的slave node中，选择一个切换成master node。
    检查每个slave node与master node断开连接的时间，如果超过了cluster-node-timeout * cluster-slave-validity-factor，那么就没有资格切换成master。
    这个也是跟哨兵是一样的，从节点超时过滤的步骤。
  3. 从节点选举
    哨兵：对所有从节点进行排序，slave priority，offset，run id。
    每个从节点，都根据自己对master复制数据的offset，来设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举。
    所有的master node开始slave选举投票，给要进行选举的slave进行投票，如果大部分master node（N/2 + 1）都投票给了某个从节点，那么选举通过，那个从节点可以切换成master。
    从节点执行主备切换，从节点切换为主节点。
  4. 与哨兵比较
    整个流程跟哨兵相比，非常类似，所以说，redis cluster功能强大，直接集成了replication和sentinal的功能。

五、Redis持久化

持久化就是把内存的数据写到磁盘中去，防止服务器宕机了内存数据丢失。
redis 提供了两种持久化方式：RDB（默认）和AOF。

5.1 RDB持久化

5.1.1 RDB持久化触发方式

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。

5.1.1.1 RDB手动触发

手动触发分别对应save和bgsave命令：

  1. save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。
  2. bgsave命令：redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，时间很短。
5.1.1.2 RDB自动触发

redis内部还存在自动触发RDB的持久化机制，例如一下场景:

  1. 使用save相关配置，如‘save m n’表示m秒之内数据集存在n次修改时，自动触发bgsave。
  2. 如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点。
  3. 执行debug reload命令重新加载redis时，也会自动触发save操作。
  4. 默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave。
save 900 1           #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照
save 300 10          #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照
save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照
5.1.2 RDB的优点
  1. RDB是一个紧凑压缩的二进制文件，代表redis在某一个时间点上的数据快照。
  2. 非常适合用于备份，全量复制等场景。
  3. 比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。
  4. Redis加载RDB恢复数据远远快于AOF方式。
5.1.3 RDB的缺点
  1. RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
  2. RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB格式，存在老版本Redis服务无法兼容新版RDB格式的问题。
  3. 针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。

5.2 AOF持久化

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

5.2.1 使用AOF

开启AOF功能需要设置配置：appendonly yes，默认不开启。
AOF文件通过appendfilename配置设置，默认文件名是appendonly.aof。保存路径同RDB持久化方式一致。通过dir配置指定。
AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）,工作流程如下：

  1. 所有的写入命令会追加到aof_buf（缓冲区）中。
  2. AOF缓冲区根据对应的策略向硬盘做同步操作。
  3. 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
appendfsync always     #每次有数据修改发生时都会写入AOF文件
appendfsync everysec   #每秒钟同步一次，该策略为AOF的缺省策略
appendfsync no         #从不同步。高效但是数据不会被持久化
5.2.2 AOF重写

当AOF文件过大时会进行AOF重写。

  1. 多次写操作只保留最后一次写操作。
  2. 新建一个新的AOF文件，然后将所有的数据以写命令的形式写入新的AOF文件中，再替换掉原来的AOF文件。
5.2.3 AOF的优点

备份机制更加稳健，丢失数据概率更低。
备份文件可读性比RDB备份文件高，通过操作备份文件，可以处理一些误操作。

5.2.4 AOF的缺点

比起RDB占用更多的磁盘空间。
回复备份速度更慢。
每次读写都同步的话，有一定的性能压力。
存在个别BUG会造成不能恢复。

5.3 如何选择RDB和AOF

建议两种持久化方式一起打开，都打开时优先恢复AOF备份。
如果对数据不敏感，可以单独用RDB。
不建议单独使用AOF，因为可能出现不可恢复的BUG。
如果只做纯内存缓存，可以都不使用。

六、 缓存穿透、击穿、雪崩

6.1 缓存穿透

一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB）。一些恶意的请求会故意查询不存在的key,请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。

解决方案：

  1. 对查询结果为空的情况也进行缓存，缓存时间设置短一点每次查询时重新设置缓存时间，或者该key对应的数据insert了之后再清理缓存。
  2. 对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的bitmap中，查询时通过该bitmap过滤。

6.2 缓存击穿

缓存击穿，就是说某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库，就像是在一道屏障上凿开了一个洞。

解决方案：

  1. 将热点数据设置为永远不过期。
  2. 基于加锁或者队列、redis或zookeeper实现互斥锁，等待第一个请求构建完缓存之后，再释放锁，进而其它请求才能通过该 key 访问数据。

6.3 缓存雪崩

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，会给后端系统带来很大压力。导致系统崩溃。
解决方案：

  1. 设置热点数据永远不过期。
  2. 在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。
  3. 做二级缓存，A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。
  4. 不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

七、 Redis过期策略

7.1 设置过期时间

  • expire key time(以秒为单位)–这是最常用的方式
  • setex(String key, int seconds, String value)–字符串独有的方式

注意

  • 除了字符串自己独有设置过期时间的方法外，其他方法都需要依靠expire方法来设置时间
  • 如果没有设置时间，那缓存就是永不过期
  • 如果设置了过期时间，之后又想让缓存永不过期，使用persist key

7.2 三种过期策略

  • 定时删除
    • 含义：在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除
    • 优点：保证内存被尽快释放
    • 缺点：
      • 若过期key很多，删除这些key会占用很多的CPU时间，在CPU时间紧张的情况下，CPU不能把所有的时间用来做要紧的事儿，还需要去花时间删除这些key
      • 定时器的创建耗时，若为每一个设置过期时间的key创建一个定时器（将会有大量的定时器产生），性能影响严重
      • 没人用
  • 惰性删除
    • 含义：key过期的时候不删除，每次从数据库获取key的时候去检查是否过期，若过期，则删除，返回null。
    • 优点：删除操作只发生在从数据库取出key的时候发生，而且只删除当前key，所以对CPU时间的占用是比较少的，而且此时的删除是已经到了非做不可的地步（如果此时还不删除的话，我们就会获取到了已经过期的key了）
    • 缺点：若大量的key在超出超时时间后，很久一段时间内，都没有被获取过，那么可能发生内存泄露（无用的垃圾占用了大量的内存）
  • 定期删除
    • 含义：每隔一段时间执行一次删除过期key操作
    • 优点：
      • 通过限制删除操作的时长和频率，来减少删除操作对CPU时间的占用–处理"定时删除"的缺点
      • 定期删除过期key–处理"惰性删除"的缺点
    • 缺点
      • 在内存友好方面，不如"定时删除"
      • 在CPU时间友好方面，不如"惰性删除"
    • 难点
      • 合理设置删除操作的执行时长（每次删除执行多长时间）和执行频率（每隔多长时间做一次删除）（这个要根据服务器运行情况来定了）

注意

  • 上边所说的数据库指的是内存数据库，默认情况下每一台redis服务器有16个数据库（关于数据库的设置，看下边代码），默认使用0号数据库，所有的操作都是对0号数据库的操作

  • memcached只是用了惰性删除，而redis同时使用了惰性删除与定期删除，这也是二者的一个不同点（可以看做是redis优于memcached的一点）

  • 对于惰性删除而言，并不是只有获取key的时候才会检查key是否过期，在某些设置key的方法上也会检查（eg.setnx key2 value2：该方法类似于memcached的add方法，如果设置的key2已经存在，那么该方法返回false，什么都不做；如果设置的key2不存在，那么该方法设置缓存key2-value2。假设调用此方法的时候，发现redis中已经存在了key2，但是该key2已经过期了，如果此时不执行删除操作的话，setnx方法将会直接返回false，也就是说此时并没有重新设置key2-value2成功，所以对于一定要在setnx执行之前，对key2进行过期检查）

7.3 Redis采用的过期策略

惰性删除+定期删除

  • 惰性删除流程
    • 在进行get或setnx等操作时，先检查key是否过期，
    • 若过期，删除key，然后执行相应操作；
    • 若没过期，直接执行相应操作
  • 定期删除流程（简单而言，对指定个数个库的每一个库随机删除小于等于指定个数个过期key）
    • 遍历每个数据库（就是redis.conf中配置的"database"数量，默认为16）
      • 检查当前库中的指定个数个key（默认是每个库检查20个key，注意相当于该循环执行20次，循环体时下边的描述）
        • 如果当前库中没有一个key设置了过期时间，直接执行下一个库的遍历
        • 随机获取一个设置了过期时间的key，检查该key是否过期，如果过期，删除key
        • 判断定期删除操作是否已经达到指定时长，若已经达到，直接退出定期删除。

注意：

  • 对于定期删除，在程序中有一个全局变量current_db来记录下一个将要遍历的库，假设有16个库，我们这一次定期删除遍历了10个，那此时的current_db就是11，下一次定期删除就从第11个库开始遍历，假设current_db等于15了，那么之后遍历就再从0号库开始（此时current_db==0）
  • 由于在实际中并没有操作过定期删除的时长和频率，所以这两个值的设置方式作为疑问？

7.4 RDB对过期key的处理

过期key对RDB没有任何影响

  • 从内存数据库持久化数据到RDB文件
    • 持久化key之前，会检查是否过期，过期的key不进入RDB文件
  • 从RDB文件恢复数据到内存数据库
    • 数据载入数据库之前，会对key先进行过期检查，如果过期，不导入数据库（主库情况）

7.5 AOF对过期key的处理

过期key对AOF没有任何影响

  • 从内存数据库持久化数据到AOF文件：
    • 当key过期后，还没有被删除，此时进行执行持久化操作（该key是不会进入aof文件的，因为没有发生修改命令）
    • 当key过期后，在发生删除操作时，程序会向aof文件追加一条del命令（在将来的以aof文件恢复数据的时候该过期的键就会被删掉）
  • AOF重写
    • 重写时，会先判断key是否过期，已过期的key不会重写到aof文件

八、 Redis应用示例

8.1 bitmap

8.1.1 bitmap概念

bitmap即位图，其实也就是 byte 数组，用二进制表示，只有 0 和 1 两个数字。
通过一个bit位来表示某个元素对应的值或者状态,其中的key就是对应元素本身。我们知道8个bit可以组成一个Byte，所以bitmap本身会极大的节省储存空间。

8.1.2 bitmap API
命令含义
getbit key offset对key所存储的字符串值，获取指定偏移量上的位（bit）
setbit key offset value对key所存储的字符串值，设置或清除指定偏移量上的位（bit）
1. 返回值为该位在setbit之前的值
2. value只能取0或1
3. offset从0开始，即使原位图只能10位，offset可以取1000
bitcount key [start end]获取位图指定范围中位值为1的个数
如果不指定start与end，则取所有
bitop op destKey key1 [key2…]做多个BitMap的and（交集）、or（并集）、not（非）、xor（异或）操作并将结果保存在destKey中
bitpos key tartgetBit [start end]计算位图指定范围第一个偏移量对应的的值等于targetBit的位置
1. 找不到返回-1
2. start与end没有设置，则取全部
3. targetBit只能取0或者1

例子：
id 是主键，所以是聚簇索引，其叶子节点存储的是对应行记录的数据

8.1.3 bitmap长度限制

bitmap底层还是字符串，Redis的键、值最大都支持512M。
计算位长度：512*1024*1024*8=4,294,967,296,即2^32，无符号int类型最大值+1。

8.1.4 bitmap应用举例

比如统计每天的登录人数。

redis> setbit 20200409 15 1 #将uid为15的用户在20200409这一天的登录设为1，表示登录过
(integer) 0

redis> setbit 20200409 16 1 #将uid为16的用户在20200409这一天的登录设为1，表示登录过
(integer) 0

redis> bitcount key 20200409 #统计20200409这一天多少人登录过
(integer) 2

8.2 ZSet实现排行榜

8.2.1 ZSet有序集合

redis的有序集合与集合一样也是String类型元素的集合，不允许有重复的元素。
每一个元素都会关联一个double类型的分数，redis正是通过分数来为集合中的成员进行从小到大的排序。
有序集合中的成员是唯一的，但是分数可以重复。
集合是通过哈希表实现的，集合中的最大元素是2的32次方减1。Zset是有序且不重复的。

注意：默认排序从小到大。

ZSet命令

  1. 赋值
127.0.0.1:6379> zadd rank 90 c++ 80 java 70 php 60 lua
(integer) 4
# 创建了一个key（名字）为rank的排行版。
  1. 修改分数
127.0.0.1:6379> zincrby rank 10 c++
"10"
  1. 通过索引区间返回指定区间内的成员
127.0.0.1:6379> zrange rank 0 -1
1) "lua"
2) "php"
3) "java"
4) "c++"
127.0.0.1:6379> zrange rank 0 1
1) "lua"
2) "php"
  1. 通过索引区间返回指定区间内的成员及分数
127.0.0.1:6379> zrange rank 0 -1 withscores
1) "lua"
2) "60"
3) "php"
4) "70"
5) "java"
6) "80"
7) "c++"
8) "90"
  1. 从大到小查询
127.0.0.1:6379> zrevrange rank 0 1 withscores
1) "c++"
2) "90"
3) "java"
4) "80"
  1. 获取成员数量
127.0.0.1:6379> zcard rank
(integer) 4
  1. 计算指定区间分数的成员数
127.0.0.1:6379> zcount rank 80 90
(integer) 2

注意这个最小分数和最大分数都是闭区间。

  1. 返回指定成员的索引（排名）
127.0.0.1:6379> zrank rank c++
(integer) 3
127.0.0.1:6379> zrevrank rank c++
(integer) 0

zrank是从小到大的排名，zrevrank 是从大到小的。

  1. 返回指定分数区间的成员
127.0.0.1:6379> zrangebyscore rank 80 90
1) "java"
2) "c++"
127.0.0.1:6379> zrevrangebyscore rank 90 80 withscores
1) "c++"
2) "90"
3) "java"
4) "80"

zrangebyscore的参数是最低分最高分，zrevrangebyscore 的参数是最高分最低分，同样是闭区间。

  1. 移除指定域成员
127.0.0.1:6379> zrem rank lua
(integer) 1
127.0.0.1:6379> zrange rank 0 -1
1) "php"
2) "java"
3) "c++"
  1. 移除给定的排名区间的所有成员
127.0.0.1:6379> zremrangebyrank rank 0 1
(integer) 2
127.0.0.1:6379> zrange rank 0 -1
1) "c++"
  1. 移除给定分数区间的所有成员
127.0.0.1:6379> zremrangebyscore rank 80 85
(integer) 0
  1. 移除整个集合排行榜
127.0.0.1:6379> del rank
(integer) 1
127.0.0.1:6379> exists rank
(integer) 0
8.2.2 ZSet最大分数

ZSet使用double存储分数，在IEEE754浮点数标准中表示的最大整数与该类型可以表示的最大值相同，因为该值本身是整数。
大约是1.79*10^308。

但是，我们需要注意的是，由于浮点类型精度问题，我们最好使用不超过16位的分数，这样不会产生精度问题。

8.2.3 ZSet如何处理分数相同

当score相同时，ZSet会按照插入的field的字典序排序，即abc比acd靠前，因为第一个字母都是a，但是b比c靠前。

其次是采用实际分数和时间戳相组合结合成的最终分数作为存入ZSet的分数。
年月日时分秒xx(2x年)xx(月)xx(日)xx(时)xx(分)xx(秒)，这里需要10个十进制位，如果还精确到毫秒，那么需要13个十进制位。

有个小问题就是分数是越大排名越靠前，但是时间戳得越小排名越靠前，可以采用“实际分数*10^13+13个9-13位时间戳”作为分数。

还有个知识点是如果用有符号int存储秒级时间戳，int最大是2^31-1=2147483647，可以用到2038-01-19 11:14:07。

8.3 Hash存储对象

哈希表是一种数据结构，而Redis Hash也是采用哈希表来实现的存储。

8.3.1 Hash命令
  1. 赋值(hset key filed value)
127.0.0.1:6379> hset uid name zhonglimo
(integer) 1
127.0.0.1:6379> hsetnx uid name zhonglimo
(integer) 0

hset不存在则创建，存在则修改。
hsetnx不存在则创建，存在则返回0。

  1. 批量赋值
127.0.0.1:6379> hmset uid name zhonglimo age 24
OK
  1. 获取值
127.0.0.1:6379> hget uid name
"zhonglimo"
127.0.0.1:6379> hmget uid name age
1) "zhonglimo"
2) "24"
127.0.0.1:6379> hgetall uid
1) "name"
2) "zhonglimo"
3) "age"
4) "24"

hiredis中Redis执行命令的返回值结构体为redisReply ，如果成功的是一个数组，比如上述hgetgall返回了4个值，则返回的redisReply中elements为4代表长度为4，element则为这4个返回值地址数组首地址。

typedef struct redisReply {  
    int type; /* REDIS_REPLY_* */  
    long long integer; /* The integer when type is REDIS_REPLY_INTEGER */  
    int len; /* Length of string */  
    char *str; /* Used for both REDIS_REPLY_ERROR and REDIS_REPLY_STRING */  
    size_t elements; /* number of elements, for REDIS_REPLY_ARRAY */  
    struct redisReply **element; /* elements vector for REDIS_REPLY_ARRAY */  
} redisReply;
  1. 获取key对应的域值对个数
127.0.0.1:6379> hlen uid
(integer) 2
  1. 获取key对应的所有的域
127.0.0.1:6379> hkeys uid
1) "name"
2) "age"
  1. 获取key对应的所有的值
1) "name"
2) "age"
127.0.0.1:6379> hvals uid
1) "zhonglimo"
2) "24"
  1. 判断key中是否存在某域
127.0.0.1:6379> hexists uid name
(integer) 1
  1. 删除key中某域
127.0.0.1:6379> hdel uid age
(integer) 1
127.0.0.1:6379> hgetall uid
1) "name"
2) "zhonglimo"

Hash不支持直接设置过期时间，可以在设置好值域之后，再使用EXPIRE key seconds或者PEXPIRE key milliseconds来设置过期时间，使用PERSIST key移除过期时间。

8.3.2 Hash存储对象结构
127.0.0.1:6379> hmset 20201010 name zhonglimo age 24 sex man
OK
127.0.0.1:6379> hgetall 20201010
1) "name"
2) "zhonglimo"
3) "age"
4) "24"
5) "sex"
6) "man"

8.4 Redis事务

由于Redis事务功能比较弱，所以没有单独成节，这里简单介绍一下。
MULTI、EXEC、DISCARD和WATCH命令是Redis事务功能的基础。Redis事务允许在一次单独的步骤中执行一组命令，并且可以保证如下两个重要事项：

  1. Redis会将一个事务中的所有命令序列化，然后按顺序执行。Redis不可能在一个Redis事务的执行过程中插入执行另一个客户端发出的请求。这样便能保证Redis将这些命令作为一个单独的隔离操作执行。
  2. 在一个Redis事务中，Redis要么执行其中的所有命令，要么什么都不执行。因此，Redis事务能够保证原子性。EXEC命令会触发执行事务中的所有命令。因此，当某个客户端正在执行一次事务时，如果它在调用MULTI命令之前就从Redis服务端断开连接，那么就不会执行事务中的任何操作；相反，如果它在调用EXEC命令之后才从Redis服务端断开连接，那么就会执行事务中的所有操作。
8.4.1 事务命令
  1. MULTI
    用于标记事务块的开始。Redis会将后续的命令逐个放入队列中，然后才能使用EXEC命令原子化地执行这个命令序列。
    这个命令的返回值是一个简单的字符串，总是OK。
  2. EXEC
    在一个事务中执行所有先前放入队列的命令，然后恢复正常的连接状态。
    当使用WATCH命令时，只有当受监控的键没有被修改时，EXEC命令才会执行事务中的命令，这种方式利用了检查再设置（CAS）的机制。
  3. DISCARD
    清除所有先前在一个事务中放入队列的命令，然后恢复正常的连接状态。
    如果使用了WATCH命令，那么DISCARD命令就会将当前连接监控的所有键取消监控。
  4. WATCH
    当某个事务需要按条件执行时，就要使用这个命令将给定的键设置为受监控的，可以同时监视多个键WATCH key1 key2。
    如果在提交EXEC时所监控的键被非本客户端修改了，则不会执行任何命令。
  5. UNWATCH
    清除所有先前为一个事务监控的键。
    如果你调用了EXEC或DISCARD命令，那么就不需要手动调用UNWATCH命令,，可以同时取消监视多个键UNWATCH key1 key2。
8.4.2 事务示例

使用MULTI命令便可以进入一个Redis事务。这个命令的返回值总是OK。此时，用户可以发出多个Redis命令。Redis会将这些命令放入队列，而不是执行这些命令。一旦调用EXEC命令，那么Redis就会执行事务中的所有命令。
相反，调用DISCARD命令将会清除事务队列，然后退出事务。

以下示例会原子化地递增foo键和bar键的值：

九、 Redis慢查询日志

关于 Redis 慢查询的配置有两个，分别是 slowlog-log-slower-than 和 slowlog-max-len。

  1. slowlog-log-slower-than
    用来控制慢查询的阈值，所有执行时间超过该值的命令都会被记录下来。该值的单位为微秒，默认值为 10000，如果设置为 0，那么所有的记录都会被记录下来，如果设置为小于 0 的值，那么对于任何命令都不会记录，即关闭了慢查询。可以通过在配置文件中设置，或者用 config set 命令来设置：
config set slowlog-log-slower-than 10000
  1. slowlog-max-len
    用来设置存储慢查询记录列表的大小，默认值为 128，当该列表满了时，如果有新的记录进来，那么 Redis 会把队最旧的记录清理掉，然后存储新的记录。在生产环境我们可以适当调大，比如调成 1000，这样就可以缓冲更多的记录，方便故障的排查。配置方法和 slowlog-log-slower-than 类似，可以在配置文件中指定，也可以在命令行执行 config set 来设置：
config set slowlog-max-len 1000

尽管 Redis 把慢查询日志记录到了内部的列表，但我们不能直接操作该列表，Redis 专门提供了一组命令来查询慢查询日志：

  1. slowlog get [n] 获取慢查询日志：
    下面操作返回当前 Redis 的所有慢查询记录，可以通过参数 n 指定查看条数：
127.0.0.1:6379> slowlog get
 1) 1) (integer) 456
    2) (integer) 1531632044
    3) (integer) 3
    4) 1) "get"
       2) "m"
    5) "127.0.0.1:50106"
    6) ""
 2) 1) (integer) 455
    2) (integer) 1531632037
    3) (integer) 14
    4) 1) "keys"
       2) "*"
    5) "127.0.0.1:50106"
    6) ""

结果说明：

  1. 慢查询记录 id；
  2. 发起命令的时间戳；
  3. 命令耗时，单位为微秒；
  4. 该条记录的命令及参数；
  5. 客户端网络套接字（ip: port）;
  6. “”
  1. slowlog len 获取当前慢查询日志记录数
127.0.0.1:6379> slowlog len
(integer) 458
  1. slowlog reset慢查询日志重置
    实际上是对慢查询列表做清理操作：
127.0.0.1:6379> slowlog len
(integer) 461
127.0.0.1:6379> slowlog reset
OK
127.0.0.1:6379> slowlog len
(integer) 1

十、 其它

10.1 MongoDB

10.1.1 MongoDB简介

MongoDB是一款NoSQL数据库，与Redis一样都是非关系型数据库，NoSQL即表之间的各个数据之间互相独立，没有限定的表结构，可以完全拥有各自的结构。
MongoDB是由C++语言编写的，是一个基于分布式文件存储的开源数据库系统。
在高负载的情况下，添加更多的节点，可以保证服务器性能。
MongoDB 旨在为WEB应用提供可扩展的高性能数据存储解决方案。

MongoDB 将数据存储为一个文档，数据结构由键值(key=>value)对组成。MongoDB 文档类似于 JSON 对象。字段值可以包含其他文档，数组及文档数组。

10.1.2 MongoDB与关系型数据库的区别

比如：mysql的表tables，MongoDB这里叫集合collections，集合里面的每一条数据叫做文件(document)。

插入的不同数据拥有完全不用的键值对，这在关系型数据库中是做不到的。

10.1.3 一些基础操作指令
  1. 插入指令
> db.student.insert({"name":"xuye","school":"hafo","numbe":141420014}) 
  #插入一条文档，我并没有创建集合student，直接写插入语句，如果表不存在会自动创建（一般都是使用此方式来建表，而不是去用createColletion()创建表，此方式的容量会自动增长。）
 
> db.student.insert({"class":101,"number":1401420,"teach":"xuye"})
#在插入一条文档，可以发现，两条文档之间的格式要求是没有任何关系的，甚至你可以随便插入不是关于学生此类的信息都可以，但是一般一个表只插入一类信息的文档（约定成俗的）。
 
> db.student.find()      #查看该集合中所有的文档。
{ "_id" : ObjectId("5b7d1aa979c725e3580ed2db") }
{ "_id" : ObjectId("5b7d1b1d79c725e3580ed2dc"), "name" : "xuye", "school" : "hafo", "numbe" : 141420014 }
{ "_id" : ObjectId("5b7d1c57c8ff91d6ecaf79d8"), "class" : 101, "number" : 1401420, "teach" : "xuye" }
#此处还需要注意，我们并没有插入_id这个东西，这是mongodb自动帮我们生成的一个id，是唯一的，所以也就不需要我们去生成id了。
 
> db.student.find().pretty()
{ "_id" : ObjectId("5b7d1aa979c725e3580ed2db") }
{
        "_id" : ObjectId("5b7d1b1d79c725e3580ed2dc"),
        "name" : "xuye",
        "school" : "hafo",
        "numbe" : 141420014
} #格式化显示查询的语句，应该还有几条，我只取了其中一条粘贴在这里，就类似代码的格式化，好看一些。
 
> db.student.insert({"name":"xuye","number":140246,"deskmate":{"name":"xiaobai","number":140265}})
#插入一条复杂一些的文档，可以嵌套，和json一样，只要符合键值对的形式都可以使用。如果多个嵌套的话，要使用中括号，如下。
 db.student.insert({"name":"xuye","number":140246,"deskmate":[{"name":"xiaobai","number":140265},
  1. 分页查询
> db.books.insert({"name":"spring","price":20.01})
> db.books.insert({"name":"springMvc","price":19.99})
> db.books.insert({"name":"java","price":67.84})
> db.books.insert({"name":"linux","price":289.78})
> db.books.insert({"name":"python","price":29.78})
> db.books.insert({"name":"c++","price":157.68})
#先插入一些数据，书名和书的价格。
 
> db.books.find()
{ "_id" : ObjectId("5b7d4a588e6123a7a302be25"), "name" : "spring", "price" : 20.01 }
{ "_id" : ObjectId("5b7d4a6b8e6123a7a302be27"), "name" : "springMvc", "price" : 19.99 }
{ "_id" : ObjectId("5b7d4a7f8e6123a7a302be28"), "name" : "java", "price" : 67.84 }
{ "_id" : ObjectId("5b7d4a898e6123a7a302be29"), "name" : "linux", "price" : 289.78 }
{ "_id" : ObjectId("5b7d4a9f8e6123a7a302be2a"), "name" : "python", "price" : 29.78 }
{ "_id" : ObjectId("5b7d4aad8e6123a7a302be2b"), "name" : "c++", "price" : 157.68 }
#查看数据，下面进行分页。
 
> db.books.find().skip(0).limit(3)
{ "_id" : ObjectId("5b7d4a588e6123a7a302be25"), "name" : "spring", "price" : 20.01 }
{ "_id" : ObjectId("5b7d4a6b8e6123a7a302be27"), "name" : "springMvc", "price" : 19.99 }
{ "_id" : ObjectId("5b7d4a7f8e6123a7a302be28"), "name" : "java", "price" : 67.84 }
#分页查询，表示查到的数据，从第一条开始，显示3条。类似SQL的limit 0,3。也可以记为，跳过0条，显示3条。
 
> db.books.find().limit(3).skip(0)
{ "_id" : ObjectId("5b7d4a588e6123a7a302be25"), "name" : "spring", "price" : 20.01 }
{ "_id" : ObjectId("5b7d4a6b8e6123a7a302be27"), "name" : "springMvc", "price" : 19.99 }
{ "_id" : ObjectId("5b7d4a7f8e6123a7a302be28"), "name" : "java", "price" : 67.84 }
#limit和skip两个函数可以更换位置，结果都一样。
 
> db.books.find().limit(3)  #等同于db.books.find().skip(0).limit(3)
 
> db.books.find().skip(5)    #跳过前5条，显示第六条以后的所有文档。
  1. 带条件的查询（and、or、gt、lt、正则、去重、排序等查询）
> db.books.find({"name":"spring"})
{ "_id" : ObjectId("5b7d4a588e6123a7a302be25"), "name" : "spring", "price" : 20.01 }
#查询name为spring的书籍，在find函数的里面加上json格式的条件即可。
 
> db.books.find({"name":"spring","price":20.01})
{ "_id" : ObjectId("5b7d4a588e6123a7a302be25"), "name" : "spring", "price" : 20.01 }
#多条件查询，使用逗号分隔即可，类似select * form books where name="spring" and price=20.01
 
> db.books.find({$or:[{"name":"spring"},{"name":"java"}]})
{ "_id" : ObjectId("5b7d4a588e6123a7a302be25"), "name" : "spring", "price" : 20.01 }
{ "_id" : ObjectId("5b7d4a7f8e6123a7a302be28"), "name" : "java", "price" : 67.84 }
#查询nam为spring或者java的书籍，格式为find({$or : [{},{}]}) 中括号里面填写每一个json格式的条件，类似select * form books where name="spring" or name="java"
 
> db.books.find({"price":{$gte : 100}})
{ "_id" : ObjectId("5b7d4a898e6123a7a302be29"), "name" : "linux", "price" : 289.78 }
{ "_id" : ObjectId("5b7d4aad8e6123a7a302be2b"), "name" : "c++", "price" : 157.68 }
#查询价格大于等于100的书籍。
 
> db.books.find({"price":{$lte : 20}})
{ "_id" : ObjectId("5b7d4a6b8e6123a7a302be27"), "name" : "springMvc", "price" : 19.99 }
#查询价格小于等于20的书籍。
 
> db.books.find({"price":{$gte:100,$lte:200}})
{ "_id" : ObjectId("5b7d4aad8e6123a7a302be2b"), "name" : "c++", "price" : 157.68 }
#查询价格大于等于100并且小于等于200的书籍。
 
> db.books.find({$or:[{"price":{$gt:200}},{"price":{$lt:20}}]})
{ "_id" : ObjectId("5b7d4a6b8e6123a7a302be27"), "name" : "springMvc", "price" : 19.99 }
{ "_id" : ObjectId("5b7d4a898e6123a7a302be29"), "name" : "linux", "price" : 289.78 }
#查询价格大于200或者价格小于20的书籍，or的操作有点另类，一定要写在一开始的key上。
 
#注意：gt为大于，gte为大于等于,lt为小于，lte为小于等于，e为equals。

因为带提交查询的指令内容太多，上面这一部分主要是大于和小于，and和or的指令。下面是去重，正则的条件查询。

> db.books.insert({"name":"spring","price":22.05})
#先插入一条name同为spring的文档
 
> db.books.distinct("name")
[ "spring", "springMvc", "java", "linux", "python", "c++" ]
#根据name去重，类似select distinct name from books
 
> db.books.distinct("name",{"price":{$lt:30}})
[ "spring", "springMvc", "python" ]
#查询出价格小于30的书籍，然后根据name去重，类似select distinct name from books where price<30
distinct命令和find类似，只不过多了一个去重功能。
 
> db.books.find({"name":/spring/})
{ "_id" : ObjectId("5b7d4a588e6123a7a302be25"), "name" : "spring", "price" : 20.01 }
{ "_id" : ObjectId("5b7d4a6b8e6123a7a302be27"), "name" : "springMvc", "price" : 19.99 }
{ "_id" : ObjectId("5b7d58deabdfa1fbe797fa0b"), "name" : "spring", "price" : 22.05 }
#使用正则表达式查询，/等同于%，类似select *from books where name like %spring%
 
> db.books.find({"name":/spring/}).skip(1).limit(2)
{ "_id" : ObjectId("5b7d4a6b8e6123a7a302be27"), "name" : "springMvc", "price" : 19.99 }
{ "_id" : ObjectId("5b7d58deabdfa1fbe797fa0b"), "name" : "spring", "price" : 22.05 }
#搜索后的分页查询，在搜索栏输入内容后的查询功能，类似select *from books where name like %spring% limit 1,2。正则表达式内容较多，具体可自己网上查询。
 
> db.books.find({},{"price":1})
{ "_id" : ObjectId("5b7d4a588e6123a7a302be25"), "price" : 20.01 }
{ "_id" : ObjectId("5b7d4a6b8e6123a7a302be27"), "price" : 19.99 }
{ "_id" : ObjectId("5b7d4a7f8e6123a7a302be28"), "price" : 67.84 }
{ "_id" : ObjectId("5b7d4a898e6123a7a302be29"), "price" : 289.78 }
{ "_id" : ObjectId("5b7d4a9f8e6123a7a302be2a"), "price" : 29.78 }
{ "_id" : ObjectId("5b7d4aad8e6123a7a302be2b"), "price" : 157.68 }
{ "_id" : ObjectId("5b7d58deabdfa1fbe797fa0b"), "price" : 22.05 }
#只显示price列，格式find({},{key1:1,key2:1})，第一个{}表示查询的条件，第二个为显示的列信息，多个用逗号隔开，类似select price from books，但是_id它是必须显示的。
 
> db.books.find({},{"price":1}).sort({"price":1})
{ "_id" : ObjectId("5b7d4a6b8e6123a7a302be27"), "price" : 19.99 }
{ "_id" : ObjectId("5b7d4a588e6123a7a302be25"), "price" : 20.01 }
{ "_id" : ObjectId("5b7d58deabdfa1fbe797fa0b"), "price" : 22.05 }
{ "_id" : ObjectId("5b7d4a9f8e6123a7a302be2a"), "price" : 29.78 }
{ "_id" : ObjectId("5b7d4a7f8e6123a7a302be28"), "price" : 67.84 }
{ "_id" : ObjectId("5b7d4aad8e6123a7a302be2b"), "price" : 157.68 }
{ "_id" : ObjectId("5b7d4a898e6123a7a302be29"), "price" : 289.78 }
#查询后只显示price列，并且按照价格升序，类似select price from books order by price 
 
> db.books.find({},{"price":1}).sort({"price":-1})
#与上面相反，按价格降序。
 
> db.books.find().count()
7
#返回查询结果的总记录数。
 
> db.books.findOne()
#查询第一条记录
  1. 修改和删除指令
> db.books.update({"name":"java"},{$set:{"name":"javase","price":50.01}})
#把name为java的这条数据更新为name=javase和price=50.01。格式update({},{})，第一个{}为要更改的数据，第二个为要修改为什么数据。类似update books set name="javase" and price=50.01 where name="java"

#注意，如果存在多个name为java的则只修改一个，下面看如何更新多个。之前我们存在名为spring的书籍有两本。现在把这两本价格都修改为50.
 
> db.books.update({"name":"spring"},{$set : {"price":50}},{multi:true})
> db.books.find()
{ "_id" : ObjectId("5b7d4a588e6123a7a302be25"), "name" : "spring", "price" : 50 }
{ "_id" : ObjectId("5b7d58deabdfa1fbe797fa0b"), "name" : "spring", "price" : 50 }
#结果为name为spring的都修改了，{multi:true}表示是否修改多行，默认是为false。
 
> db.books.remove({"name":"spring"})
> db.books.find()
{ "_id" : ObjectId("5b7d4a6b8e6123a7a302be27"), "name" : "springMvc", "price" : 19.99 }
{ "_id" : ObjectId("5b7d4a898e6123a7a302be29"), "name" : "linux", "price" : 289.78 }
{ "_id" : ObjectId("5b7d4a9f8e6123a7a302be2a"), "name" : "python", "price" : 29.78 }
{ "_id" : ObjectId("5b7d4aad8e6123a7a302be2b"), "name" : "c++", "price" : 157.68 }
#删除name为spring的书籍，默认是存在多少个就删除多少个，与update相反。
 
> db.books.remove({}) #删除当前集合的所有数据，不要乱用。
  1. 索引的操作指令
> db.books.ensureIndex({"name":1,"price":-1}) 
#创建组合索引，mongodb会自动为索引创建名字，如果{}里面为一个，则为单个索引，多个就为组合索引，其中1和-1表示索引的方向。
 
> db.books.ensureIndex({"price":1},{"name":"index_price"})
#创建一个索引，并指定索引的名字。
 
> db.books.ensureIndex({"name":1},{"unique":true})
#为name创建一个唯一索引
 
> db.books.getIndexes()
#查看当前集合中的索引信息。

> db.system.indexes.find()
{ "v" : 1, "key" : { "_id" : 1 }, "ns" : "test.student", "name" : "_id_" }
{ "v" : 1, "key" : { "_id" : 1 }, "ns" : "test.books", "name" : "_id_" }
{ "v" : 1, "key" : { "name" : 1, "price" : 1 }, "ns" : "test.books", "name" : "name_1_price_1" }
{ "v" : 1, "key" : { "price" : 1 }, "ns" : "test.books", "name" : "index_price" }
{ "v" : 1, "key" : { "name" : 1 }, "unique" : true, "ns" : "test.books", "name" : "name_1" }
#索引的信息存在每个数据库的system.indexes集合里面，这里是查看所有的索引信息，需要与上面区别开。
 
> db.books.dropIndex("name_1")
{ "nIndexesWas" : 4, "ok" : 1 }
#删除在books集合中索引名为name_1的索引
 
> db.books.dropIndexes()
{
        "nIndexesWas" : 3,
        "msg" : "non-_id indexes dropped for collection",
        "ok" : 1
}
#删除在books集合中的所有索引。

db.collection.createIndex(keys, options)
语法中 Key 值为你要创建的索引字段，1 为指定按升序创建索引，如果你想按降序来创建索引指定为 -1 即可。

在后台创建索引：db.values.createIndex({open: 1, close: 1}, {background: true})

10.2 Redis与MemCache、MongoDB的对比

10.2.1 Redis与MemCache

  1. 相同点
    都支持一主多从集群模式。
    都是将数据存放在内存中，都是内存数据库。

  2. Redis优势区别

    1. Redis支持string、list、set、hash等数据结构，而Memcache只支持string。
    2. Redis支持AOF、RDB持久化策略，Memcache不支持持久化，宕机全无。
    3. Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘，Memcache超过内存比例会抹掉前面的数据。
    4. Redis可以在set时或set后用expire设置过期，Memcache只能在set时设置过期。
    5. Redis的key、value最大支持512MB，Memcache最大是1MB。
    6. Redis支持pub/sub消息订阅机制，可以用来进行消息订阅与通知。

  3. Memcache优势区别

    1. Memcache可以利用多核优势，单实例吞吐量极高，可以达到几十万QPS，适用于最大程度扛量。
    2. Redis单实例QPS大概只有5000~2W（未严格验证）。
    3. Memcache官方支持Linux和Win，而Redis官方只支持Linux。
10.2.2 Redis与MongoDB

Redis主要把数据存储在内存中，其“缓存”的性质远大于其“数据存储“的性质，其中数据的增删改查也只是像变量操作一样简单。
MongoDB却是一个“存储数据”的系统，增删改查可以添加很多条件，就像SQL数据库一样灵活。

指标MongoDB(v2.4.9)Redis(v2.4.17)比较说明
实现语言C++C/C++-
协议BSON、自定义二进制类Telnet-
性能依赖内存，TPS较高依赖内存，TPS非常高Redis优于MongoDB
可操作性丰富的数据表达、索引；最类似于关系数据库，支持丰富的查询语言数据丰富，较少的IOMongoDB优于Redis
内存及存储适合大数据量存储，依赖系统虚拟内存管理，采用镜像文件存储；内存占有率比较高，官方建议独立部署在64位系统（32位有最大2.5G文件限制，64位没有改限制）Redis2.0后增加虚拟内存特性，突破物理内存限制；数据可以设置时效性，类似于memcache不同的应用角度看，各有优势
可用性支持master-slave,replicaset（内部采用paxos选举算法，自动故障恢复）,auto sharding机制，对客户端屏蔽了故障转移和切分机制依赖客户端来实现分布式读写；主从复制时，每次从节点重新连接主节点都要依赖整个快照,无增量复制；不支持自动sharding,需要依赖程序设定一致hash机制MongoDB优于Redis；单点问题上，MongoDB应用简单，相对用户透明，Redis比较复杂，需要客户端主动解决。（MongoDB 一般会使用replica sets和sharding功能结合，replica sets侧重高可用性及高可靠性，而sharding侧重于性能、易扩展）
可靠性从1.8版本后，采用binlog方式（MySQL同样采用该方式）支持持久化，增加可靠性依赖快照进行持久化；AOF增强可靠性；增强可靠性的同时，影响访问性能MongoDB优于Redis
一致性不支持事务，靠客户端自身保证支持事务，比较弱，仅能保证事务中的操作按顺序执行Redis优于MongoDB
数据分析内置数据分析功能（mapreduce）不支持MongoDB优于Redis
应用场景海量数据的访问效率提升较小数据量的性能及运算MongoDB优于Redis

10.3 Redis单线程为什么这么快

  1. 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；
  2. 数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；
    1. SDS O(1)获取len属性；
    2. SDS空间预分配和惰性空间释放（不主动释放多余的空间）；
    3. 渐进式Rehash;
  3. 采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
  4. 使用epoll多路I/O复用模型，非阻塞IO。

10.4 Redis为什么单线程

Redis瓶颈主要是系统内存大小或者带宽大小，CPU一般不会成为瓶颈，既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了（毕竟采用多线程会有很多麻烦！）。

参考文章

  1. Redis 设计与实现
  2. Redis集群详解
  3. Redis cluster集群模式的原理
  4. Redis过期策略
  5. Redis 命令参考
  6. Redis常见面试题
  7. 超强、超详细Redis入门教程
  8. 什么是redis，redis能做什么，redis的应用场景
  9. redis 持久化详解,RDB和AOF是什么？他们优缺点是什么？运行流程是什么？
  10. 详解Redis中两种持久化机制RDB和AOF（面试常问，工作常用）
  11. redis 学习（13）-- BitMap
  12. redis：zset（赋值、取值、删除、修改分数）
  13. Redis 排行榜 相同分数根据时间优先排行
  14. Redis的事务功能详解
  15. MongoDB 教程
  16. MongoDB教程
  17. MongoDB入门教程（1）
  18. Redis和Memcache区别，优缺点对比
  19. Redis 慢查询分析
  20. memcache、redis等常用nosql解决方案，优缺点以及使用场景
  21. redis,memcache二者的区别是？（优缺点）
  22. Redis和MongoDB的区别(面试受用)
  23. 一文揭秘单线程的Redis为什么这么快?
  24. 为什么说Redis是单线程的以及Redis为什么这么快！
钟离默
关注
专栏目录
redis学习笔记
05-04
### Redis 学习笔记知识点概览 #### 一、Redis 简介及特性 - **Redis**（Remote Dictionary Server）是一种开源的、基于内存的数据结构存储系统，它支持多种数据结构，如字符串（strings）、散列（hashes）、列表...
Redis学习笔记整理
11-14
二、 redis学习笔记之数据类型 3 三、 redis学习笔记之排序 11 四、 redis学习笔记之事务 16 五、 redis学习笔记之pipeline 20 六、 redis学习笔记之发布订阅 23 七、 redis学习笔记之持久化 28 八、 redis学习笔记...
Redis学习笔记.zip
06-06
简单来说 redis 就是一个数据库，不过与传统数据库不同的是 redis 的数据是存在内存中的，所以存写速度非常快，因此 redis 被广泛应用于缓存方向。另外，redis 也经常用来做分布式锁。redis 提供了多种数据类型来...
redis学习笔记.docx
04-15
Redis学习笔记 Redis是基于键值对存储的NoSQL数据库，可以用来存储和检索数据。下面是Redis的基础知识点： 基础命令 * set key value：保存一个数据，重复set相同的key只会保存最新的value * get key：获取一个...
redis学习笔记.zip
10-19
这个“redis学习笔记.zip”压缩包很可能是包含了关于Redis的学习资料，可能包括概念解释、操作教程、实践案例等内容，适合初学者和有一定基础的学习者参考。 Redis的学习可以分为以下几个主要部分： 1. **基础知识...
Redis学习笔记.pdf
08-07
Redis还支持主从复制和哨兵机制（Sentinel），前者可以实现数据的同步备份，后者则用于管理多个Redis服务器，实现故障转移。Redis集群的建立和管理可以进一步提升数据库的高可用性和扩展性，支持数据分片和负载均衡...
redis学习笔记Redis.md
01-04
### Redis 学习笔记知识点概览 #### 一、Redis 概述与应用场景 ##### 1.1 NoSQL 数据库简介 - **定义**: NoSQL（Not Only SQL）泛指非关系型数据库，它们通常不使用传统的表格关系来存储数据。 - **特性**: NoSQL ...
Redis学习笔记大全
09-08
Redis学习笔记大全 Redis是当前使用最广泛的NoSQL数据库之一，具有高性能、低延迟和支持事务等特点。本文将对Redis的基本概念、安装、启动、关闭、基本命令、5大数据类型、发布和订阅、Bitmaps和HyperLoglog等进行...
redis学习笔记.pdf
02-13
Redis学习笔记 Redis是一个开源的基于键值对（Key-Value）NoSQL数据库，使用ANSI C语言编写、支持网络、基于内存但支持持久化。性能优秀，并提供多种语言的API。Redis可以被称为KV数据库，键值对数据库，内部存储...
Redis学习笔记1
08-08
本文将基于提供的“Redis学习笔记1”内容，详细介绍Redis的安装、启动、单线程特性、发布订阅机制、持久化策略以及AOF和RDB的区别。 1. **Redis安装与启动** Redis的安装通常涉及下载源码包、解压、编译和安装。在...
Redis全套学习笔记
05-25
Redis 是一款高性能的键值数据库，它以非关系型、内存存储的方式提供快速的数据访问。Redis 的设计目标是为了处理高并发、高扩展性场景，以及大数据存储问题。它支持多种数据结构，包括字符串(String)、链表(List)、...
超详细的redis学习笔记
11-27
### 超详细的Redis学习笔记知识点汇总 #### 1. Redis 的启动与停止 ##### 1.1 直接启动 Redis 服务 - **默认端口启动**：使用 `$ redis-server` 命令，默认监听端口为 `6379`。 - **指定端口启动**：使用 `$ ...
Redis
fxbsdl的博客
09-16 645
redis是一个的，将数据存储到中，的存储数据的一款可以用来当作1、（秒杀的商品数量信息），3、（如：俩个Java项目连接一个redis）1、可以将数据存储在内存中，也可以将数据持久化到硬盘上2、性能高，redis能读的速度是110000次/秒，写的速度是80000次/秒3、提供了丰富的数据结构存储数据为什么使用redis？大量用户连接数据库，数据库就会出现瓶颈（连接数量太多，io时间长）为了减轻数据库的压力，有些数据就直接存储到redis中，从而实现对关系型数据库的保护。redis安装。
实战Redis与MySQL双写一致性的缓存模式
不惑
09-20 478
​Redis和MySQL都是常用的数据存储系统，它们各自有自己的优缺点。在实际应用中，我们可能需要将它们结合起来使用，比如将Redis作为缓存，MySQL作为持久化存储。在这种情况下，我们需要保证Redis和MySQL的数据一致性，也就是当数据在Redis中进行修改时，也要相应地在MySQL中进行修改，反之亦然。
Redis 集群策略详解
lssffy的博客
09-16 704
为了应对这些问题，Redis 提供了**Redis 集群（Redis Cluster）**方案，通过将数据分片存储在多个节点上，实现高可用性和水平扩展。：Redis 集群具有自动故障转移机制，当集群中的某个主节点发生故障时，从节点会自动接替故障主节点，并成为新的主节点。：在 Redis 集群中，某些节点作为主节点负责处理读写请求，而其他节点作为从节点，保存主节点的数据副本。这意味着在某些场景下，从节点的数据可能会与主节点稍有不同，但经过一段时间后，从节点的数据会与主节点保持一致。
SpringBoot：关于Redis的配置失效(版本问题)
一些平时在开发过程中遇到的常见问题，分享给大家
09-14 461
SpringBoot：关于Redis的配置失效(版本问题)
redis常见问题
最新发布
weixin_44804108的博客
09-20 268
内存淘汰策略是允许reids在内存资源紧张时，根据一定策略主动删除一些键值对，已释放内存空间并保持系统的稳定性。缓存击穿：热点数据失效，大量请求打到DB。缓存雪崩：大规模缓存失效，或者缓存宕机。缓存穿透：查询不存在的数据。
如何基于Redis通过对接阿里云短信服务实现验证码登录
weixin_65950986的博客
09-18 347
这里简单记录一下。
尚硅谷redis学习笔记
09-08
尚硅谷是一个教育机构，他们提供了一份关于Redis的学习笔记。根据提供的引用内容，我们可以了解到他们提到了一些关于Redis配置和使用的内容。 首先，在引用中提到了通过执行命令"vi /redis-6.2.6/redis.conf"来编辑Redis配置文件。这个命令可以让你进入只读模式来查询"daemonize"配置项的位置。 在引用中提到了Redis会根据键值计算出应该送往的插槽，并且如果不是该客户端对应服务器的插槽，Redis会报错并告知应该前往的Redis实例的地址和端口。 在引用中提到了通过修改Redis的配置文件来指定Redis的日志文件位置。可以使用命令"sudo vim /etc/redis.conf"来编辑Redis的配置文件，并且在文件中指定日志文件的位置。 通过这些引用内容，我们可以得出结论，尚硅谷的Redis学习笔记涵盖了关于Redis的配置和使用的内容，并提供了一些相关的命令和操作示例。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* [Redis学习笔记--尚硅谷](https://blog.csdn.net/HHCS231/article/details/123637379)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] - *2* *3* [Redis学习笔记——尚硅谷](https://blog.csdn.net/qq_48092631/article/details/129662119)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值