压缩列表

概述

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

压缩列表的构成

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

  2. 图示
    图片说明
    图片说明
    图片说明

压缩列表节点的构成

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

  • 节点的previous_entry_length属性以字节为单位，记录了压缩列表中前一个节点的长度。previous_entry_length属性的长度可以是1字节或者5字节。
    图片说明
    因为节点的previous_entry_length属性记录了前一个节点的长度，所以程序可以通过指针运算，根据当前节点的起始地址来计算出前一个节点的起始地址。
    图片说明
    压缩列表的从表尾向表头遍历操作就是使用这一原理实现的，只要我们拥有了一个指向某个节点起始地址的指针，那么通过这个指针以及这个节点的previous_entry_length属性，程序就可以一直向前一个节点回溯，最终到达压缩列表的表头节点。
    举例一个从表尾节点向表头节点进行遍历的完整过程：
    图片说明

  • 节点的encoding属性记录了节点的content属性所保存数据的类型以及长度：
    ❑一字节、两字节或者五字节长，值的最高位为00、01或者10的是字节数组编码：这种编码表示节点的content属性保存着字节数组，数组的长度由编码除去最高两位之后的其他位记录；
    ❑一字节长，值的最高位以11开头的是整数编码：这种编码表示节点的content属性保存着整数值，整数值的类型和长度由编码除去最高两位之后的其他位记录；

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

连锁更新

  1. 由于每个节点的previous_entry_length属性特性决定的，根据前一个节点的长度不同所需要的空间不同，如果现在每一个节点都在临界值，如果在头部插入一个新的节点，第二个节点需要更新previous_entry_length值，空间变大，重新分配空间，后面接连都会陆陆续续的重新分配空间，Redis将这种在特殊情况下产生的连续多次空间扩展操作称之为“连锁更新”。除了添加新节点可能会引发连锁更新之外，删除节点也可能会引发连锁更新。
  2. 因为连锁更新在最坏情况下需要对压缩列表执行N次空间重分配操作，而每次空间重分配的最坏复杂度为O（N），所以连锁更新的最坏复杂度为O（N 2）。
  3. 要注意的是，尽管连锁更新的复杂度较高，但它真正造成性能问题的几率是很低的。情况很特殊，还能被中断，或许可能只是几个节点存在这样的情况
  4. 因为以上原因，ziplistPush等命令的平均复杂度仅为O（N），在实际中，我们可以放心地使用这些函数，而不必担心连锁更新会影响压缩列表的性能。

总结

❑压缩列表是一种为节约内存而开发的顺序型数据结构。
❑压缩列表被用作列表键和哈希键的底层实现之一。
❑压缩列表可以包含多个节点，每个节点可以保存一个字节数组或者整数值。
❑添加新节点到压缩列表，或者从压缩列表中删除节点，可能会引发连锁更新操作，但这种操作出现的几率并不高。

第八章 对象

概述

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

对象类型和编码

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

  2. 图片说明

  3. 对象的type属性记录了对象的类型
    图片说明

  4. 对于Redis数据库保存的键值对来说，键总是一个字符串对象，而值则可以是字符串对象、列表对象、哈希对象、集合对象或者有序集合对象的其中一种，因此：
    ❑当我们称呼一个数据库键为“字符串键”时，我们指的是“这个数据库键所对应的值为字符串对象”；
    ❑当我们称呼一个键为“列表键”时，我们指的是“这个数据库键所对应的值为列表对象”。

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

  6. 对象的ptr指针指向对象的底层实现数据结构，而这些数据结构由对象的encoding属性决定。encoding属性记录了对象所使用的编码，也即是说这个对象使用了什么数据结构作为对象的底层实现，这个属性的值可以是表8-3列出的常量的其中一个。
    图片说明

  7. 每种类型的对象都至少使用了两种不同的编码，表8-4列出了每种类型的对象可以使用的编码。
    图片说明

  8. 使用OBJECT ENCODING命令可以查看一个数据库键的值对象的编码
    图片说明
    图片说明

  9. 通过encoding属性来设定对象所使用的编码，而不是为特定类型的对象关联一种固定的编码，极大地提升了Redis的灵活性和效率，因为Redis可以根据不同的使用场景来为一个对象设置不同的编码，从而优化对象在某一场景下的效率。
    10 举例子在列表对象包含的元素比较少时，Redis使用压缩列表作为列表对象的底层实现：
    ❑因为压缩列表比双端链表更节约内存，并且在元素数量较少时，在内存中以连续块方式保存的压缩列表比起双端链表可以更快被载入到缓存中；
    ❑随着列表对象包含的元素越来越多，使用压缩列表来保存元素的优势逐渐消失时，对象就会将底层实现从压缩列表转向功能更强、也更适合保存大量元素的双端链表上面；其他类型的对象也会通过使用多种不同的编码来进行类似的优化。

字符串对象

  1. 字符串对象的编码可以是int、raw或者embstr。
  2. 如果一个字符串对象保存的是整数值，并且这个整数值可以用long类型来表示，那么字符串对象会将整数值保存在字符串对象结构的ptr属性里面（将void*转换成long），并将字符串对象的编码设置为int。图片说明
  3. 如果字符串对象保存的是一个字符串值，并且这个字符串值的长度大于32字节，那么字符串对象将使用一个简单动态字符串（SDS）来保存这个字符串值，并将对象的编码设置为raw。图片说明
  4. embstr编码是专门用于保存短字符串的一种优化编码方式，这种编码和raw编码一样，都使用redisObject结构和sdshdr结构来表示字符串对象，但raw编码会调用两次内存分配函数来分别创建redisObject结构和sdshdr结构，而embstr编码则通过调用一次内存分配函数来分配一块连续的空间，空间中依次包含redisObject和sdshdr两个结构，如图8-3所示。
    图片说明
  5. embstr编码的字符串对象在执行命令时，产生的效果和raw编码的字符串对象执行命令时产生的效果是相同的，但使用embstr编码的字符串对象来保存短字符串值有以下好处：
    ❑embstr编码将创建字符串对象所需的内存分配次数从raw编码的两次降低为一次。
    ❑释放embstr编码的字符串对象只需要调用一次内存释放函数，而释放raw编码的字符串对象需要调用两次内存释放函数。
    ❑因为embstr编码的字符串对象的所有数据都保存在一块连续的内存里面，所以这种编码的字符串对象比起raw编码的字符串对象能够更好地利用缓存带来的优势。
  6. 例子
    图片说明
  7. 可以用long double类型表示的浮点数在Redis中也是作为字符串值来保存的。如果我们要保存一个浮点数到字符串对象里面，那么程序会先将这个浮点数转换成字符串值，然后再保存转换所得的字符串值。
    图片说明
    图片说明
  8. 编码的转换
    • int编码的字符串对象和embstr编码的字符串对象在条件满足的情况下，会被转换为raw编码的字符串对象。对于int编码的字符串对象来说，如果我们向对象执行了一些命令，使得这个对象保存的不再是整数值，而是一个字符串值，那么字符串对象的编码将从int变为raw。
      图片说明
  9. 因为Redis没有为embstr编码的字符串对象编写任何相应的修改程序（只有int编码的字符串对象和raw编码的字符串对象有这些程序），所以embstr编码的字符串对象实际上是只读的。当我们对embstr编码的字符串对象执行任何修改命令时，程序会先将对象的编码从embstr转换成raw，然后再执行修改命令。因为这个原因，embstr编码的字符串对象在执行修改命令之后，总会变成一个raw编码的字符串对象。【embstr不能修改，修改就需要编程raw】
  10. 字符串命令
    图片说明

列表对象

  1. 列表对象的编码可以是ziplist或者linkedlist。
  2. ziplist编码的列表对象使用压缩列表作为底层实现，每个压缩列表节点（entry）保存了一个列表元素。图片说明
  3. linkedlist编码的列表对象使用双端链表作为底层实现，每个双端链表节点（node）都保存了一个字符串对象，而每个字符串对象都保存了一个列表元素。图片说明
  • linkedlist编码的列表对象在底层的双端链表结构中包含了多个字符串对象，这种嵌套字符串对象的行为在稍后介绍的哈希对象、集合对象和有序集合对象中都会出现，字符串对象是Redis五种类型的对象中唯一一种会被其他四种类型对象嵌套的对象。
    图片说明
  1. 编码的转换
  • 当列表对象可以同时满足以下两个条件时，列表对象使用ziplist编码：（以下两个值是可以改变的）
    ❑列表对象保存的所有字符串元素的长度都小于64字节；
    ❑列表对象保存的元素数量小于512个；不能满足这两个条件的列表对象需要使用linkedlist编码。
    对于使用ziplist编码的列表对象来说，当使用ziplist编码所需的两个条件的任意一个不能被满足时，对象的编码转换操作就会被执行，原本保存在压缩列表里的所有列表元素都会被转移并保存到双端链表里面，对象的编码也会从ziplist变为linkedlist。
  1. 列表命令的实现
    图片说明

哈希对象

  1. 哈希对象的编码可以是ziplist或者hashtable。
  2. ziplist编码的哈希对象使用压缩列表作为底层实现，每当有新的键值对要加入到哈希对象时，程序会先将保存了键的压缩列表节点推入到压缩列表表尾，然后再将保存了值的压缩列表节点推入到压缩列表表尾，【连续存放】因此：
    ❑保存了同一键值对的两个节点总是紧挨在一起，保存键的节点在前，保存值的节点在后；
    ❑先添加到哈希对象中的键值对会被放在压缩列表的表头方向，而后来添加到哈希对象中的键值对会被放在压缩列表的表尾方向。
    图片说明
  3. 另一方面，hashtable编码的哈希对象使用字典作为底层实现，哈希对象中的每个键值对都使用一个字典键值对来保存：❑字典的每个键都是一个字符串对象，对象中保存了键值对的键；❑字典的每个值都是一个字符串对象，对象中保存了键值对的值。
    图片说明
  4. 编码转换（可配置）
    当哈希对象可以同时满足以下两个条件时，哈希对象使用ziplist编码：
    ❑哈希对象保存的所有键值对的键和值的字符串长度都小于64字节；
    ❑哈希对象保存的键值对数量小于512个；不能满足这两个条件的哈希对象需要使用hashtable编码。
  5. 对于使用ziplist编码的列表对象来说，当使用ziplist编码所需的两个条件的任意一个不能被满足时，对象的编码转换操作就会被执行，原本保存在压缩列表里的所有键值对都会被转移并保存到字典里面，对象的编码也会从ziplist变为hashtable。
  6. 哈希命令
    图片说明

集合对象

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

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

  3. 图片说明

  4. 编码的转换（可配置）
    当集合对象可以同时满足以下两个条件时，对象使用intset编码：
    ❑集合对象保存的所有元素都是整数值；
    ❑集合对象保存的元素数量不超过512个。
    不能满足这两个条件的集合对象需要使用hashtable编码。

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

  6. 举例子 图片说明

  7. 命令
    图片说明

有序集合对象

  1. 有序集合的编码可以是ziplist或者skiplist。ziplist编码的压缩列表对象使用压缩列表作为底层实现，每个集合元素使用两个紧挨在一起的压缩列表节点来保存，第一个节点保存元素的成员（member），而第二个元素则保存元素的分值（score）。
  2. 压缩列表内的集合元素按分值从小到大进行排序，分值较小的元素被放置在靠近表头的方向，而分值较大的元素则被放置在靠近表尾的方向。
  3. 举例子
    图片说明
    图片说明
  4. skiplist编码的有序集合对象使用zset结构作为底层实现，一个zset结构同时包含一个字典和一个跳跃表：
    图片说明
    图片说明
  5. zset结构中的zsl跳跃表按分值从小到大保存了所有集合元素，每个跳跃表节点都保存了一个集合元素：跳跃表节点的object属性保存了元素的成员，而跳跃表节点的score属性则保存了元素的分值。通过这个跳跃表，程序可以对有序集合进行范围型操作，比如ZRANK、ZRANGE等命令就是基于跳跃表API来实现的
  6. zset结构中的dict字典为有序集合创建了一个从成员到分值的映射，字典中的每个键值对都保存了一个集合元素：字典的键保存了元素的成员，而字典的值则保存了元素的分值。通过这个字典，程序可以用O（1）复杂度查找给定成员的分值，ZSCORE命令就是根据这一特性实现的，而很多其他有序集合命令都在实现的内部用到了这一特性。
  7. 有序集合每个元素的成员都是一个字符串对象，而每个元素的分值都是一个double类型的浮点数。值得一提的是，虽然zset结构同时使用跳跃表和字典来保存有序集合元素，但这两种数据结构都会通过指针来共享相同元素的成员和分值，所以同时使用跳跃表和字典来保存集合元素不会产生任何重复成员或者分值，也不会因此而浪费额外的内存。 【类似于LRU】
  8. 为什么有序集合需要同时使用跳跃表和字典来实现？
  • 有序集合可以单独使用字典或者跳跃表的其中一种数据结构来实现，但无论单独使用字典还是跳跃表，在性能上对比起同时使用字典和跳跃表都会有所降低。举个例子，如果我们只使用字典来实现有序集合，那么虽然以O（1）复杂度查找成员的分值这一特性会被保留，但是，因为字典以无序的方式来保存集合元素，所以每次在执行范围型操作——比如ZRANK、ZRANGE等命令时，程序都需要对字典保存的所有元素进行排序，完成这种排序需要至少O（NlogN）时间复杂度，以及额外的O（N）内存空间（因为要创建一个数组来保存排序后的元素）。
  • 如果我们只使用跳跃表来实现有序集合，那么跳跃表执行范围型操作的所有优点都会被保留，但因为没有了字典，所以根据成员查找分值这一操作的复杂度将从O（1）上升为O（logN）。因为以上原因，为了让有序集合的查找和范围型操作都尽可能快地执行，Redis选择了同时使用字典和跳跃表两种数据结构来实现有序集合。

  1. 编码的转换（可配置）
    当有序集合对象可以同时满足以下两个条件时，对象使用ziplist编码：
    ❑有序集合保存的元素数量小于128个；
    ❑有序集合保存的所有元素成员的长度都小于64字节；
    不能满足以上两个条件的有序集合对象将使用skiplist编码。

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

  3. 命令
    图片说明

类型检验与命令多态

1.Redis中用于操作键的命令基本上可以分为两种类型。其中一种命令可以对任何类型的键执行，比如说DEL命令、EXPIRE命令、RENAME命令、TYPE命令、OBJECT命令等。
图片说明
2. 另一种命令只能对特定类型的键执行
❑SET、GET、APPEND、STRLEN等命令只能对字符串键执行；
❑HDEL、HSET、HGET、HLEN等命令只能对哈希键执行；
❑RPUSH、LPOP、LINSERT、LLEN等命令只能对列表键执行；
❑SADD、SPOP、SINTER、SCARD等命令只能对集合键执行；
❑ZADD、ZCARD、ZRANK、ZSCORE等命令只能对有序集合键执行；
3. 类型检查的实现
为了确保只有指定类型的键可以执行某些特定的命令，在执行一个类型特定的命令之前，Redis会先检查输入键的类型是否正确，然后再决定是否执行给定的命令。
类型特定命令所进行的类型检查是通过redisObject结构的type属性来实现的：
❑在执行一个类型特定命令之前，服务器会先检查输入数据库键的值对象是否为执行命令所需的类型，如果是的话，服务器就对键执行指定的命令；
❑否则，服务器将拒绝执行命令，并向客户端返回一个类型错误
图片说明

  1. 多态命令的实现
    Redis除了会根据值对象的类型来判断键是否能够执行指定命令之外，还会根据值对象的编码方式，选择正确的命令实现代码来执行命令。
    图片说明
    图片说明

内存回收

  1. Redis在自己的对象系统中构建了一个引用计数（reference counting）技术实现的内存回收机制，通过这一机制，程序可以通过跟踪对象的引用计数信息，在适当的时候自动释放对象并进行内存回收。每个对象的引用计数信息由redisObject结构的refcount属性记录
    图片说明
    图片说明

对象共享

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

图片说明

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

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

  3. 为什么Redis不共享包含字符串的对象？
    当服务器考虑将一个共享对象设置为键的值对象时，程序需要先检查给定的共享对象和键想创建的目标对象是否完全相同，只有在共享对象和目标对象完全相同的情况下，程序才会将共享对象用作键的值对象，而一个共享对象保存的值越复杂，验证共享对象和目标对象是否相同所需的复杂度就会越高，消耗的CPU时间也会越多。
    尽管共享更复杂的对象可以节约更多的内存，但受到CPU时间的限制，Redis只对包含整数值的字符串对象进行共享。

对象的空转时长

  1. redisobject中除了的type、encoding、ptr和refcount四个属性之外，redisObject结构包含的最后一个属性为lru属性，该属性记录了对象最后一次被命令程序访问的时间
    图片说明
  2. OBJECT IDLETIME命令的实现是特殊的，这个命令在访问键的值对象时，不会修改值对象的lru属性。除了可以被OBJECT IDLETIME命令打印出来之外，键的空转时长还有另外一项作用：如果服务器打开了maxmemory选项，并且服务器用于回收内存的算法为volatile-lru或者allkeys-lru，那么当服务器占用的内存数超过了maxmemory选项所设置的上限值时，空转时长较高的那部分键会优先被服务器释放，从而回收内存。
    图片说明

重点回顾

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