【Java - redis】数据类型内部编码和应用场景

笔记：
《Redis设计与实现》
《Redis实战运维》

1-内部编码

1. 每种数据结构都有两种以上的内部编码实现，例如list数据结构包含了linkedlist和ziplist两种内部编码
   

数据结构

1. 概述
   

1 long类型的整数

2 简单动态字符串|raw

|C字符串|SDS|SDS作用|SDS实现|和C的区别|为什么用SDS|||

1. 关于C语言的字符串？

• C语言传统的字符串表示（以空字符结尾的字符数组，以下简称C字符串）
• Redis里面，C字符串只会作为字符串字面量（string literal）用在一些无须对字符串值进行修改的地方，比如打印日志：

  redisLog(REDIS_WARNING,"Redis is now ready to exit, bye bye...");
  
  

1. redis构建的字符串？

• 简单动态字符串（simple dynamic string，SDS）的抽象类型；
• 用作Redis的默认字符串表示；
• 当Redis需要的不仅仅是一个字符串字面量，而是一个可以被修改的字符串值时，Redis就会使用SDS来表示字符串值，比如在Redis的数据库里面，包含字符串值的键值对在底层都是由SDS实现的。

2. SDS的应用？

• 1）用来保存数据库中的字符串值；
  2）用作缓冲区（buffer）：AOF模块中的AOF缓冲区，以及客户端状态中的输入缓冲区，都是由SDS实现的；

1. SDS的实现？

• SDS的定义
  1）每个sds.h/sdshdr结构表示一个SDS值：

  struct sdshdr {
      // 记录buf数组中已使用字节的数量等于SDS所保存字符串的长度
      int len;
      // 记录buf数组中未使用字节的数量
      int free;
      // 字节数组，用于保存字符串
      char buf[];
  };
  
  

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


– SDS遵循C字符串以空字符结尾的惯例，保存空字符的1字节空间不计算在SDS的len属性里面，并且为空字符分配额外的1字节空间，以及添加空字符到字符串末尾等操作，都是由SDS函数自动完成的，所以这个空字符对于SDS的使用者来说是完全透明的。遵循空字符结尾这一惯例的好处是，SDS可以直接重用一部分C字符串函数库里面的函数。
– 上两个图展示的SDS的区别在于，这个SDS为buf数组分配了五字节未使用空间，所以它的free属性的值为5（图中使用五个空格来表示五字节的未使用空间）。

1. SDS与C字符串的区别？

• 根据传统，C语言使用长度为N+1的字符数组来表示长度为N的字符串，并且字符数组的最后一个元素总是空字符’\0’。
• 1）常数复杂度获取字符串长度
  – C字符串：C字符串并不记录自身的长度信息，所以为了获取一个C字符串的长度，程序必须遍历整个字符串，对遇到的每个字符进行计数，直到遇到代表字符串结尾的空字符为止，这个操作的复杂度为O（N）。
  – SDS：和C字符串不同，因为SDS在len属性中记录了SDS本身的长度，所以获取一个SDS长度的复杂度仅为O（1）。
  设置和更新SDS长度的工作是由SDS的API在执行时自动完成的，使用SDS无须进行任何手动修改长度的工作。
  – 总：通过使用SDS而不是C字符串，Redis将获取字符串长度所需的复杂度从O（N）降低到了O（1），这确保了获取字符串长度的工作不会成为Redis的性能瓶颈。
• 2）杜绝缓冲区溢出
  – 缓冲区溢出：C字符串不记录自身长度带来的另一个问题是容易造成缓冲区溢出（buffer overflow）。
  例子，<string.h>/strcat函数可以将src字符串中的内容拼接到dest字符串的末尾：
  char *strcat(char *dest, const char *src);
  – C字符串：因为C字符串不记录自身的长度，所以strcat假定用户在执行这个函数时，已经为dest分配了足够多的内存，可以容纳src字符串中的所有内容，而一旦这个假定不成立时，就会产生缓冲区溢出。
  – SDS：与C字符串不同，SDS的空间分配策略完全杜绝了发生缓冲区溢出的可能性：当SDS API需要对SDS进行修改时，API会先检查SDS的空间是否满足修改所需的要求，如果不满足的话，API会自动将SDS的空间扩展至执行修改所需的大小，然后才执行实际的修改操作，所以使用SDS既不需要手动修改SDS的空间大小，也不会出现前面所说的缓冲区溢出问题。
• 3）减少修改字符串时带来的内存重分配次数
  – 现象：因为内存重分配涉及复杂的算法，并且可能需要执行系统调用，所以它通常是一个比较耗时的操作：
  · 在一般程序中，如果修改字符串长度的情况不太常出现，那么每次修改都执行一次内存重分配是可以接受的。
  · 但是Redis作为数据库，经常被用于速度要求严苛、数据被频繁修改的场合，如果每次修改字符串的长度都需要执行一次内存重分配的话，那么光是执行内存重分配的时间就会占去修改字符串所用时间的一大部分，如果这种修改频繁地发生的话，可能还会对性能造成影响。
  – C字符串：因为C字符串并不记录自身的长度，所以对于一个包含了N个字符的C字符串来说，这个C字符串的底层实现总是一个N+1个字符长的数组（额外的一个字符空间用于保存空字符）。因为C字符串的长度和底层数组的长度之间存在着这种关联性，所以每次增长或者缩短一个C字符串，程序都总要对保存这个C字符串的数组进行一次内存重分配操作：
  · 如果程序执行的是增长字符串的操作，比如拼接操作（append），那么在执行这个操作之前，程序需要先通过内存重分配来扩展底层数组的空间大小——如果忘了这一步就会产生缓冲区溢出。
  · 如果程序执行的是缩短字符串的操作，比如截断操作（trim），那么在执行这个操作之后，程序需要通过内存重分配来释放字符串不再使用的那部分空间——如果忘了这一步就会产生内存泄漏。
  – SDS：为了避免C字符串的这种缺陷，SDS通过未使用空间解除了字符串长度和底层数组长度之间的关联：在SDS中，buf数组的长度不一定就是字符数量加一，数组里面可以包含未使用的字节，而这些字节的数量就由SDS的free属性记录。
• 4）二进制安全
  – C字符串：C字符串中的字符必须符合某种编码（比如ASCII），并且除了字符串的末尾之外，字符串里面不能包含空字符，否则最先被程序读入的空字符将被误认为是字符串结尾，这些限制使得C字符串只能保存文本数据，而不能保存像图片、音频、视频、压缩文件这样的二进制数据。
  – SDS：虽然数据库一般用于保存文本数据，但使用数据库来保存二进制数据的场景也不少见，因此，为了确保Redis可以适用于各种不同的使用场景，SDS的API都是二进制安全的（binary-safe），所有SDS API都会以处理二进制的方式来处理SDS存放在buf数组里的数据，程序不会对其中的数据做任何限制、过滤、或者假设，数据在写入时是什么样的，它被读取时就是什么样。
  这也是我们将SDS的buf属性称为字节数组的原因——Redis不是用这个数组来保存字符，而是用它来保存一系列二进制数据。
  – 总：通过使用二进制安全的SDS，而不是C字符串，使得Redis不仅可以保存文本数据，还可以保存任意格式的二进制数据。
• 5）兼容部分C字符串函数
  – 虽然SDS的API都是二进制安全的，但它们一样遵循C字符串以空字符结尾的惯例：这些API总会将SDS保存的数据的末尾设置为空字符，并且总会在为buf数组分配空间时多分配一个字节来容纳这个空字符，这是为了让那些保存文本数据的SDS可以重用一部分<string.h>库定义的函数。
  – 总：通过遵循C字符串以空字符结尾的惯例，SDS可以在有需要时重用<string.h>函数库，从而避免了不必要的代码重复。
  

1. 未使用空间，SDS实现的空间预分配和惰性空间释放两种优化策略？ - 减少修改字符串时带来的内存重分配次数

• ① 空间预分配
  – 空间预分配用于优化SDS的字符串增长操作：当SDS的API对一个SDS进行修改，并且需要对SDS进行空间扩展的时候，程序不仅会为SDS分配修改所必须要的空间，还会为SDS分配额外的未使用空间。
  – 其中，额外分配的未使用空间数量由以下公式决定：
  · 如果对SDS进行修改之后，SDS的长度（也即是len属性的值）将小于1MB，那么程序分配和len属性同样大小的未使用空间，这时SDS len属性的值将和free属性的值相同。举个例子，如果进行修改之后，SDS的len将变成13字节，那么程序也会分配13字节的未使用空间，SDS的buf数组的实际长度将变成13+13+1=27字节（额外的一字节用于保存空字符）。
  · 如果对SDS进行修改之后，SDS的长度将大于等于1MB，那么程序会分配1MB的未使用空间。
  举个例子，如果进行修改之后，SDS的len将变成30MB，那么程序会分配1MB的未使用空间，SDS的buf数组的实际长度将为30MB+1MB+1byte。
  – 通过空间预分配策略，Redis可以减少连续执行字符串增长操作所需的内存重分配次数。
  – 在扩展SDS空间之前，SDSAPI会先检查未使用空间是否足够，如果足够的话，API就会直接使用未使用空间，而无须执行内存重分配。
  – 通过这种预分配策略，SDS将连续增长N次字符串所需的内存重分配次数从必定N次降低为最多N次。
• ② 惰性空间释放
  – 惰性空间释放用于优化SDS的字符串缩短操作：当SDS的API需要缩短SDS保存的字符串时，程序并不立即使用内存重分配来回收缩短后多出来的字节，而是使用free属性将这些字节的数量记录起来，并等待将来使用。
  – 通过惰性空间释放策略，SDS避免了缩短字符串时所需的内存重分配操作，并为将来可能有的增长操作提供了优化。
  – 与此同时，SDS也提供了相应的API，让我们可以在有需要时，真正地释放SDS的未使用空间，所以不用担心惰性空间释放策略会造成内存浪费。

3. 解释为什么Redis要使用SDS而不是C字符串？

• 比起C字符串，SDS具有以下优点：
  1）常数复杂度获取字符串长度。
  2）杜绝缓冲区溢出。
  3）减少修改字符串长度时所需的内存重分配次数。
  4）二进制安全。
  5）兼容部分C字符串函数。

3 链表-linkedlist

1. 链表基本知识？

• 链表提供了高效的节点重排能力，以及顺序性的节点访问方式，并且可以通过增删节点来灵活地调整链表的长度。
• 作为一种常用数据结构，链表内置在很多高级的编程语言里面，因为Redis使用的C语言并没有内置这种数据结构，所以Redis构建了自己的链表实现。
• 链表在Redis中的应用非常广泛，比如列表键的底层实现之一就是链表。当一个列表键包含了数量比较多的元素，又或者列表中包含的元素都是比较长的字符串时，Redis就会使用链表作为列表键的底层实现。
• 作用：
  – integers列表键的底层实现就是一个链表，链表中的每个节点都保存了一个整数值。
  – 除了链表键之外，发布与订阅、慢查询、监视器等功能也用到了链表，Redis服务器本身还使用链表来保存多个客户端的状态信息，以及使用链表来构建客户端输出缓冲区（output buffer）

1. 链表和链表节点的实现？

• 每个链表节点使用一个adlist.h/listNode结构来表示：
• 多个listNode可以通过prev和next指针组成双端链表

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

• 虽然仅仅使用多个listNode结构就可以组成链表，但使用adlist.h/list来持有链表的话，操作起来会更方便：
• 如下，list结构为链表提供了表头指针head、表尾指针tail，以及链表长度计数器len，而dup、free和match成员则是用于实现多态链表所需的类型特定函数：
  · dup函数用于复制链表节点所保存的值；
  · free函数用于释放链表节点所保存的值；
  · match函数则用于对比链表节点所保存的值和另一个输入值是否相等。

  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;
  
  

1. Redis的链表实现的特性可以总结如下：

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

4 字典-hashtable

1. 字典的基本理论？

• 字典，又称为符号表（symbol table）、关联数组（associative array）或映射（map），是一种用于保存键值对（key-value pair）的抽象数据结构。
• 在字典中，一个键（key）可以和一个值（value）进行关联（或者说将键映射为值），这些关联的键和值就称为键值对。
• 字典中的每个键都是独一无二的，程序可以在字典中根据键查找与之关联的值，或者通过键来更新值，又或者根据键来删除整个键值对，等等。
• 字典经常作为一种数据结构内置在很多高级编程语言里面，但Redis所使用的C语言并没有内置这种数据结构，因此Redis构建了自己的字典实现。
• 字典在Redis中的应用相当广泛，比如Redis的数据库就是使用字典来作为底层实现的，对数据库的增、删、查、改操作也是构建在对字典的操作之上的。
• 除了用来表示数据库之外，字典还是哈希键的底层实现之一，当一个哈希键包含的键值对比较多，又或者键值对中的元素都是比较长的字符串时，Redis就会使用字典作为哈希键的底层实现。
• 除了用来实现数据库和哈希键之外，Redis的不少功能也用到了字典

1. 字典的实现？
   Redis的字典使用哈希表作为底层实现，一个哈希表里面可以有多个哈希表节点，而每个哈希表节点就保存了字典中的一个键值对。
   接下来的三个小节将分别介绍Redis的哈希表、哈希表节点以及字典的实现。

• 1）哈希表
  – Redis字典所使用的哈希表由dict.h/dictht结构定义：
  ---- table属性：是一个数组，数组中的每个元素都是一个指向dict.h/dictEntry结构的指针，每个dictEntry结构保存着一个键值对。
  ---- size属性：记录了哈希表的大小，也即是table数组的大小，而used属性则记录了哈希表目前已有节点（键值对）的数量。
  ---- sizemask属性：的值总是等于size-1，这个属性和哈希值一起决定一个键应该被放到table数组的哪个索引上面。
  ---- 展示了一个大小为4的空哈希表（没有包含任何键值对）。

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

• 2）哈希表节点
  哈希表节点使用dictEntry结构表示，每个dictEntry结构都保存着一个键值对：
  ---- key属性：保存着键值对中的键；
  ---- v属性：则保存着键值对中的值，其中键值对的值可以是一个指针，或者是一个uint64_t整数，又或者是一个int64_t整数。
  ---- next属性：是指向另一个哈希表节点的指针，这个指针可以将多个哈希值相同的键值对连接在一次，以此来解决键冲突（collision）的问题。

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

• 3)字典
  Redis中的字典由dict.h/dict结构表示：
  – type属性和privdata属性是针对不同类型的键值对，为创建多态字典而设置的：
  ---- type属性：是一个指向dictType结构的指针，每个dictType结构保存了一簇用于操作特定类型键值对的函数，Redis会为用途不同的字典设置不同的类型特定函数。
  ---- privdata属性：则保存了需要传给那些类型特定函数的可选参数。
  ---- ht属性：是一个包含两个项的数组，数组中的每个项都是一个dictht哈希表，一般情况下，字典只使用ht[0]哈希表，ht[1]哈希表只会在对ht[0]哈希表进行rehash时使用。
  除了ht[1]之外，另一个和rehash有关的属性就是rehashidx，它记录了rehash目前的进度，如果目前没有在进行rehash，那么它的值为-1。
  – 如图，普通状态下（没有进行rehash）的字典。

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

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

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

  #使用字典设置的哈希函数，计算键key的哈希值
  hash = dict->type->hashFunction(key);
  #使用哈希表的sizemask属性和哈希值，计算出索引值
  #根据情况不同，ht[x]可以是ht[0]或者ht[1]
  index = hash & dict->ht[x].sizemask;
  

空字典

当字典被用作数据库的底层实现，或者哈希键的底层实现时，Redis使用MurmurHash2算法来计算键的哈希值。

1. 解决键冲突？
   当有两个或以上数量的键被分配到了哈希表数组的同一个索引上面时，我们称这些键发生了冲突（collision）。
   Redis的哈希表使用链地址法（separate chaining）来解决键冲突，每个哈希表节点都有一个next指针，多个哈希表节点可以用next指针构成一个单向链表，被分配到同一个索引上的多个节点可以用这个单向链表连接起来，这就解决了键冲突的问题。

• 因为dictEntry节点组成的链表没有指向链表表尾的指针，所以为了速度考虑，程序总是将新节点添加到链表的表头位置（复杂度为O（1）），排在其他已有节点的前面。
  一个包含两个键值对的哈希表使用链表解决k2和k1的冲突
  
  

1. rehash？

• 随着操作的不断执行，哈希表保存的键值对会逐渐地增多或者减少，为了让哈希表的负载因子（load factor）维持在一个合理的范围之内，当哈希表保存的键值对数量太多或者太少时，程序需要对哈希表的大小进行相应的扩展或者收缩。
• 扩展和收缩哈希表的工作可以通过执行rehash（重新散列）操作来完成，Redis对字典的哈希表执行rehash的步骤如下：
  1）为字典的ht[1]哈希表分配空间，这个哈希表的空间大小取决于要执行的操作，以及ht[0]当前包含的键值对数量（也即是ht[0].used属性的值）：
  · 如果执行的是扩展操作，那么ht[1]的大小为第一个大于等于ht[0].used*2的2 n（2的n次方幂）；
  · 如果执行的是收缩操作，那么ht[1]的大小为第一个大于等于ht[0].used的2 n。
  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做准备。

1. rehash的步骤？
   举个例子，假设程序要对图4-8所示字典的ht[0]进行扩展操作，那么程序将执行以下步骤：
   – 执行rehash之前的字典：
   

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

1. 哈希表的扩展与收缩？

• 当以下条件中的任意一个被满足时，程序会自动开始对哈希表执行扩展操作：
  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时，程序自动开始对哈希表执行收缩操作。

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而带来的庞大计算量。

1. 一次完整的渐进式rehash过程?

• 下图展示了一次完整的渐进式rehash过程，注意观察在整个rehash过程中，字典的rehashidx属性是如何变化的。
• 1）准备开始rehash
  
• 2）rehash索引0上的键值对
  
• 3）rehash索引1上的键值对
  
• 4）rehash索引2上的键值对
  
• 5）rehash索引3上的键值对
  
• 6）rehash执行完毕
  

1. 渐进式rehash执行期间的哈希表操作？

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

4 跳跃表-skiplist

1. 跳跃表基本理论？

• 跳跃表（skiplist）是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的。
• 跳跃表支持平均O（logN）、最坏O（N）复杂度的节点查找，还可以通过顺序性操作来批量处理节点。
• 在大部分情况下，跳跃表的效率可以和平衡树相媲美，并且因为跳跃表的实现比平衡树要来得更为简单，所以有不少程序都使用跳跃表来代替平衡树。
• Redis使用跳跃表作为有序集合键的底层实现之一，如果一个有序集合包含的元素数量比较多，又或者有序集合中元素的成员（member）是比较长的字符串时，Redis就会使用跳跃表来作为有序集合键的底层实现。
• 和链表、字典等数据结构被广泛地应用在Redis内部不同，Redis只在两个地方用到了跳跃表，一个是实现有序集合键，另一个是在集群节点中用作内部数据结构，除此之外，跳跃表在Redis里面没有其他用途。本章将对Redis中的跳跃表实现进行介绍，并列出跳跃表的操作API。本章不会对跳跃表的基本定义和基础算法进行介绍，如果有需要的话，可以参考WilliamPugh关于跳跃表的论文《Skip Lists:A Probabilistic Alternative to Balanced Trees》，或者《算法：C语言实现（第1～4部分）》一书的13.5节。

1. 跳跃表的实现？

• Redis的跳跃表由redis.h/zskiplistNode和redis.h/zskiplist两个结构定义；
  – 其中，
  zskiplistNode结构：用于表示跳跃表节点；
  zskiplist结构：则用于保存跳跃表节点的相关信息，比如节点的数量，以及指向表头节点和表尾节点的指针等等。
• zskiplist结构：位于图片最左边的，该结构包含以下属性：
  – header：指向跳跃表的表头节点。
  – tail：指向跳跃表的表尾节点。
  – level：记录目前跳跃表内，层数最大的那个节点的层数（表头节点的层数不计算在内）。
  – length：记录跳跃表的长度，也即是，跳跃表目前包含节点的数量（表头节点不计算在内）。
• zskiplistNode结构：位于zskiplist结构右方的是四个zskiplistNode结构，该结构包含以下属性：
  – 层（level）：节点中用L1、L2、L3等字样标记节点的各个层，L1代表第一层，L2代表第二层，以此类推。每个层都带有两个属性：前进指针和跨度。前进指针用于访问位于表尾方向的其他节点，而跨度则记录了前进指针所指向节点和当前节点的距离。在上面的图片中，连线上带有数字的箭头就代表前进指针，而那个数字就是跨度。当程序从表头向表尾进行遍历时，访问会沿着层的前进指针进行。
  – 后退（backward）指针：节点中用BW字样标记节点的后退指针，它指向位于当前节点的前一个节点。后退指针在程序从表尾向表头遍历时使用。
  – 分值（score）：各个节点中的1.0、2.0和3.0是节点所保存的分值。在跳跃表中，节点按各自所保存的分值从小到大排列。
  – 成员对象（obj）：各个节点中的o1、o2和o3是节点所保存的成员对象。
  注意表头节点和其他节点的构造是一样的：表头节点也有后退指针、分值和成员对象，不过表头节点的这些属性都不会被用到，所以图中省略了这些部分，只显示了表头节点的各个层。
• 如下，一个跳跃表：
  

1. zskiplistNode和zskiplist两个结构-zskiplistNode？
   跳跃表节点的实现由redis.h/zskiplistNode结构定义：

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

• 1）层
  跳跃表节点的level数组可以包含多个元素，每个元素都包含一个指向其他节点的指针，程序可以通过这些层来加快访问其他节点的速度，一般来说，层的数量越多，访问其他节点的速度就越快。
  每次创建一个新跳跃表节点的时候，程序都根据幂次定律（power law，越大的数出现的概率越小）随机生成一个介于1和32之间的值作为level数组的大小，这个大小就是层的“高度”。
  图展示了三个高度为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。
  

1. zskiplistNode和zskiplist两个结构-zskiplist？

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

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

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

6 整数集-intset

1. 整数集的基本知识？

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

1. 整数集合的实现

• 整数集合（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数组是整数集合的底层实现：整数集合的每个元素都是contents数组的一个数组项（item），各个项在数组中按值的大小从小到大有序地排列，并且数组中不包含任何重复项。
– length属性：length属性记录了整数集合包含的元素数量，也即是contents数组的长度。

• 虽然intset结构将contents属性声明为int8_t类型的数组，但实际上contents数组并不保存任何int8_t类型的值，contents数组的真正类型取决于encoding属性的值：
  · 如果encoding属性的值为INTSET_ENC_INT16，那么contents就是一个int16_t类型的数组，数组里的每个项都是一个int16_t类型的整数值（最小值为-32768，最大值为32767）。
  · 如果encoding属性的值为INTSET_ENC_INT32，那么contents就是一个int32_t类型的数组，数组里的每个项都是一个int32_t类型的整数值（最小值为-2147483648，最大值为2147483647）。
  · 如果encoding属性的值为INTSET_ENC_INT64，那么contents就是一个int64_t类型的数组，数组里的每个项都是一个int64_t类型的整数值（最小值为-9223372036854775808，最大值为9223372036854775807）。

1. 升级？

• 每当我们要将一个新元素添加到整数集合里面，并且新元素的类型比整数集合现有所有元素的类型都要长时，整数集合需要先进行升级（upgrade），然后才能将新元素添加到整数集合里面。
• 升级整数集合并添加新元素共分为三步进行：
  1）根据新元素的类型，扩展整数集合底层数组的空间大小，并为新元素分配空间。
  2）将底层数组现有的所有元素都转换成与新元素相同的类型，并将类型转换后的元素放置到正确的位上，而且在放置元素的过程中，需要继续维持底层数组的有序性质不变。
  3）将新元素添加到底层数组里面。
• 因为每次向整数集合添加新元素都可能会引起升级，而每次升级都需要对底层数组中已有的所有元素进行类型转换，所以向整数集合添加新元素的时间复杂度为O（N）。

1. 升级过程的例子展示？

2. 升级之后新元素的摆放位置？

• 因为引发升级的新元素的长度总是比整数集合现有所有元素的长度都大，所以这个新元素的值要么就大于所有现有元素，要么就小于所有现有元素：
  · 在新元素小于所有现有元素的情况下，新元素会被放置在底层数组的最开头（索引0）；
  · 在新元素大于所有现有元素的情况下，新元素会被放置在底层数组的最末尾（索引length-1）。

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

• 1）提升灵活性
  因为C语言是静态类型语言，为了避免类型错误，我们通常不会将两种不同类型的值放在同一个数据结构里面。
  – 例如，我们一般只使用int16_t类型的数组来保存int16_t类型的值，只使用int32_t类型的数组来保存int32_t类型的值，诸如此类。
  – 但是，因为整数集合可以通过自动升级底层数组来适应新元素，所以我们可以随意地将int16_t、int32_t或者int64_t类型的整数添加到集合中，而不必担心出现类型错误，这种做法非常灵活。
• 2）节约内存
  当然，要让一个数组可以同时保存int16_t、int32_t、int64_t三种类型的值，最简单的做法就是直接使用int64_t类型的数组作为整数集合的底层实现。不过这样一来，即使添加到整数集合里面的都是int16_t类型或者int32_t类型的值，数组都需要使用int64_t类型的空间去保存它们，从而出现浪费内存的情况。
  – 而整数集合现在的做法既可以让集合能同时保存三种不同类型的值，又可以确保升级操作只会在有需要的时候进行，这可以尽量节省内存。
  – 例如，如果我们一直只向整数集合添加int16_t类型的值，那么整数集合的底层实现就会一直是int16_t类型的数组，只有在我们要将int32_t类型或者int64_t类型的值添加到集合时，程序才会对数组进行升级。

1. 降级？

• 整数集合不支持降级操作，一旦对数组进行了升级，编码就会一直保持升级后的状态。
• 例子：
  – 对于图1所示的整数集合来说，即使我们将集合里唯一一个真正需要使用int64_t类型来保存的元素4294967295删除了，整数集合的编码仍然会维持INTSET_ENC_INT64，底层数组也仍然会是int64_t类型的，如图2所示。
  
  

7.压缩列表-ziplist

1. 压缩列表的基本知识？

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

2. 压缩列表的构成？

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

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

2. 压缩列表节点的构成？

• 每个压缩列表节点都由previous_entry_length、encoding、content三个部分组成：
  
• 每个压缩列表节点可以保存一个字节数组或者一个整数值
  – 字节数组：可以是以下三种长度的其中一种：
  ·长度小于等于63（2 6–1）字节的字节数组；
  ·长度小于等于16383（2 14–1）字节的字节数组；
  ·长度小于等于4294967295（2 32–1）字节的字节数组；
  – 整数值：则可以是以下六种长度的其中一种：
  ·4位长，介于0至12之间的无符号整数；
  ·1字节长的有符号整数；
  ·3字节长的有符号整数；
  ·int16_t类型整数；
  ·int32_t类型整数；
  ·int64_t类型整数。

1. 压缩列表节点的构成？-previous_entry_length

• 节点的previous_entry_length属性
  以字节为单位，记录了压缩列表中前一个节点的长度。previous_entry_length属性的长度可以是1字节或者5字节：
  ·如果前一节点的长度小于254字节，那么previous_entry_length属性的长度为1字节：前一节点的长度就保存在这一个字节里面。
  ·如果前一节点的长度大于等于254字节，那么previous_entry_length属性的长度为5字节：其中属性的第一字节会被设置为0xFE（十进制值254），而之后的四个字节则用于保存前一节点的长度。
• 因为节点的previous_entry_length属性记录了前一个节点的长度，所以程序可以通过指针运算，根据当前节点的起始地址来计算出前一个节点的起始地址。
• 压缩列表的从表尾向表头遍历操作就是使用这一原理实现的，只要我们拥有了一个指向某个节点起始地址的指针，那么通过这个指针以及这个节点的previous_entry_length属性，程序就可以一直向前一个节点回溯，最终到达压缩列表的表头节点。

1. 一个从表尾节点向表头节点进行遍历的完整过程？
   ·首先，我们拥有指向压缩列表表尾节点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. 压缩列表节点的构成？-encoding

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

1. 压缩列表节点的构成？-content

• 节点的content属性
  负责保存节点的值，节点值可以是一个字节数组或者整数，值的类型和长度由节点的encoding属性决定。
• 一个保存字节数组的节点示例：
  ·编码的最高两位00表示节点保存的是一个字节数组；
  ·编码的后六位001011记录了字节数组的长度11；
  ·content属性保存着节点的值"hello world"。
  
  ·编码11000000表示节点保存的是一个int16_t类型的整数值；
  ·content属性保存着节点的值10086。

1. 连锁更新？

• 每个节点的previous_entry_length属性都记录了前一个节点的长度：
  ·如果前一节点的长度小于254字节，那么previous_entry_length属性需要用1字节长的空间来保存这个长度值。
  ·如果前一节点的长度大于等于254字节，那么previous_entry_length属性需要用5字节长的空间来保存这个长度值。
• 一种情况：在一个压缩列表中，有多个连续的、长度介于250字节到253字节之间的节点e1至eN：
  – 因为e1至eN的所有节点的长度都小于254字节，所以记录这些节点的长度只需要1字节长的previous_entry_length属性，换句话说，e1至eN的所有节点的previous_entry_length属性都是1字节长的。
  
• 问题：这时，如果我们将一个长度大于等于254字节的新节点new设置为压缩列表的表头节点，那么new将成为e1的前置节点：
  – 因为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）
• 连锁更新过程：
  

1. 删除节点引发的连锁更新？

• 除了添加新节点可能会引发连锁更新之外，删除节点也可能会引发连锁更新。
• 考虑压缩列表，如果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），在实际中，可以放心地使用这些函数，而不必担心连锁更新会影响压缩列表的性能。

对象

1. 概述

• Redis用到的所有主要数据结构，如简单动态字符串（SDS）、双端链表、字典、压缩列表、整数集合等等。
• Redis并没有直接使用这些数据结构来实现键值对数据库，而是基于这些数据结构创建了一个对象系统，这个系统包含字符串对象、列表对象、哈希对象、集合对象和有序集合对象这五种类型的对象;

1. 简化字符串对象，以下统一使用

• 使用了一个带有StringObject字样的格子来表示一个字符串对象，而StringObject字样下面的是字符串对象所保存的值
  

1. 对象的表示？

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

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

1. type属性

• 记录了对象的类型，属性的值可以是如下常量：
  REDIS_STRING(字符串对象)、
  REDIS_LIST（列表对象）、
  REDIS_HASH（哈希对象）、
  REDIS_SET（集合对象）、
  REDIS_ZSET（有序集合对象）
• TYPE命令
  对一个数据库键执行TYPE命令时，命令返回的结果为数据库键对应的值对象的类型，而不是键对象的类型;
• 不同类型值对象的TYPE命令输出
  对象type属性的值/对象/TYPE命令的输出
  REDIS_STRING(字符串对象)string、
  REDIS_LIST（列表对象）list、
  REDIS_HASH（哈希对象）hash、
  REDIS_SET（集合对象）set、
  REDIS_ZSET（有序集合对象）zset

1. ptr指针和encoding属性

• 对象的ptr指针指向对象的底层实现数据结构，而这些数据结构由对象的encoding属性决定。
• encoding属性记录了对象所使用的编码，也即是说这个对象使用了什么数据结构作为对象的底层实现，这个属性的值可以是以下常量：
  
• 不同编码的对象所对应的OBJECT ENCODING命令输出。
  
  

1 string

1. string对象编码？

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

1. 字符串对象编码？

• ① int
  如果一个字符串对象保存的是整数值，并且这个整数值可以用long类型来表示，那么字符串对象会将整数值保存在字符串对象结构的ptr属性里面（将void*转换成long），并将字符串对象的编码设置为int；
• ② raw
  如果字符串对象保存的是一个字符串值，并且这个字符串值的长度大于32字节，那么字符串对象将使用一个简单动态字符串（SDS）来保存这个字符串值，并将对象的编码设置为raw。
  
• ③ embstr
  如果字符串对象保存的是一个字符串值，并且这个字符串值的长度小于等于32字节，那么字符串对象将使用embstr编码的方式来保存这个字符串值。
  

1. embstr编码？

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

1. embstr编码的字符串对象来保存短字符串值的好处?

• 1） embstr编码将创建字符串对象所需的内存分配次数从raw编码的两次降低为一次。
• 2）释放embstr编码的字符串对象只需要调用一次内存释放函数，而释放raw编码的字符串对象需要调用两次内存释放函数。
  3） 因为embstr编码的字符串对象的所有数据都保存在一块连续的内存里面，所以这种编码的字符串对象比起raw编码的字符串对象能够更好地利用缓存带来的优势。

1. 保存long double类型表示的浮点数

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

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

2. 编码转换？

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

2 list

1. 列表对象的编码？

• 列表对象的编码可以是ziplist或者linkedlist。
• 1）ziplist
  ziplist编码的列表对象使用压缩列表作为底层实现，每个压缩列表节点（entry）保存了一个列表元素。
  
• linkedlist
  linkedlist编码的列表对象使用双端链表作为底层实现，每个双端链表节点（node）都保存了一个字符串对象，而每个字符串对象都保存了一个列表元素。
  

1. 对象嵌套？

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

1. 编码转换？

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

3 hash

1. 哈希对象的编码？

• 哈希对象的编码可以是ziplist或者hashtable。
• ziplist编码
  ziplist编码的哈希对象使用压缩列表作为底层实现，每当有新的键值对要加入到哈希对象时，程序会先将保存了键的压缩列表节点推入到压缩列表表尾，然后再将保存了值的压缩列表节点推入到压缩列表表尾，因此：
  ·保存了同一键值对的两个节点总是紧挨在一起，保存键的节点在前，保存值的节点在后；
  ·先添加到哈希对象中的键值对会被放在压缩列表的表头方向，而后来添加到哈希对象中的键值对会被放在压缩列表的表尾方向。
  
• hashtable编码
  hashtable编码的哈希对象使用字典作为底层实现，哈希对象中的每个键值对都使用一个字典键值对来保存：
  ·字典的每个键都是一个字符串对象，对象中保存了键值对的键；
  ·字典的每个值都是一个字符串对象，对象中保存了键值对的值。
  

1. 编码转换？

• 当哈希对象可以同时满足以下两个条件时，哈希对象使用ziplist编码：
  ·哈希对象保存的所有键值对的键和值的字符串长度都小于64字节；
  ·哈希对象保存的键值对数量小于512个；不能满足这两个条件的哈希对象需要使用hashtable编码。
• 对于使用ziplist编码的列表对象来说，当使用ziplist编码所需的两个条件的任意一个不能被满足时，对象的编码转换操作就会被执行，原本保存在压缩列表里的所有键值对都会被转移并保存到字典里面，对象的编码也会从ziplist变为hashtable。

4 set

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

• intset编码
  intset编码的集合对象使用整数集合作为底层实现，集合对象包含的所有元素都被保存在整数集合里面。
  
• hashtable编码
  hashtable编码的集合对象使用字典作为底层实现，字典的每个键都是一个字符串对象，每个字符串对象包含了一个集合元素，而字典的值则全部被设置为NULL。
  

1. 编码转换？

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

5 zset

1. 有序集合的编码

• 有序集合的编码可以是ziplist或者skiplist。
• ziplist编码
  ziplist编码的压缩列表对象使用压缩列表作为底层实现，每个集合元素使用两个紧挨在一起的压缩列表节点来保存，第一个节点保存元素的成员（member），而第二个元素则保存元素的分值（score）。
  压缩列表内的集合元素按分值从小到大进行排序，分值较小的元素被放置在靠近表头的方向，而分值较大的元素则被放置在靠近表尾的方向。
  
  
• skiplist编码
  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结构同时使用跳跃表和字典来保存有序集合元素，但这两种数据结构都会通过指针来共享相同元素的成员和分值，所以同时使用跳跃表和字典来保存集合元素不会产生任何重复成员或者分值，也不会因此而浪费额外的内存。

1. 为什么有序集合需要同时使用跳跃表和字典来实现？

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

1. 编码转换？

• 不能满足以上两个条件的有序集合对象将使用skiplist编码。（可修改条件上限）
  ·有序集合保存的元素数量小于128个；
  ·有序集合保存的所有元素成员的长度都小于64字节；
• 对于使用ziplist编码的有序集合对象来说，当使用ziplist编码所需的两个条件中的任意一个不能被满足时，就会执行对象的编码转换操作，原本保存在压缩列表里的所有集合元素都会被转移并保存到zset结构里面，对象的编码也会从ziplist变为skiplist。

2-应用场景

1. string

1. string类型应用场景？

• 1）缓存功能
  比较典型的缓存使用场景，如图
  
  – 其中，Redis作为缓存层，MySQL作为存储层，绝大部分请求的数据都是从Redis中获取。由于Redis具有支撑高并发的特性，所以缓存通常能起到加速读写和降低后端压力的作用。

  //1）该函数用于获取用户的基础信息：
      UserInfo getUserInfo(long id){
          ...
      }
  //2）首先从Redis获取用户信息：
      // 定义键
      userRedisKey = "user:info:" + id;
      // 从Redis获取值
      value = redis.get(userRedisKey);
      if (value != null) {
          // 将值进行反序列化为UserInfo并返回结果
          userInfo = deserialize(value);
          return userInfo;
      }
  //3）如果没有从Redis获取到用户信息，需要从MySQL中进行获取，并将结果回写到Redis，添加1小时（3600秒）过期时间：
      // 从MySQL获取用户信息
      userInfo = mysql.get(id);
      // 将userInfo序列化，并存入Redis
      redis.setex(userRedisKey, 3600, serialize(userInfo));
      // 返回结果
      return userInfo    
  //总结：整个功能的伪代码如下：
      UserInfo getUserInfo(long id){
          userRedisKey = "user:info:" + id
          value = redis.get(userRedisKey);
          UserInfo userInfo;
          if (value != null) {
              userInfo = deserialize(value);
          } else {
              userInfo = mysql.get(id);
              if (userInfo != null)
              redis.setex(userRedisKey, 3600, serialize(userInfo));
          }
          return userInfo;
      }
      
  

• 2）计数
  – Redis作为计数的基础工具，可以实现快速计数、查询缓存的功能，同时数据可以异步落地到其他数据源。
  – 例如笔者所在团队的视频播放数系统就是使用Redis作为视频播放数计数的基础组件，用户每播放一次视频，相应的视频播放数就会自增1：

  long incrVideoCounter(long id) {
      key = "video:playCount:" + id;
      return redis.incr(key);
  }
  
  

  – 应用：实际上一个真实的计数系统要考虑的问题会很多：防作弊、按照不同维度计数，数据持久化到底层数据源等。
• 3)共享Session
  现象：
  一个分布式Web服务将用户的Session信息（例如用户登录信息）保存在各自服务器中，这样会造成一个问题，出于负载均衡的考虑，分布式服务会将用户的访问均衡到不同服务器上，用户刷新一次访问可能会发现需要重新登录，这个问题是用户无法容忍的。
  解决：
  为了解决这个问题，可以使用Redis将用户的Session进行集中管理，如
  图，在这种模式下只要保证Redis是高可用和扩展性的，每次用户更新或者查询登录信息都直接从Redis中集中获取。
  
  
• 4）限速
  很多应用出于安全的考虑，会在每次进行登录时，让用户输入手机验证
  码，从而确定是否是用户本人。但是为了短信接口不被频繁访问，会限制用户每分钟获取验证码的频率，例如一分钟不能超过5次
  (例如一些网站限制一个IP地址不能在一秒钟之内访问超过n次也可以采用类似的思路。)

  //伪代码给出了基本实现思路：
      phoneNum = "138xxxxxxxx";
      key = "shortMsg:limit:" + phoneNum;
      // SET key value EX 60 NX
      isExists = redis.set(key,1,"EX 60","NX");
      if(isExists != null || redis.incr(key) <=5){
          // 通过
      }else{
          // 限速
      }
      
  

2. hash

3. 哈希应用场景？

• 关系型数据表记录的两条用户信息，用户的属性作为表的列，每条用户信息作为行。

  id	name	age	city
  1	tom	23	beijng
  2	mike	30	tianjin

• 将其用哈希类型存储
  

• 相比于使用字符串序列化缓存用户信息，哈希类型变得更加直观，并且在更新操作上会更加便捷。可以将每个用户的id定义为键后缀，多对fieldvalue对应每个用户的属性，类似如下伪代码：

  UserInfo getUserInfo(long id){
      // 用户id作为key后缀
      userRedisKey = "user:info:" + id;
      // 使用hgetall获取所有用户信息映射关系
      userInfoMap = redis.hgetAll(userRedisKey);
      UserInfo userInfo;
      if (userInfoMap != null) {
          // 将映射关系转换为UserInfo
          userInfo = transferMapToUserInfo(userInfoMap);
      } else {
          // 从MySQL中获取用户信息
          userInfo = mysql.get(id);
          // 将userInfo变为映射关系使用hmset保存到Redis中
          redis.hmset(userRedisKey, transferUserInfoToMap(userInfo));
          // 添加过期时间
          redis.expire(userRedisKey, 3600);
      }
      return userInfo;
  }
  
  

• 不同
  但是需要注意的是哈希类型和关系型数据库有两点不同之处：
  – 哈希类型是稀疏的，而关系型数据库是完全结构化的，例如哈希类型
  每个键可以有不同的field，而关系型数据库一旦添加新的列，所有行都要为其设置值（即使为NULL）
  – 关系型数据库可以做复杂的关系查询，而Redis去模拟关系型复杂查询开发困难，维护成本高。

4. 三种缓存方法-方案的实现方法和优缺点分析。
   缓存用户信息：
   1）原生字符串类型：每个属性一个键。

   set user:1:name tom
   set user:1:age 23
   set user:1:city beijing
   

优点：简单直观，每个属性都支持更新操作。
缺点：占用过多的键，内存占用量较大，同时用户信息内聚性比较差，
所以此种方案一般不会在生产环境使用。
2）序列化字符串类型：将用户信息序列化后用一个键保存。
set user:1 serialize(userInfo)
优点：简化编程，如果合理的使用序列化可以提高内存的使用效率。
缺点：序列化和反序列化有一定的开销，同时每次更新属性都需要把全
部数据取出进行反序列化，更新后再序列化到Redis中。
3）哈希类型：每个用户属性使用一对field-value，但是只用一个键保
存。
hmset user:1 name tomage 23 city beijing
优点：简单直观，如果使用合理可以减少内存空间的使用。
缺点：要控制哈希在ziplist和hashtable两种内部编码的转换，hashtable会消耗更多内存。

3. list

1. list列表的使用场景？

2. 消息队列
   lpush+brpop命令组合即可实现阻塞队列，生产者客户端使用lrpush从列表左侧插入元素，多个消费者客户端使用brpop命令阻塞式的“抢”列表尾部的元素，多个客户端保证了消费的负载均衡和高可用性。
   

3. 文章列表
   每个用户有属于自己的文章列表，现需要分页展示文章列表。此时可以
   考虑使用列表，因为列表不但是有序的，同时支持按照索引范围获取元素。

• 1|每篇文章使用哈希结构存储，例如每篇文章有3个属性title、timestamp、content：

  hmset acticle:1 title xx timestamp 1476536196 content xxxx
  ...
  hmset acticle:k title yy timestamp 1476512536 content yyyy
  ...
  

• 2|向用户文章列表添加文章，user：{id}：articles作为用户文章列表的键(key)：

  lpush user:1:acticles article:1 article3
  ...
  lpush user:k:acticles article:5
  ...
  
  

• 3|分页获取用户文章列表，例如下面伪代码获取用户id=1的前10篇文
  章：

  articles = lrange user:1:articles 0 9
  for article in {articles}
      hgetall {article}
  

• 使用列表类型保存和获取文章列表会存在两个问题。
  第一，如果每次分页获取的文章个数较多，需要执行多次hgetall操作，此时可以考虑使用Pipeline批量获取，或者考虑将文章数据序列化为字符串类型，使用mget批量获取。
  第二，分页获取文章列表时，lrange命令在列表两端性能较好，但是如果列表较大，获取列表中间范围的元素性能会变差，此时可以考虑将列表做二级拆分，或者使用Redis3.2的quicklist内部编码实现，它结合ziplist和linkedlist的特点，获取列表中间范围的元素时也可以高效完成。

3. 扩展？
   实际上列表的使用场景很多，在选择时可以参考以下口诀：

• lpush+lpop=Stack（栈）
• lpush+rpop=Queue（队列）
• lpsh+ltrim=Capped Collection（有限集合）
• lpush+brpop=Message Queue（消息队列）

4.set

1. 标签？

• 集合类型比较典型的使用场景是标签（tag）。
• 例如一个用户可能对娱乐、体育比较感兴趣，另一个用户可能对历史、新闻比较感兴趣，这些兴趣点就是标签。有了这些数据就可以得到喜欢同一个标签的人，以及用户的共同喜好的标签，这些数据对于用户体验以及增强用户黏度比较重要。
• 例如一个电子商务的网站会对不同标签的用户做不同类型的推荐，比如对数码产品比较感兴趣的人，在各个页面或者通过邮件的形式给他们推荐最新的数码产品，通常会为网站带来更多的利益。

2. 实现标签功能？
   下面使用集合类型实现标签功能的若干功能。

• 1|给用户添加标签

  sadd user:1:tags tag1 tag2 tag5
  sadd user:2:tags tag2 tag3 tag5
  ...
  sadd user:k:tags tag1 tag2 tag4
  ...
  

• 2|给标签添加用户

  sadd tag1:users user:1 user:3
  sadd tag2:users user:1 user:2 user:3
  ...
  sadd tagk:users user:1 user:2
  ...
  

2. 开发注意问题:开发提示1:
   用户和标签的关系维护应该在一个事务内执行，防止部分命令失败造成的数据不一致，有关如何将两个命令放在一个事务，参考事务以及Lua的使用方法。

• 3|删除用户下的标签

  srem user:1:tags tag1 tag5
  ...
  

• 4|删除标签下的用户

  srem tag1:users user:1
  srem tag5:users user:1
  ...
  

• 3|和4|也是尽量放在一个事务执行。
• 5|计算用户共同感兴趣的标签可以使用sinter命令，来计算用户共同感兴趣的标签，如下代码所示：

  sinter user:1:tags user:2:tags
  

2. 开发注意问题:开发提示2:
   前面只是给出了使用Redis集合类型实现标签的基本思路，实际上一个
   标签系统远比这个要复杂得多，不过集合类型的应用场景通常为以下几种：

• sadd=Tagging（标签）
• spop/srandmember=Random item（生成随机数，比如抽奖）
• sadd+sinter=Social Graph（社交需求）

5-zset

1. zset的应用场景？

• 有序集合比较典型的使用场景就是排行榜系统。
• 例如视频网站需要对用户上传的视频做排行榜，榜单的维度可能是多个方面的：按照时间、按照播放数量、按照获得的赞数。

2. 使用赞数这个维度，记录每天用户上传视频的排行榜。
   主要需要实现以下4个功能：
   （1）添加用户赞数
   例如用户mike上传了一个视频，并获得了3个赞，可以使用有序集合的zadd和zincrby功能：

   zadd user:ranking:2016_03_15 mike 3
   

如果之后再获得一个赞，可以使用zincrby：
zincrby user:ranking:2016_03_15 mike 1
（2）取消用户赞数
由于各种原因（例如用户注销、用户作弊）需要将用户删除，此时需要
将用户从榜单中删除掉，可以使用zrem。
例如删除成员tom：
zrem user:ranking:2016_03_15 mike
（3）展示获取赞数最多的十个用户
此功能使用zrevrange命令实现：
zrevrangebyrank user:ranking:2016_03_15 0 9
（4）展示用户信息以及用户分数
此功能将用户名作为键后缀，将用户信息保存在哈希类型中，至于用户
的分数和排名可以使用zscore和zrank两个功能：
hgetall user:info:tom zscore user:ranking:2016_03_15 mike zrank user:ranking:2016_03_15 mike