Redis之底层数据结构

Posted swimming_in_it_

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Redis之底层数据结构相关的知识，希望对你有一定的参考价值。

一 Redis数据结构

Redis底层数据结构有三层意思：

  • 从Redis本身数据存储的结构层面来看，Redis数据结构是一个HashMap。
  • 从使用者角度来看，Redis的数据结构是String，List，Hash，Set，Sorted Set。
  • 从内部实现角度来看，Redis的数据结构是ict，sds，ziplist，quicklist，skiplist，intset。

这五种数据类型分别对应以下几种数据结构：

如图所示：

  • String的底层是：简单动态字符串
  • List的底层是：双向链表和压缩列表。
  • Hash的底层是：压缩链表和哈希表
  • Set底层是：整数数组和哈希表。
  • Sort Set底层是：压缩链表和跳表。

1.Redis哈希表如何实现

  Redis是一个k-v的数据库。为了实现从key到value的快速访问，Redis使用了一个哈希表来保存所有的键值对。

  • 一个哈希表，本身就是一个数组，数组的每个元素称为一个哈希桶。
  • 不管是键类型还是值类型，哈希桶内的元素保存的都不是值本身，而是指向具体值的指针。

  如下图中可以看到，哈希桶中的entry元素中保存了key和value指针，分别指向了实际的键和值，这样一来，即使值是一个集合，也可以通过*value指针被查找到：

因为这个哈希表保存了所有的键值对，所以，它也叫做全局哈希表。

  • 哈希表的最大好处就是让我们可以用O(1)的时间复杂度来快速查找到键值对----我们只需要计算键的哈希值，就可以知道它对应的哈希桶位置，然后就可以访问相应的entry元素。
  • 这个查找过程主要依赖于哈希计算，和数据量的多少并没有直接关系。也就是说，不管哈希表里有10万个键还是 100 万个键，我们只需要一次计算就能找到相应的键。
  • 也就是说，整个数据库就是一个全局hash表，而hash表的时间复杂度就是O(1)，只需要计算每个键的hash值，就知道对应的hash桶的位置，定位桶里面的entry找到对应数据，这个也是redis块的原因之一。

2.Redis哈希冲突

1，什么是hash冲突？

  哈希冲突，也就是指，两个key的哈希值和哈希桶计算对应关系时，正好落在了同一个哈希桶中。毕竟，哈希桶的个数通常要少于key的数量，hash冲突是不可避免。

2，hash冲突如何解决？

  Redis解决哈希冲突的方式，就是链式哈希：所谓的链式哈希，就是指同一个哈希桶中的多个元素用一个链表来保存，它们之间一次用指针连接。如下图：

  图中的entry1、entry2 和 entry3 都需要保存在哈希桶 3 中，导致了哈希冲突。此时，entry1 元素会通过一个next指针指向 entry2，同样，entry2 也会通过next指针指向entry3。这样一来，即使哈希桶 3 中的元素有 100 个，我们也可以通过 entry 元素中的指针，把它们连起来。这就形成了一个链表，也叫作哈希冲突链。

3，渐进式rehash

  上面说过，哈希冲突的解决办法是hash链表，但是hash链表中如果hash冲突链越来越长，肯定会导致redis的性能下降，解决办法是什么尼？也就是渐进式rehash。
  为了使得rehash操作更加高效，redis默认使用了两个全局哈希表：哈希表1和哈希表2.一开始，当你刚插入数据时，默认使用哈希表1，此时的哈希表2并没有被分配空间。随着数据逐步增多，redis开始执行rehash，这个过程分为三步：

  1. 把哈希表2分配更大的空间，比如是当前哈希表1大小的两倍
  2. 把哈希表1中的数据重新映射并拷贝到哈希表2中
  3. 释放哈希表1的空间

  至此，我们就可以从哈希表1切换到哈希表2，用增大的哈希表2保存更多的数据，而原来的哈希表1操作留作下一次rehash扩容备用。

  上面步骤有一个问题，那就是第二步涉及大量的数据拷贝，如果一次性把哈希表1中的数据都迁移完，会造成redis线程阻塞，无法服务其他请求。此时，redis就无法快速访问数据了。为了避免这个问题，redis采用了渐进式rehash。
  简单来说就是在第二步拷贝数据时，Redis 仍然正常处理客户端请求，每处理一个请求时，从哈希表 1 中的第一个索引位置开始，顺带着将这个索引位置上的所有 entries 拷贝到哈希表 2 中；等处理下一个请求时，再顺带拷贝哈希表 1 中的下一个索引位置的entries。如下图所示：

  这样就巧妙地把一次性大量拷贝的开销，分摊到了多次处理请求的过程中，避免了耗时操作，保证了数据的快速访问。另外，渐进式rehash执行时，除了根据键值对的操作来进行数据迁移，redis本身还会有一群定时任务在执行rehash，如果没有键值对操作，这个定时任务会周期性的搬移一些数据到新的哈希表中。

二 Redis中value的内部实现数据结构

  redis是通过对象来表示存储的数据的，redis 也是键值对存储的方式，那么每存储一条数据，redis至少会生成2个对象，一个是redisObject，用来描述具体数据的类型的，比如用的是那种数据类型，底层用了哪种数据结构，还有一个对象就是具体存储的数据。 这个存储对象数据就是通过redisObject这个对象的指针来指引的。
  由于不同的数据类型，是有不同的内部实现且互相交叉的，具体如图所示：

  下面我们将分开介绍简单动态字符串，双向列表，压缩列表，哈希表，跳表和整数数组。

1.RedisObject对象解析

  上面说过redis本身在存储数据的时候会产生一个redisObject对象用来存储当前key对应的value的数据类型。其结构如下：

typedef struct redisObject 
 
	unsigned type:4; 
	unsigned encoding:4; 
	//对象最后一次被访问的时间
	unsigned lru:REDIS_LRU_BITS;  
	/* lru time (relative to server.lruclock) */  
	int refcount; 
	//指向底层实现数据结构的指针
	void *ptr;
 robj;

其中具体的值含义如下：
1，type： 字段表示value的对象类型，占4byte。目前包括REDIS_STRING(字符串)、REDIS_LIST (列表)、REDIS_HASH(哈希)、REDIS_SET(集合)、REDIS_ZSET(有序集合)。在执行 type key的时候能查看到对应的类型：

2，encoding 表示对象的内部编码，占4个比特。对于redis支持的每种类型都至少有两种编码，对于字符串有int、embsre、row三种
通过encoding属性，redis可以根据不同的使用场景来对对象使用不同的编码，大大提高的redis的灵活性和效率。命令：object encoding key;

3，lru： 记录对象最后一次被访问的时间，当配置了maxmemory和maxmemory-policy=valatile-lru ｜ allkeys-lru时，用于辅助LRU算法删除键数据。可以使用 object idletime key 命令在不更新lru字段情况下查看当前键的空闲时间。开发提示：可以使用scan + object idletime 命令批量查询哪些键长时间未被访问，找出长时间不访问的键进行清理降低内存占用。
4，refcount字段: 记录当前对象被引用的次数，用于通过引用次数回收内存，当refcount=0时，可以安全回收当前对象空间。使用object refcount key 获取当前对象引用。当对象为整数且范围在[0-9999]时，Redis可以使用共享对象的方式来节省内存。具体细节见之后共享对象池部分。
5，ptr字段: 与对象的数据内容相关，如果是整数直接存储数据，否则表示指向数据的指针。Redis在3.0之后对值对象是字符串且长度<=39字节的数据，内部编码为embstr类型，字符串sds和redisObject一起分配，从而只要一次内存操作。开发提示：高并发写入场景中，在条件允许的情况下建议字符串长度控制在39字节以内，减少创建redisObject内存分配次数从而提高性能。eg：一个代表string的robj，它的ptr可能指向一个sds结构；一个代表list的robj，它的ptr可能指向一个quicklist。

2.SDS：简单动态字符串

1，实现原理

  在c语音中，定义的字符串是不可被修改的，因此redis设计了可变的字符串长度对象，接SDS（simple dynamic string），实现原理：

struct sdshdr
    //记录buf数组中已存的字节数量，也就是sds保存的字符串长度
    int len;
 
    // buf数组中剩余可用的字节数量
    int free;
 
    //字节数组，用来存储字符串的
    char buf[];

参数解析：

  1. len ： 保存的字符串长度。获取字符串的长度就是O(1)
  2. free：剩余可用存储字符串的长度
  3. buf：保存字符串

这样设计的优点：
1）：当用户修改字符串时sds api会先检查空间是否满足需求，如果满足，直接执行修改操作，如果不满足，将空间修改至满足需求的大小，然后再执行修改操作
2）：空间预分配

  1. 如果修改后的sds的字符串小于1MB时（也就是len的长度小于1MB），那么程序会分配与len属性相同大小的未使用空间（就是再给未使用空间free也分配与len相同的空间） 例：字符串大小为600k，那么会分配600k给这个字符串使用，再分配600k的free空间在那。
  2. 惰性空间释放，当缩短sds的存储内容时，并不会立即使用内存重分配来回收字符串缩短后的空间，而是通过free将空闲的空间记录起来，等待将来使用。真正需要释放内存的时候，通过调用api来释放内存
  3. 通过空间预分配操作，redis有效的减少了执行字符串增长所需要的内存分配次数
  4. 如果修改后sds大于1MB时（也就是len的长度大于等于1MB），那么程序会分配1MB的未使用空间 例：字符串大小为3MB，那么会分配3MB给这个字符串使用，再分配1MB的free空间在那。

2，不同的编码实现

查看key的编码：object encoding key

1）int (REDIS_ENCODING_INT)整数值实现：
  存储的数据是整数时，redis会将键值设置为int类型来进行存储，对应的编码类型是REDIS_ENCODING_INT。
2）embstr(REDIS_ENCODING_EMBSTR)
  由sds实现 ，字节数 <= 39。存储的数据是字符串时，且字节数小于等于39 ，用的是embstr
优点：
1、创建字符串对象由两次变成了一次
2、连续的内存，更好的利用缓存优势
缺点：
1、由于是连续的空间，所以适合只读，如果修改的话，就会变成raw
2、由于是连续的空间，所以值适合小字符串

3）raw (REDIS_ENCODING_RAW)
  由sds实现。字节数 > 39

3.双向链表(LinkedList)

1，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;
其中:
	head：表头节点
	tail：表尾节点
	len：包含的节点数量
	(*dup)函数：节点值复制函数
	(*free)函数：节点值释放函数
	(*match)函数：节点值比较函数，比较值是否相等

2，ListNode链表节点结构：

typedef  struct listNode 
    struct listNode *prev;
    struct listNode *next;
    void *value;  
 listNode;
其中:
	prev：前置节点
	next：后置节点
	value：当前节点的值

3，linkedlist结构

拥有4个节点的linkedlist示意图如下:

4，总结：

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

4.压缩列表(zipList)

1，使用场景

  适用于长度较小的值，因为他是由连续的空间实现的。存取的效率高，内存占用小，但由于内存是连续的，在修改的时候要重新分配内存
在数据量比较小的时候使用的是ziplist
当list对象同时满足以下两个条件是，使用的ziplist编码

  1. list对象保存的所有字符串元素长度都小于64字节
  2. list对象保存的元素数量小于512个(redis版本3.2之前)之后是128个

2，ZipList结构

struct ziplist<T> 
    int32 zlbytes; // 整个压缩列表占用字节数
    int32 zltail_offset; // 最后一个元素距离压缩列表起始位置的偏移量，用于快速定位到最后一个节点
    int16 zllength; // 元素个数
    T[] entries; // 元素内容列表，挨个挨个紧凑存储
    int8 zlend; // 标志压缩列表的结束，值恒为 0xFF

  如果我们要查找定位第一个元素和最后一个元素，可以通过表头三个字段的长度直接定位，复杂度是 O(1)。而查找其他元素时，就没有这么高效了，只能逐个查找，此时的复杂度就是 O(N)

3，entry结构如下：

struct entry 
    int<var> previous_entry_length; //前一个entry的字节长度
    int<var> encoding; //当前元素编码类型
    optional byte[] content; //当前元素内容

  previous_entry__length记录前一个节点的长度，所以程序可以通过指针运算（当前节点的起始位置-previous_entry__length得到上一个节点的起始位置。），压缩列表从表尾遍历操作就是通过这个原理实现的。encoding属性记录节点的content属性所保存数据的类型以及长度。content保存节点的内容，可以是整数或者是字节数组。
  当前entry的总字节数 = 下一个entry的previous_entry_length的值 = previous_entry_length字节数 + encoding字节数 + content字节数

  • 如果前一节点的长度小于254字节，那么previous_entry__length属性的长度为1字节：前一节点的长度就保存在这一字节里面。
  • 如果前一节点的长度大于等于254字节，那么previous_entry__length属性的长度为5字节：其属性的第一字节会被设置为0xFE（十进制254），而之后的四个字节长度则用于保存前一节点的长度。

4，连锁更新

  连锁更新是由于previous_entry_length造成的。现在考虑这样一种情况：在一个压缩列表中，有多个连续的，长度介于250字节到253字节之间的节点e1-eN，如下图

  因为e1到eN的长度都介于250字节到253字节之间，所以它们的previous_entry__length均为1字节。现在将一个长度大于254字节的节点插入到e1前面，如下图：

  因为newE的长度大于254字节，所以他后面的e1的previous_entry__length长度需要从1字节变为5字节。但是由于e1原本的长度为250字节到253字节之间，这样子扩展后，长度必然超过254字节，就会导致后面的e2的previous_entry__length也需要改变…以此类推，后面的节点的previous_entry__length都需要扩展。Redis将这种特殊情况下产生的连续多次空间扩展操作称之为"连锁更新"。除了插入节点会发生"连锁更新"。删除节点也会，如下图：
  假设small及后面的节点的长度都介于250-253字节，big长度大于254字节，现在把samll删除了，导致e1的previous_entry__length需要扩展，后面依此类推，这样就会发生"连锁更新"。
  因为连锁更新在最坏的情况下需要对压缩列表执行N次空间重分配，而每次空间重分配的最坏复杂度为O(N)，所以连锁更新的最坏复杂度为O(N^2)

5.quickList类型

1，quicklist简介

  Redis 中的 list 数据类型在版本 3.2 之前，其底层的编码是 ziplist 和 linkedlist 实现的，但是在版本 3.2 之后，重新引入了一个 quicklist 的数据结构，list 底层都由 quicklist 实现。
  在早期的设计中， 当 list 对象中元素的长度比较小或者数量比较少的时候，采用 ziplist 来存储，当 list 对象中元素的长度比较大或者数量比较多的时候，则会转而使用双向列表 linkedlist 来存储。
  快速列表 quicklist 可以看成是用双向链表将若干小型的 ziplist 连接到一起组成的一种数据结构。
​
  说白了就是把 ziplist 和 linkedlist 结合起来。每个双链表节点中保存一个 ziplist，然后每个 ziplist 中存一批list 中的数据(具体 ziplist 大小可配置)，这样既可以避免大量链表指针带来的内存消耗，也可以避免 ziplist 更新导致的大量性能损耗，将大的 ziplist 化整为零。

2，zipList和linkedList的优缺点

  双端链表 linkedlist 便于在表的两端进行 push 和 pop 操作，在插入节点上复杂度很低，但是它的内存开销比较大。首先，它在每个节点上除了要保存数据之外，还要额外保存两个指针；其次，双向链表的各个节点是单独的内存块，地址不连续，节点多了容易产生内存碎片。
​
  压缩列表 ziplist 存储在一段连续的内存上，所以存储效率很高。但是，它不利于修改操作，插入和删除操作需要频繁的申请和释放内存。特别是当 ziplist 长度很长的时候，一次 realloc 可能会导致大批量的数据拷贝。
​
  因此，在 Redis3.2 以后，采用了 quicklist，quicklist 是综合考虑了时间效率与空间效率而引入的新型数据结构。

3，quickList的极端情况

情况一： 当 ziplist 节点过多的时候，quicklist 就会退化为双向链表。效率较差；效率最差时，一个 ziplist 中只包含一个 entry，即只有一个元素的双向链表。（增加了查询的时间复杂度）
情况二： 当 ziplist 元素个数过少时，quicklist 就会退化成为 ziplist，最极端的时候，就是 quicklist 中只有一个 ziplist 节点。（当增加数据时，ziplist 需要重新分配空间）
  所以说：quicklist 其实就是综合考虑了时间和空间效率引入的新型数据结构。（使用 ziplist 能提高空间的使用率，使用 linkedlist 能够降低插入元素时的时间）

4，quickList结构


  quicklist 作为一个链表结构，在它的数据结构中，是定义了整个 quicklist 的头、尾指针，这样一来，可以通过 quicklist 的数据结构，来快速定位到 quicklist 的链表头和链表尾。

typedef struct quicklist 
    quicklistNode *head;   // quicklist的链表头
    quicklistNode *tail;   // quicklist的链表尾
    unsigned long count;   // 所有ziplist中的总元素个数
    unsigned long len;     // quicklistNodes的个数
    int fill : QL_FILL_BITS;  // 单独解释
    unsigned int compress : QL_COMP_BITS; // 具体含义是两端各有compress个节点不压缩
    ...
 quicklist;

  fill用来指明每个quicklistNode中ziplist长度，当fill为正数时，表明每个ziplist最多含有的数据项数，当fill为负数时，如下：

  • Length -1: 4k，即ziplist节点最大为4KB
  • Length -2: 8k，即ziplist节点最大为8KB
  • Length -3: 16k …
  • Length -4: 32k
  • Length -5: 64k

  fill取负数时，必须大于等于-5。可以通过Redis修改参数list-max-ziplist-size配置节点所占内存大小。实际上每个ziplist节点所占的内存会在该值上下浮动。默认：list-max-ziplist-size -2

  考虑quicklistNode节点个数较多时，我们经常访问的是两端的数据，为了进一步节省空间，Redis允许对中间的quicklistNode节点进行压缩，通过修改参数list-compress-depth进行配置，即设置compress参数，该项的具体含义是两端各有compress个节点不压缩。默认：list-compress-depth 0

5，quickListNode结构

typedef struct quicklistNode 
    struct quicklistNode *prev;  //前一个quicklistNode
    struct quicklistNode *next;  //后一个quicklistNode
    unsigned char *zl;           //quicklistNode指向的ziplist
    unsigned int sz;             //ziplist的字节大小
    unsigned int count : 16;     //ziplist中的元素个数
    unsigned int encoding : 2;   //编码格式，1:原生字节数组，2:使用LZF压缩存储
    unsigned int container : 2;  //container为quicklistNode节点zl指向的容器类型：1代表none,2代表使用ziplist存储数据
    unsigned int recompress : 1; //代表这个节点之前是否是压缩节点，若是，则在使用压缩节点前先进行解压缩，使用后需要重新压缩，此外为1，代表是压缩节点；
    unsigned int attempted_compress : 1; //数据能否被压缩，测试时使用；
    unsigned int extra : 10;     //预留的bit位
 quicklistNode;

6，quickListEntry结构

typedef struct quicklistEntry 
    const quicklist *quicklist;//quicklist指向当前元素所在的quicklist;
    quicklistNode *node;//node指向当前元素所在的quicklistNode结构；
    unsigned char *zi;//zi指向当前元素所在的ziplist;
    unsigned char *value;//value指向该节点的字符串内容；
    long long longval;//为该节点的整型值；
    unsigned int sz;//代表该节点的大小，与value配合使用；
    int offset;//明该节点相对于整个ziplist的偏移量，即该节点是ziplist第多少个entry
 quicklistEntry;

7，quicklistIter结构

在redis的quicklist结构中，实现了自己的迭代器，用于遍历节点。

//quicklist的迭代器结构
typedef struct quicklistIter 
    const quicklist *quicklist;//指向所属的quicklist的指针
    quicklistNode *current;//指向当前迭代的quicklist节点的指针
    unsigned char *zi;//指向当前quicklist节点中迭代的ziplist
    long offset; //当前ziplist结构中的偏移量      /* offset in current ziplist */
    int direction;//迭代方向
 quicklistIter;

8，数据压缩

quicklist每个节点的实际数据存储结构为ziplist，这种结构的主要优势在于节省存储空间。为了进一步降低ziplist所占用的空间，Redis允许对ziplist进一步压缩，Redis采用的压缩算法是LZF，压缩过后的数据可以分成多个片段，每个片段有2部分：

  • 一部分是解释字段，另一部分是存放具体的数据字段。
  • 解释字段可以占用1～3个字节，数据字段可能不存在。

解释字段|数据|…|解释字段|数据

LZF压缩的数据格式有3种，即解释字段有3种：

  1. 000LLLLL：字面型，解释字段占用1个字节，数据字段长度由解释字段后5位决定；L是数据长度字段，数据长度是长度字段组成的字面值加1。例如：0000 0001代表数据长度为2
  2. LLLooooo oooooooo：简短重复型，解释字段占用2个字节，没有数据字段，数据内容与前面数据内容重复，重复长度小于8；L是长度字段，数据长度为长度字段的字面值加2, o是偏移量字段，位置偏移量是偏移字段组成的字面值加1。例如：0010 0000 0000 0100代表与前面5字节处内容重复，重复3字节。
  3. 111ooooo LLLLLLLL oooooooo：批量重复型，解释字段占3个字节，没有数据字段，数据内容与前面内容重复；L是长度字段，数据长度为长度字段的字面值加9, o是偏移量字段，位置偏移量是偏移字段组成的字面值加1。例如：1110 0000 0000 0010 0001 0000代表与前面17字节处内容重复，重复11个字节。
//quicklistLZF结构：
typedef struct quicklistLZF 
    unsigned int sz;//该压缩node的的总长度
    char compressed[];//压缩后的数据片段(多个)，每个数据片段由解释字段和数据字段组成
 quicklistLZF;

//当前ziplist未压缩长度存在于quicklistNode->sz字段中
//当ziplist被压缩时，node->zl字段将指向quicklistLZF

1）压缩：
  LZF数据压缩的基本思想是：数据与前面重复的，记录重复位置以及重复长度，否则直接记录原始数据内容。
  压缩算法的流程如下：遍历输入字符串，对当前字符及其后面2个字符进行散列运算，如果在Hash表中找到曾经出现的记录，则计算重复字节的长度以及位置，反之直接输出数据。

/*
 * compressed format
 *
 * 000LLLLL <L+1>    ; literal, L+1=1..33 octets
 * LLLooooo oooooooo ; backref L+1=1..7 octets, o+1=1..4096 offset
 * 111ooooo LLLLLLLL oooooooo ; backref L+8 octets, o+1=1..4096 offset
 */
unsigned int
lzf_compress (const void *const in_data, unsigned int in_len, void *out_data, unsigned int out_len)

2)解压缩
  根据LZF压缩后的数据格式，可以较为容易地实现LZF的解压缩。需要注意的是，可能存在重复数据与当前位置重叠的情况，例如在当前位置前的15个字节处，重复了20个字节，此时需要按位逐个复制。

unsigned int
lzf_decompress (const void *const in_data, unsigned int in_len, void *out_data, unsigned int out_len)

9，基本操作

1）插入元素
  API定义：

/* Insert a new entry before or after existing entry 'entry'.
 *
 * If after==1, the new value is inserted after 'entry', otherwise
 * the new value is inserted before 'entry'. */
REDIS_STATIC void _quicklistInsert(quicklist *quicklist, quicklistEntry *entry, void *value, const size_t sz, int after)

  其中，参数after用于控制在entry之前或者之后插入。正因为 quicklist 采用了链表结构，所以当插入一个新的元素时，quicklist 首先就会检查插入位置的 ziplist 是否能容纳该元素，这是通过 _quicklistNodeAllowInsert 函数来完成判断的。

REDIS_STATIC int _quicklistNodeAllowInsert(const quicklistNode *node,
                                           const int fill, const size_t sz) 
    if (unlikely(!node))
        return 0;

    int ziplist_overhead;
    /* size of previous offset */
    if (sz < 254)
        ziplist_overhead = 1;
    else
        ziplist_overhead = 5;

    /* size of forward offset */
    if (sz < 64)
        ziplist_overhead += 1;
    else if (likely(sz < 16384))
        ziplist_overhead += 2;
    else
        ziplist_overhead += 5;

    /* new_sz overestimates if 'sz' encodes to an integer type */
    unsigned int new_sz = node->sz + sz + ziplist_overhead;
    if (likely(_quicklistNodeSizeMeetsOptimizationRequirement(new_sz, fill)))
        return 1;
    else if (!sizeMeetsSafetyLimit(new_sz))
        return 0;
    else if ((int)node->count < fill)
        return 1;
    else
        return 0;

  _quicklistNodeAllowInsert 函数会计算新插入元素后的大小（new_sz），这个大小等于 quicklistNode 的当前大小（node->sz）、插入元素的大小（sz），以及插入元素后 ziplist 的 prevlen 占用大小。在计算完大小之后，_quicklistNodeAllowInsert 函数会依次判断新插入的数据大小（sz）是否满足要求，即单个 ziplist 是否不超过 8KB，或是单个 ziplist 里的元素个数是否满足要求。
  只要这里面的一个条件能满足，quicklist 就可以在当前的 quicklistNode 中插入新元素，否则 quicklist 就会新建一个 quicklistNode，以此来保存新插入的元素。这样一来，quicklist 通过控制每个 quicklistNode 中，ziplist 的大小或是元素个数，就有效减少了在 ziplist 中新增或修改元素后，发生连锁更新的情况，从而提供了更好的访问性能。

2）删除元素：
quicklist对于元素删除提供了删除单一元素以及删除区间元素2种方案。
  1]:删除单一元素 :可以使用quicklist对外的接口quicklistDelEntry实现，也可以通过quicklistPop将头部或者尾部元素弹出。quicklistDelEntry函数调用底层quicklistDelIndex函数，该函数可以删除quicklistNode指向的ziplist中的某个元素，其中p指向ziplist中某个entry的起始位置。
  quicklistPop可以弹出头部或者尾部元素，具体实现是通过ziplist的接口获取元素值，再通过上述的quicklistDelIndex将数据删除

void quicklistDelEntry(quicklistIter *iter, quicklistEntry *entry) 
    quicklistNode *prev = entry->node->prev;
    quicklistNode *next = entry->node->next;
    // 底层仍然通过quicklistDelIndex删除
    int deleted_node = quicklistDelIndex((quicklist *)entry->quicklist,
                                         entry->node, &entry->zi);

    /* after delete, the zi is now invalid for any future usage. */
    iter->zi = NULL;

    /* If current node is deleted, we must update iterator node and offset. */
    if (deleted_node) 
        if (iter->direction == AL_START_HEAD) 
            iter->current = next;
            iter->offset = 0;
         else if (iter->direction == AL_START_TAIL) 
            iter->current = prev;
            iter->offset = -1;

  2]:删除区间元素 :quicklist提供了quicklistDelRange接口，该函数可以从指定位置删除指定数量的元素

int quicklistDelRange(quicklist *quicklist, const long start, const long count)

  start为需要删除的元素的起始位置，count为需要删除的元素个数。返回0代表没有删除任何元素，返回1并不代表删除了count个元素，因为count可能大于quicklist所有元素个数，故而只能代表操作成功。

总体删除逻辑为： 不管什么方式删除，最终都会通过ziplist来执行元素删除操作。先尝试删除该链表节点所指向的ziplist中的元素，如果ziplist中的元素已经为空了，就将该链表节点也删除掉。
3) 更改元素：
  quicklist更改元素是基于index，主要的处理函数quicklistReplaceAtIndex。其基本思路是先删除原有元素，之后插入新的元素。quicklist不适合直接改变原有元素，主要由于其内部是ziplist结构，ziplist在内存中是连续存储的，当改变其中一个元素时，可能会影响后续元素。故而，quicklist采用先删除后插入的方案。

/* Replace quicklist entry at offset 'index' by 'data' with length 'sz'.
 *
 * Returns 1 if replace happened.
 * Returns 0 if replace failed and no changes happened. */
int quicklistReplaceAtIndex(quicklist *quicklist, long index, void *data,
                            int sz) 
    quicklistEntry entry;
    if (likely(quicklistIndex(quicklist, index, &entry))) 
        /* quicklistIndex provides an uncompressed node */
        entry.node->zl = ziplistDelete(entry.node->zl, &entry.zi);
        entry.node->zl = ziplistInsert(entry.node->zl, entry.zi, data, sz);
        quicklistNodeUpdateSz(entry.node);
        quicklistCompress(quicklist, entry.node);
        return 1;
     else 
        return 0;

4）查找元素：
  quicklist查找元素主要是针对index，即通过元素在链表中的下标查找对应元素。基本思路是，首先找到index对应的数据所在的quicklistNode节点，之后调用ziplist的接口函数ziplistGet得到index对应的数据，源码中的处理函数为quicklistIndex。

int quicklistIndex(coquicklistnst quicklist *quicklist, const long long idx,
                   quicklistEntry *entry) 
    quicklistNode *n;
    unsigned long long accum = 0;
    unsigned long long index;
    int forward = idx < 0 ? 0 : 1; /* < 0 -> reverse, 0+ -> forward */
    
    ... 
    
    // 这里是在定位具体是在哪个quicklist节点
    while (likely(n)) 
        if ((accum + n->count) > index) 
            break;
         else 
            D("Skipping over (%p) %u at accum %lld", (void *)n, n->count,
              accum);
            accum += n->count;
            n = forward ? n->next : n->prev;
        
    

    ... 
    
    // 最终还是利用ziplist获取元素
    ziplistGet(entry->zi, &entry->value, &entry->sz, 
    参考技术A
            
 我们都知道， Redis 是由 C 语言编写的。在 C 语言中，字符串标准形式是以空字符 \\0 作为结束符的，但是 Redis 里面的字符串却没有直接沿用 C 语言的字符串。主要是因为 C 语言中获取字符串长度可以调用 strlen 这个标准函数，这个函数的时间复杂度是 O(N) ，由于 Redis 是单线程的，承受不了这个时间复杂度。
  
 在上一篇文章中，我们介绍了 Redis 的 RedisObject 的数据结构，如下所示：
  
 对于不同的对象， Redis 会使用不同的类型来存储。对于同一种类型 type 会有不同的存储形式 encoding 。对于 string 类型的字符串，其底层编码方式共有三种，分别为 int 、 embstr 和 raw 。
  
 使用 object encoding key 可以查看 key 对应的 encoding 类型，如下所示：
                                          
 对于 embstr 和 raw 这两种 encoding 类型，其存储方式还不太一样。对于 embstr 类型，它将 RedisObject 对象头和 SDS 对象在内存中地址是连在一起的，但对于 raw 类型，二者在内存地址不是连续的。
                                          
 在介绍 string 类型的存储类型时，我们说到，对于 embstr 和 raw 两种类型其存储方式不一样，但 ptr 指针最后都指向一个 SDS 的结构。那什么是 SDS 呢？ Redis 中的字符串称之为 Simple Dynamic String ，简称为 SDS 。与普通 C 语言的原始字符串结构相比， sds 多了一个 sdshdr 的头部信息， sdshdr 基本数据结构如下所示：
  
 可以看出， SDS 的结构有点类似于 Java 中的 ArrayList 。 buf[] 表示真正存储的字符串内容， alloc 表示所分配的数组的长度， len 表示字符串的实际长度，并且由于 len 这个属性的存在， Redis 可以在 O(1) 的时间复杂度内获取数组长度。
  
 为了追求对于内存的极致优化，对于不同长度的字符串， Redis 底层会采用不同的结构体来表示。在 Redis 中的 sds.h 源码中存在着五种 sdshdr ，分别如下：
  
 上面说了， Redis 底层会根据字符串的长度来决定具体使用哪种类型的 sdshdr 。可以看出， sdshdr5 明显区别于其他四种结构，它一般只用于存储长度不会变化，且长度小于32个字符的字符串。但现在一般都不再使用该结构， 因为其结构没有 len 和 alloc 这两个属性,不具备动态扩容操作 ，一旦预分配的内存空间使用完，就需要重新分配内存并完成数据的复制和迁移，类似于 ArrayList 的扩容操作，这种操作对性能的影响很大。
  
 上面介绍 sdshdr 属性的时候说过， flag 这个属性用于标识使用哪种 sdshdr 类型， flag 的低三位标识当前 sds 的类型，分别如下所示：
  
 同时，注意到在每个 sdshdr 的头定义上都有一个 attribute((packed)) ，这个是为了告诉 gcc  取消优化对齐 ，这样，每个字段分配的内存地址就是 紧紧排列在一起的 ， Redis 中字符串参数的传递直接使用 char* 指针，其实现原理在于，由于 sdshdr 内存分配禁止了优化对齐，所以 sds[-1] 指向的就是 flags 属性的内存地址，而通过 flags 属性又可以确定 sdshdr 的属性，进而可以读取头部字段确定 sds 的相关属性。
  
 sds的逻辑图如下所示：
                                          
 相比较于 C 语言原始的字符串， sdshdr 的具备一些优势。
  
 由于 sdshdr 中存在 len 这个属性，所以可以在 O(1) 的时间复杂度下获得长度；而传统的 C 语言得使用 strlen 这个标准函数获取，时间复杂度为 O(N) 。
  
 原始的 C 语言一直使用与长度匹配的内存，这样在追加字符串导致字符串长度发生变化时，就必须进行内存的重新分配。内存重新分配涉及到复杂算法和系统调用，耗费性能和时间。对于 Redis 来说，它是单线程的，如果使用原始的字符串结构，势必会引发频繁的内存重分配，这个显然是不合理的。
  
 因而， sds 每次进行内存分配时，都会通过内存的预分配来减少因为修改字符串而引发的内存重分配次数。这个原理可以参数 Java 中的 ArrayList ，一般在使用 ArrayList 时都会建议使用带有容量的构造方式，这样可以避免频繁 resize 。
  
 对于 SDS 来说，当其使用 append 进行字符串追加时，程序会用  alloc-len 比较下剩下的空余内存是否足够分配追加的内容 ，如果不够自然触发内存重分配，而如果剩余未使用内存空间足够放下，那么将直接进行分配，无需内存重分配。其扩容策略为， 当字符串占用大小小于1M时，每次分配为 len  * 2，也就是保留100%的冗余；大于1M后，为了避免浪费，只多分配1M的空间。 
  
 通过这种预分配策略， SDS 将连续增长 N 次字符串所需的内存重分配次数 从必定 N 次降低为最多 N 次。 
  
  缓冲区溢出是指当某个数据超过了处理程序限制的范围时，程序出现的异常操作。 原始的 C 语言中，是由编码者自己来分配字符串的内存，当出现内存分配不足时就会发生 缓存区溢出 。而 sds 的修改函数在修改前会判断内存，动态的分配内存，杜绝了 缓冲区溢出 的可能性。
  
 对于原始的 C 语言字符串来说，它会通过判断当前字符串中是否存在空字符 \\0 来确定是否已经是字符串的结尾。因而在某些情况下，如使用空格进行分割一段字符串时，或者是图片或者视频等二进制文件中存在 \\0 等，就会出问题。而 sds 不是通过空字符串来判断字符串是否已经到结尾，而是通过 len 这个字段的值。所以说， sds 还具备 二进制安全 这个特性，即可以安全的存储具有特殊格式的二进制数据。
                                          
  https://www.cnblogs.com/reecelin/p/13358432.html 
	

            
以上是关于Redis之底层数据结构的主要内容，如果未能解决你的问题，请参考以下文章
 

 Redis数据结构之简单动态字符串SDS


 Redis数据结构之简单动态字符串SDS


 Redis底层探秘：简单动态字符串(SDS)


 Redis数据结构之字典


 redis五种数据结构与六种底层实现


 redis一次访问耗时