动态字符串SDS
Redis保存的Key是字符串，value往往是字符串或者字符串的集合。可见字符串是Redis中最常用的一种数据结构。不过Redis没有直接使用C语言中的字符串，因为C语言字符串存在很多问题：
- 获取字符串长度需要进行一个运算
- 非二进制安全
- 不可修改
Redis构建一种新的字符串结构，称为简单动态字符串，简称SDS
Redis是由C语言实现的，其中SDS是一个结构体，源码如下：
例如：一个包含字符串“name”的sds结构如下：
SDS之所以叫动态字符串，是因为它具备动态扩容的能力。
如果我们要给SDS追加一段字符串，首先就会申请新的内存空间：
- 如果新字符串小于1M，则新空间拓展后字符串长度的二倍+1 （+1是因为C语言的结尾为\0）
- 如果新字符串大于1M，则新空间为拓展后字符串长度+1M+1.
这种方式称之为预分配
追加“，Amy”后：
优点：
- 获取字符串长度的时间复杂度为O(1)
- 支持动态扩容
- 减少内存分配次数
- 二进制安全
IntSet
IntSet是Redis中Set集合的一种实现方式，基于整数数组来实现，具备长度可变、有序等特征
结构如下：
其中encoding 包括三种模式，表示存储的整数大小不同：
为了方便查找，Redis会将intset中所有的整数按照升序一次保存在contents数组中，结果如图：
当我们想intset添加一个超出范围的数，那么intset就会自动升级编码方式到合适的大小。
流程如下：
- 进行计算，升级到合适的编码，并按照新的编码方式及元素个数扩容数组
- 倒叙依次将数组中的元素拷贝到扩容后的正确位置。倒序是为了防止被覆盖
- 将待添加的元素放入数组末尾
- 最后，将intset的encoding属性进行更改，同时将数组长度也进行一个修改
IntSet可以看作是特殊的整数数组，具备以下特征：
- Redis会确保IntSet中的元素唯一、游戏
- 具备类型升级机制，可以节省内存空间
- 底层采用二分查找方式进行查询
在数据量不多的情况下使用效果更好
Dict
Redis是键值对型的数据库，我们可以根据键进行快速的增删改查，而键与值的映射关系正是通过Dict来实现的
DIct由三部分组成，分别是：哈希表（DictHashTable）、哈希节点（DictEntry）、字典（Dict）
源码：
当我们想Dict添加键值对时，Redis首先根据Key计算出hash值，然后利用h&sizemask来计算元素应该存到数组的那个索引位置。我们存储k1=v1，假设k1的哈希值h=1，则1&3=1，因此k1=v1要存在到数组角标为1的位置
Dict扩容
Dict的HashTable就是数组结合单向链表的实现，当集合中元素较多时，必然导致哈希冲突增多，链表过长，则查询效率大大降低。
Dict在每次新增键值对时都会检查负载因子（LoadFactor=used/size），满足一下两种情况会触发哈希表扩容：
- 哈希表的LoadFactor>=1，并且服务器没有执行BGSAVE或者BGREWARITEAOF等后台操作
- 哈希表的LoadFactor>5
Dict收缩
Dict出了扩容以外，当删除元素的时会对负载因子进行一个检查，当LoadFactor(负载因子)<0.1时，会进行一个收缩
Dict的rehash
不管是扩容还是收缩，必定会创建新的哈希表，导致哈希表的size和sizemask发生变化，而key的查询与sizemask有关。因此必须对哈希表的每一个key重新计算索引，插入新的哈希表，这个过程称之为rehash，
Dict的rehash不是一次性完成的，如果Dict中包含数百万的entry，要再一次rehash完成，极可能导致主线程阻塞，因此Dict的rehash是分多次、渐进式的完成，因此被称之为渐进式rehash
过程：
- 计算新hash表的realeSize，值取决于当前要做的是扩容还是收缩
- 如果是扩容，则新size为第一个大于等于dict.ht[0].used +1 的2^n
- 如果是收缩，则新size为第一个大于等于dict.ht[0].used的2^n（不得小于4）
- 按照新的realesize申请内存空间，创建dictht，并赋值给dict.ht[1]
- 设置dict.rehashindex=0,标识开始rehash
将dict.ht[0]中的每一个dictEntry都rehash到dict.ht[1]
每次执行新增、查询、修改、删除操作时，都检查一下dict.rehashidx是否大于-1，如果是则将dict.ht[0].table[rehashidx]的entry链表rehash到dict.ht[1]，并将rehashidx++。直至dict.ht[0]的所有数据都rehash到dict.ht[1]- 将dict.ht[1]赋值给dict.ht[0],给dict.ht[1]初始化为空哈希表，释放原来dict.ht[0]的内存
- 将rehashidx赋值为-1，标识rehash结束
- 在rehash过程中新增操作，则直接写入ht[1]，查询、修改和删除则会在dict.ht[0]和dict.ht[1]一次查找并执行，这样子可以确保ht[0]的数据只减不增，随着rehash最终为空
ZipList
ZipList是一种特殊的双端链表，有一系列特殊编码的连续内存块组成，可以在任意一端进行压入/弹出操作，并且该操作的时间复杂度为O(1)
大致结构（Redis 6 ）
| 属性 | 类型 | 长度 | 用途 |
|---|---|---|---|
| zlbytes | uint32_t | 4字节 | 记录整个压缩列表占用的内存字节数 |
| zltail | uint32_t | 4字节 | 记录压缩链表表为节点距离压缩列表的起始地址有多少字节，通过这个偏移量，可以确定表尾节点的地址 |
| zllen | uint16_t | 2字节 | 记录了压缩列表包含的节点数量，最大值为UINT16_MAX(65534),如果超出了这个值，此处会记录为65535，单结点的真实数据需要遍历整个压缩列表才能计算出来 |
| entry | 列表节点 | 不定 | 压缩列表包含的各个节点，结点的长度由节点保存的内容决定 |
| zlend | uint8_t | 1字节 | 特殊值0xff(十进制255)，用于标记压缩列表的末端 |
ZipListEntry
ZipList中的Entry并不像普通链表那样记录前后节点的指针，因为记录两个指针要占用16字节，浪费内存，而是采用了这种结构：
- previous_entry_length：前一节点的长度，占1个或者5个字节
- 如果前一个结点的长度小于254，则采用1个字节来保存这个长度值
- 如果前一节点的长度大于254，则采用5个节点来保存这个长度值，第一个字节为0xfe,后四个字节才是真实长度数据
- encoding：编码属性，记录content的数据类型（是字符串还是证书）以及长度，占用1/2/5个字节
- contents：负责保存节点的数据，可以是字符串或者整数
Encoding编码
ZipListEntry中的encoding编码分别为字符串和整数两种：
- 字符串：如果encoding是以“00”、“01”或者“10”开头的，证明content是字符串
- 整数：如果encoding是以“11”开始，则证明content是整数，且encoding固定只占用1个字节
ZipList的连锁更新问题
ZipList的每个Entry都包含previous_entry_length来记录上一个节点的大小，长度是1个或者5个字节
- 如果前一节点的长度小于254，则采用1个字节来保存这个长度值
- 如果前一节点的长度大于254，则采用5个字节来保存这个长度，第一个字节为0xfe，后面4个字节才是真是长度数据
假设有N个连续的、长度为250~253字节之间的entry，因此entry的previous_entry_length属性用1个字节即可标识：
ZipList这种特殊情况下产生的连续多次空间拓展称之为连锁更新，新增、删除都可能导致连锁更新的发生
QuickList
ZipList存在这部分问题：
-
ZipList虽然节省内存，但申请内存必须是连续空间，如果内存占用较多，申请内存效率很低怎么办？
为了缓解这个问题，我们必须限制ZipList的长度和entry大小
-
我们要存储大量数据，超出了ZipList的最佳上限怎么办？
可以创建多个ZipList来分片存储数据
-
数据拆分后比较分散，不方便管理和查找，这多个ZipList如何建立联系？
Redis在3.2版本引入了新的数据结构QuickList，他是一个双端链表，不过链表的每个节点都是一个ZipList
为了避免QuickList中的每个ZipList中entry过多，Redis提供了一个配置项：list-max-ziplist-size来进行限制
-
如果为正：则代表ZipList的允许的个数的最大值
-
如果为负，则代表ZipList的最大内存大小，分为5中
- -1 ：每个ZipList的内存不超过4kb
- -2：每个ZipList的内存不超过8kb
- -3 : 每个ZipList的内存不超过16kb
- -4 : 每个ZipList的内存不超过32kb
- -5 : 每个ZipList的内存不超过64kb
默认为-2
出了控制ZipList的大小，QuickList还可以对节点的ZipList做压缩，通过配置项list-compress-depth来控制。因为链表一般都是从首尾访问比较多，所以首尾不是压缩的，这个参数是控制首尾不压缩的节点个数
- 0：特殊值，标识不压缩
- 1：表示QuickList的首位各有1个节点不压缩，中间节点压缩
- 2：表示QuickList的首位各有2个节点不压缩，中间节点压缩
- 以此类推
默认值 0, 表示不压缩：
源码：
内存结构图：
特点：
- 是一个节点为ZipList的双端链表
- 节点采用ZipList，解决了传统链表的内存占用问题
- 控制了ZipList大小，解决连续内存空间申请效率问题
- 中间节点可以压缩，进一步节省了内存
SkipList
SkipList(跳表)首先是链表，但是与传统的链表相比有几点差异：
- 元素按照升序排列存储
- 节点可能包含多个指针，指针跨度不同
为了加快查询速率，在这里使用了指针，指针最多存在32级，32级相当于最多可以存储2^31次方个数
内存结构图：
特点：
- 跳跃表是一个双向链表，每个节点都包含一个score和ele值
- 节点按照score值进行排序，score值一样则按照ele字典排序
- 每个节点都可以包含多层指针，层数是1~32之间的随机数
- 不同层指针到一个结点的跨度不同，层级越高，跨度越大
- 增上改查效率与红黑树基本一致，实现却更简单
RedisObject
Redis中任意数据类型的键和值都会被封装为一个RedisObject，也叫做Redis对象，源码如下：
11种编码格式：
| 编号 | 编码方式 | 说明 |
|---|---|---|
| 0 | OBJ_ENCODING_RAW | raw编码动态字符串 |
| 1 | OBJ_ENCODING_INT | long类型的整数的字符串 |
| 2 | OBJ_ENCODING_HT | hash表(字典Dict) |
| 3 | OBJ_ENCODING_ZIPMAP | 已废弃 |
| 4 | OBJ_ENCODING_LINKEDLIST | 双端链表 |
| 5 | OBJ_ENCODING_ZIPLIST | 压缩列表 |
| 6 | OBJ_ENCODING_INTSET | 整数集合 |
| 7 | OBJ_ENCODING_SKIPLIST | 跳表 |
| 8 | OBJ_ENCODING_EMBSTR | embstr的动态字符串 |
| 9 | OBJ_ENCODING_QUICKLIST | 快速列表 |
| 10 | OBJ_ENCODING_STREAM | Stream流 |
五种数据结构：
Redis种会根据存储的数据类型不同，选择不同的编码方式，每种数据类型的使用的编码方式如下：
| 数据类型 | 编码方式 |
|---|---|
| OBJ_STRING | int 、embstr、raw |
| OBJ_LIST | LinkedList和ZipList（3.2之前）、QuickList(3.2之后) |
| Obj_SET | intset、ht |
| OBJ_ZSET | ZipList、HT、SkipList |
| OBJ＿HASH | ZipList、HT |
String
String是Redis种最常用的数据类型：
- 其基本编码方式为RAW，基于简单动态字符串(SDS)实现的，存储上限为512MB
- 如果存储的SDS长度小于44字节，则会采用EMBSTR编码，此时ObjectHead与SDS是一段连续空间，申请内存是只需要调用一次内存分配函数，效率更高
- 如果存储的字符串是整数值，并且大小在LONG_MAX范围内，则会采用INT编码：直接将数据保存在RedisObject的pre指针位置，刚好8字节，就不再需要SDS了
String的内存结构图：
List
Redis的List类型可以从首尾操作列表中的元素
满足这种特征的数据结构有：
- LinkedList：普通链表，可以从双端进行访问，内存占用较高，内存碎片较多
- ZipList：压缩列表，可以从双端访问，内存占用低，存储上限低
- QuickList：底层结构是LinkedList+ZipList，可以从双端访问，内存占用比较低，包含多个ZipList，存储上限高
3.2版本之前，Redis采用ZipList和LinkedList来实现List，当元素数量小于512且元素大小小于64字节时采用ZipList编码，超过则采用LinkedList编码。
3.2版本之后，Redis统一采用QuickList实现List
数据结构：
Set
Set时Redis种的单列集合，满足下列特点：
- 不保证元素有序性
- 保证元素唯一性（可以判断元素是否已经存在）
- 求交集、并集、差集
Set是Redis中的集合，不一定确保元素游戏，可以满足元素唯一，查询效率要求极高
- 为了查询效率和唯一性，Set采用HT编码（DICT），DICT中的Key用来存储元素，value统一为null；
- 当存储的所有数据都是整数，并且元素数量不超过set-max-insert-entries是，Set会采用IntSet编码，以节省内存
ZSet
Zset也就是SortedSet，其中每一个元素都需要制定一个score值和member值
- 可以根据score值排序
- member必须唯一
- 可以根据member查询分数
因此，zset底层数据结构必须满足键值存储、键必须唯一、可排序这几个需求，可以考虑到的数据结构有：
- SkipList：可以排序，并且可以同时存储score和ele值（member），能够实现键值存储和可排序，但是键唯一性查询效率极低
- HT（DICT）：可以键值存储，并且可以根据key找到value；能够满足键值对存储和高效的查询，但是不能够实现可排序这一特点
实际上ZSet在底层使用的是HT和SkipList二者结合的方式。
但是这种方式会存在大量的指针和冗余数据，会导致内存的极大浪费。因此ZSet还会采用ZipList结构来节省内存，不过需要同时满足两个条件：
- 元素数量小于zset_max_ziplist_entries，默认128
- 每个元素都小于zset_max_ziplist_value字节，默认为64
ZipList本身没有排序功能，而且没有键值对的概念，因此需要有zset通过编码实现：
- ZipList是连续内存，因此score和element是仅仅挨在一起的两个entry，element在前，score灾后
- score越小越接近对手，score越大越接近对位，按照score的值升序排列
Hash
Hash结构与Redis中的Zset非常类似：
- 都是键值存储
- 都要求根据键获取值
- 键必须唯一
ZSet与Hash的区别：
- Zset的键是member ，值是score，hash的键和值都是任意值
- zset要根据score排序，hash则无需排序
因此，Hash底层采用的编码与ZSet基本一只，只需要把排序有关的SkipList去掉即可
- Hash结构默认采用ZipList编码，用以节省内存，ZipList种相邻的两个entry分别保存field和value
- 当数据量较大时，Hash结构会转为HT编码，也就是Dict，触发条件有两个：
- ZipList中的元素数量超过了hash-max-ziplist-entries(默认512)
- ziplist种的任意entry大小超过了hash-max-value（默认64字节）
