Redis底层数据结构

一. 常见数据结构的底层数据结构

1. 动态字符串SDS（Simple Dynamic String）

为什么要这样设计呢？为什么不用c语言的字符串呢?

• 保证二进制安全且无需遍历数组获取长度
  c语言没有字符串，是靠字符数组实现的，并且以“ \0 ”作为结束标志，但是如果数据中间存在结束字符会导致读取数据不全的问题，所以引入len变量来保存字符数量，以len作为标准去读取数据，同时无需遍历数组获取长度（len）
• 动态扩容
  

2. IntSet
本质是一个动态有序的整数数组。

encoding表示编码方式，数组中的数据就按照该编码方式存储。

如果数据超过了编码的范围怎么办呢？

如何确保有序呢? 底层如何查找的呢?

3. Dict(dictionary)
3.1组成
和java中jdk1.7版本的HashMap底层数据结构十分相似，由三部分组成：hash表（数组），哈希节点（entry）、字典（Dict）

每个Dict有两个hashTable一个用于存储当前数据，一个用于rehash（后续详细介绍）。
每个hashTable（dictHT）存储entry的指针以及hash表大小和entry个数，其中有一个sizemask用于进行hash求索引比如n&sizemask等价于n%size（sizemask+1），&运算速率更加快。
当发生hash碰撞的时候就是key运算后索引相同则使用单向链表，进行前插法添加新元素。

3.2 扩容

3.3 收缩
hashTable默认size为4，怎么收缩都不能低于4。
收缩后的size为大于等于实际entry个数的最小2的n次方（5->8）

3.4 rehash

因为一次新增的数据太多，导致rehash一次性更新到新的hashTable时长太长而影响其他业务性能，所以每次执行增删改查的时候才会去更新一个索引的数据，直到结束为止。

4.ZipList

为什么不使用相同内存存储entry呢？
回答：之所以叫压缩列表，就是因为去除了链表中的指针（一个指针8字节），并且每个entry由实际内容决定，节省了大批内存空间。

在遍历的时候，无需使用链表的指针来获取前一个元素和下一个元素，而是根据previous_enrty_length计算前一个entry的起始地址，通过自身大小计算下一节点地址。


连锁更新问题

如果这个时候插入一个节点并且长度大于254，将会导致pre_enrty_length属性由1字节变成5字节导致后面的该属性全部连锁更新为5字节。
(该情况发生概率很低)

总结特性

• 可以看成一种连续空间的"双向链表" ，首尾操作简单
• 节点之间不通过指针连接，记录上一节点和本节点长度寻址，节省内存
• 如果节点数量过多，导致链表过长，需要逐个遍历，查询效率不高
• 增删大数据时可能发生连续更新问题

5. QuickList
上面说到ZipList的致命缺点：空间连续，如果数据过多，申请效率会变低，查询效率也下降，如何解决呢？

• 可以通过限制ZipList的长度和entry大小
• 对于大量的数据进行分片，多个ZipList存储
• 多个ZipList进行联系，引入主角：QuickList
  5.1 组成
  QuickList本质是一个双端链表，但是每个节点指向ZipList，使得ZipList们联系起来。
  

config get list-max-ziplist-size 

config get list-compress-depth 

5.2 底层源码（结合组成示意图理解）

5.3 特点总结

• 是一个节点为ZipList的双端链表
• 节点采用ZipList，解决了传统链表的内存占用问题（指针）
• 控制了ZipList的大小，解决申请效率的问题
• 中间节点可以进一步压缩，进一步节省内存空间。

6.SkipList
上面聊了这么多链表，其实都没看到怎么去解决快速查找中间节点的问题，这里引入的SkipList就优化了链表中元素查找效率。

它和其他传统链表不同：1、元素按升序排列（也是方便后续的查找）
根据score值进行排序

2、节点可能包含多个指针，跨度不一样（加速查找效率，跳表的来源）
上源码：是个双向链表，每个节点值是SDS，整个排序考score，然后就是前后指针，由于增序，所以多级指针体现在forword（向后），跨度不一所以使用数组存储。

示意图

特点总结：

• 双向链表，每个节点都含score和ele值
  -节点按score排序，score值相同则按 ele字典排序（字符串）
• 每个节点可包含多级指针，1-32之间
• 指针层级越高，跨度越大
• 增删修改效率和红黑树 基本一致，实现却简单