【深入理解redis】数据结构
文章目录
- 动态字符串SDS
-
- 字符串编码类型
- intset
- Dict
- ZipList
-
- ZipList的连锁更新问题
- QuickList
- SkipList
- RedisObject
- String
- List
- Set结构
- ZSET
- Hash
Redis 共有 5 种基本数据结构：String（字符串）、List（列表）、Set（集合）、Hash（散列）、Zset（有序集合）。
这 5 种数据结构是直接提供给用户使用的，是数据的保存形式，其底层实现主要依赖这 8 种数据结构：简单动态字符串（SDS）、LinkedList（双向链表）、Hash Table（哈希表）、SkipList（跳跃表）、Intset（整数集合）、ZipList（压缩列表）、QuickList（快速列表）。
Redis 基本数据结构的底层数据结构实现如下：
Redis 3.2 之前，List 底层实现是 LinkedList 或者 ZipList。 Redis 3.2 之后，引入了 LinkedList 和 ZipList 的结合 QuickList，List 的底层实现变为 QuickList。
动态字符串SDS
我们都知道Redis中保存的Key是字符串，value往往是字符串或者字符串的集合。可见字符串是Redis中最常用的一种数据结构。
Redis是使用C语言编写的，不过Redis没有直接使用C语言中的字符串，因为C语言字符串存在很多问题：
- 获取字符串长度的需要通过运算
- 非二进制安全
- 不可修改
所谓字符串的二进制安全性，是指字符串中可以包含任意的数据，包括’\0’字符，而且这不会影响字符串的使用。
C语言中的字符串不是二进制安全的，因为:
- C语言使用’\0’字符来标识字符串的结束，一旦字符串中出现’\0’，就会被当作字符串结束符处理。
- C语言的字符串在内存中是一个字符数组，数组大小由字符串常量或初始化时决定。如果实际字符串长度小于数组大小，那么数组余下的空间就会被其他数据占用，这可能导致’\0’被改写，进而破坏字符串。
- C语言的字符串函数(如strlen、strcpy等)都是依赖’\0’结束符来判断字符串范围和复制字符串的。如果’\0’被破坏，这些函数就会产生未定义行为。
- C语言字符串的读取通常使用指针遍历，依靠’\0’结束来判断何时停止，这同样依赖’\0’的完整性。
所以，在C语言中，如果要处理二进制数据并当作字符串使用，必须注意’\0’字符的位置和是否被改写。最好的方法是在字符串最后额外添加一个’\0’，来确保字符串的完整性。或者使用其他语言的字符串，如C++的std::string，它具有更强的二进制安全性。
在其他语言(如Java、Python等)中，字符串的结束不是依赖特定字符，而是由字符串对象的长度来决定，所以这些语言的字符串天然支持二进制安全。这也是C语言字符串相比其他现代语言的一个重要缺陷。
- 如果使用C字符串所用的函数来识别，只能读取到“hello”，后面的“world”会被忽略，这个限制使得C字符串只能保存文本数据，而不能保存图片、视频、压缩文件等二进制数据。
- SDS使用len属性的值判断字符串是否结束，而不是空字符，即SDS是二进制安全的。
Redis构建了一种新的字符串结构，称为简单动态字符串（Simple Dynamic String），简称SDS。
例如，我们执行命令：
那么Redis将在底层创建两个SDS，其中一个是包含“name”的SDS，另一个是包含“虎哥”的SDS。
Redis是C语言实现的，其中SDS是一个结构体，源码如下：
这里的sds根据长度类型，分为五类，比如我们看到sdshdr8中len属性的类型为uint8_t代表无符号8比特位，len最大为255，也就是说这种类型的sds长度最大为255字节。struct __attribute__ ((__packed__)) sdshdr8 { uint8_t len; // 已经使用的字节数 uint8_t alloc; // 实际可以存储的字节最大长度，不包括SDS头部和结尾的空字符 unsigned char flags; // flags中的低3个bit决定使用哪种结构存储字符串，高5bit未使用 char buf[]; // 柔性数组，用来保存实际的字符串 };sdshdrxx会根据字符串的实际长度，选取合适的结构，最大化节省内存空间。获取字符串长度时间复杂度O(1)。
例如，一个包含字符串“name”的sds结构如下：
SDS之所以叫做动态字符串，是因为它具备动态扩容的能力，例如一个内容为“hi”的SDS：
假如我们要给SDS追加一段字符串“,Amy”，这里首先会申请新内存空间，称为内存预分配：
-
如果新字符串小于1M，则新空间为扩展后字符串长度的两倍+1Byte
-
如果新字符串大于1M，则新空间为扩展后字符串长度+1M+1Byte
-
这里的1字节你可以当作是给
\0留的，也就是说从宏观来看，小于1M就在新字符串的基础上再扩1倍，大于1M就在新字符串的基础上扩1M.
注意：
在C语言中，char数组的元素大小与编译器和系统有关。常见的有:
1字节：在大多数系统和编译器下，char的大小是1字节(8位)，可以存储0-255之间的整数。这是最常见的情况。>1字节：某些系统使用UTF-16或其他多字节编码，这时char可能大于1字节，比如2个字节(16位)。这种情况较少见。- 与short、int等整数类型相同:某些嵌入式系统上,char可能与short、int等整数类型具有相同的大小，比如 both 2字节或4字节。这种情况也不太常见。
所以，通常我们假定char数组的元素大小是1字节会是正确的，但是也要注意在某些系统或编译器上可能不同。
申请内存的动作非常消耗资源，而通过内存的预分配可以适当地减少申请内存的次数。
字符串编码类型
字符串类型的内部编码有三种：
-
int：存储 8 个字节的长整型（long，2^63-1），如果 value 是 long 类型的整数，则使用此编码。
-
embstr：代表 embstr 格式的 SDS，存储小于 44 个字节的字符串（3.2 版本之前是 39 个字节），只分配一次内存空间（因为 Redis Object 和 SDS 是连续的）。
- embstr 分配的是连续的一块内存，包含 robj 和 sds，robj 占用了16个字节，3.2 版本之前 sds 占用 8 个字节，3.2 及之后版本 占用 3 个字节。因此，
- 在 3.2 版本之前，如果字符串存储小于等于 39 个字节，编码为 embstr，超过 39 个字节，编码为 raw；
- 在 3.2 及之后，如果字符串存储小于等于 44 个字节，编码为 embstr，超过 44 个字节，编码为 raw。
- 优点：只需要一次内存分配，数据比较小的时候使用的是这种编码，数据更紧凑，效率更高。
- 缺点：没有提供修改的函数，所以是只读的，如果要对此编码数据进行修改，会变成 raw 再执行修改，然后结束。
- embstr 分配的是连续的一块内存，包含 robj 和 sds，robj 占用了16个字节，3.2 版本之前 sds 占用 8 个字节，3.2 及之后版本 占用 3 个字节。因此，
-
raw：存储大于 44 个字节的字符串（3.2 版本之前是 39 个字节），需要分配两次内存空间（分别为 Redis Object 和 SDS 分配空间）。raw 分配的不是连续的内存，需要调用两次内存分配函数来分别创建 robj 和 sds。
intset
IntSet是Redis中set集合的一种实现方式，基于整数数组来实现，并且具备长度可变、有序等特征。
结构如下：
其中的encoding包含三种模式，表示存储的整数大小不同：
分析：
contents数组是整数集合的底层实现：整数集合中的每一个元素就是contents数组中的一个元素，每个元素在数组中按照从小到大的顺序排列，并且没有重复元素。
虽然，contents数组被声明为 int8_t 类型的数组，但实际上contents数组并不保存任何int8_t 类型的值，contents数组实际存储的类型取决于encoding的值。encoding的取值可以是：INTSET_ENC_INT16、INTSET_ENC_INT32 或 INTSET_ENC_INT64，每种编码的取值范围如下：
- INTSET_ENC_INT16 取值范围：[−2^15 ，2^15−1] 即：[-32768, 32767 ]
- INTSET_ENC_INT32 取值范围：[−2^31 ，2^31−1] 即：[-2147483648, 2147483647]
- INTSET_ENC_INT64 取值范围：[−2^63 ，2^63−1] 即：[-9223372036854775808, 9223372036854775807]
为了方便查找，Redis会将intset中所有的整数按照升序依次保存在contents数组中，结构如图：
通过右边的寻址公式可以得到每一个整数的位置，这也反映了为什么要将数组中的数字编码类型进行统一。因为是连续的内存地址，方便寻找数组中每个元素的地址。
现在，数组中每个数字都在int16_t的范围内，因此采用的编码方式是INTSET_ENC_INT16，每部分占用的字节大小为：
- encoding：4字节
- length：4字节
- contents：2字节 * 3 = 6字节
我们向该其中添加一个数字：50000，这个数字超出了int16_t的范围，intset会自动升级编码方式到合适的大小。
以当前案例来说流程如下：
- 升级编码为INTSET_ENC_INT32, 每个整数占4字节，并按照新的编码方式及元素个数扩容数组
- 倒序依次将数组中的元素拷贝到扩容后的正确位置
- 将待添加的元素放入数组末尾
- 最后，将inset的encoding属性改为INTSET_ENC_INT32，将length属性改为4
源码如下：
小总结：
Intset可以看做是特殊的整数数组，具备一些特点：
- Redis会确保Intset中的元素唯一、有序
- 具备类型升级机制，可以节省内存空间
- 底层采用二分查找方式来查询
Dict
我们知道Redis是一个键值型（Key-Value Pair）的数据库，我们可以根据键实现快速的增删改查。而键与值的映射关系正是通过Dict来实现的。
Dict由三部分组成，分别是：哈希表（DictHashTable）、哈希节点（DictEntry）、字典（Dict）
当我们向Dict添加键值对时，Redis首先根据key计算出hash值（h），然后利用 h & sizemask来计算元素应该存储到数组中的哪个索引位置。我们存储k1=v1，假设k1的哈希值h =1，则1&3 =1，因此k1=v1要存储到数组角标1位置。
Dict的扩容
Dict中的HashTable就是数组结合单向链表的实现，当集合中元素较多时，必然导致哈希冲突增多，链表过长，则查询效率会大大降低。
Dict在每次新增键值对时都会检查负载因子（LoadFactor = used/size） ，满足以下两种情况时会触发哈希表扩容：
- 哈希表的 LoadFactor >= 1，并且服务器没有执行 BGSAVE 或者 BGREWRITEAOF 等后台进程；
- 哈希表的 LoadFactor > 5 ；
Dict的rehash
不管是扩容还是收缩，必定会创建新的哈希表，导致哈希表的size和sizemask变化，而key的查询与sizemask有关。因此必须对哈希表中的每一个key重新计算索引，插入新的哈希表，这个过程称为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.rehashidx = 0，标示开始rehash
-
将dict.ht[0]中的每一个dictEntry都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最终为空
整个过程可以描述成：
小总结：
Dict的结构：
- 类似java的HashTable，底层是数组加链表来解决哈希冲突
- Dict包含两个哈希表，ht[0]平常用，ht[1]用来rehash
Dict的伸缩：
- 当LoadFactor大于5或者LoadFactor大于1并且没有子进程任务时，Dict扩容
- 当LoadFactor小于0.1时，Dict收缩
- 扩容大小为第一个大于等于used + 1的2^n
- 收缩大小为第一个大于等于used 的2^n
- Dict采用渐进式rehash，每次访问Dict时执行一次rehash
- rehash时ht[0]只减不增，新增操作只在ht[1]执行，其它操作在两个哈希表
ZipList
ZipList 是一种特殊的“双端链表” ，由一系列特殊编码的连续内存块组成。可以在任意一端进行压入/弹出操作, 并且该操作的时间复杂度为 O(1)。
| 属性 | 类型 | 长度 | 用途 |
|---|---|---|---|
| zlbytes | uint32_t | 4 字节 | 记录整个压缩列表占用的内存字节数 |
| zltail | uint32_t | 4 字节 | 记录压缩列表表尾节点距离压缩列表的起始地址有多少字节，通过这个偏移量，可以确定表尾节点的地址。 |
| zllen | uint16_t | 2 字节 | 记录了压缩列表包含的节点数量。 最大值为UINT16_MAX （65534），如果超过这个值，此处会记录为65535，但节点的真实数量需要遍历整个压缩列表才能计算得出。 |
| entry | 列表节点 | 不定 | 压缩列表包含的各个节点，节点的长度由节点保存的内容决定。 |
| zlend | uint8_t | 1 字节 | 特殊值 0xFF （十进制 255 ），用于标记压缩列表的末端。 |
例如：
说明：ziplist 的总长度为96字节（0x60的十进制），最后一个entry距离ziplist起始位置偏移了75字节（0x4B的十进制），ziplist中此时有3（0x03的十进制）个entry。
ZipListEntry
ZipList 中的Entry并不像普通链表那样记录前后节点的指针，因为记录两个指针要占用16个字节，浪费内存。而是采用了下面的结构：
-
previous_entry_length：前一节点的长度，占1个或5个字节。
- 如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值
- 如果前一节点的长度大于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据
-
encoding：编码属性，记录content的数据类型（字符串还是整数）以及长度，占用1个、2个或5个字节
-
contents：负责保存节点的数据，可以是字符串或整数
ZipList中所有存储长度的数值均采用小端字节序，即低位字节在前，高位字节在后。例如：数值0x1234，采用小端字节序后实际存储值为：0x3412
Encoding编码
ZipListEntry中的encoding编码分为字符串和整数两种：
字符串：如果encoding是以“00”、“01”或者“10”开头，则证明content是字符串
| 编码 | 编码长度 | 字符串大小 |
|---|---|---|
| |00pppppp| | 1 bytes | <= 63 bytes |
| |01pppppp|qqqqqqqq| | 2 bytes | <= 16383 bytes |
| |10000000|qqqqqqqq|rrrrrrrr|ssssssss|tttttttt| | 5 bytes | <= 4294967295 bytes |
例如，我们要保存字符串：“ab”和 “bc”
整数：如果encoding是以“11”开始，则证明content是整数，且encoding固定只占用1个字节
| 编码 | 编码长度 | 整数类型 |
|---|---|---|
| 11000000 | 1 | int16_t（2 bytes） |
| 11010000 | 1 | int32_t（4 bytes） |
| 11100000 | 1 | int64_t（8 bytes） |
| 11110000 | 1 | 24位有符整数(3 bytes) |
| 11111110 | 1 | 8位有符整数(1 bytes) |
| 1111xxxx | 1 | 直接在xxxx位置保存数值，范围从0001~1101，减1后结果为实际值 |
ZipList的连锁更新问题
ZipList的每个Entry都包含previous_entry_length来记录上一个节点的大小，长度是1个或5个字节：
- 如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值
- 如果前一节点的长度大于等于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据
现在，假设我们有N个连续的、长度为250~253字节之间的entry(连锁更新问题发生条件非常苛刻，所以几率很低)，因此entry的previous_entry_length属性用1个字节即可表示，如图所示：
如果这个时候插入了一个新的Entry，并且它的大小超过了254个字节，那么就会出现下面这样的情况：
- 因为第一个元素的大小超过了254字节，那么第二个元素在记录前一个元素的长度的时候就要使用5个字节
- 这也就意味着第二个元素的整体大小也超过了254字节，这也就会导致第三个元素产生同样的影响
- 以此类推
ZipList这种特殊情况下产生的连续多次空间扩展操作称之为连锁更新（Cascade Update）。新增、删除都可能导致连锁更新的发生。
再举一个例子：
如上图，有 entryX-1 512字节，entryX 128字节，entryX+1 253字节，entryX+2 253 字节。
由于 entryX 元素长度为 128 字节，那么 entryX + 1 元素的 prevlen 的元素的长度就只要 1 个字节就可以了。
这个时候，在 entryX 和 entryX+1 之间加了一个 entryNew 元素，这个元素长度是 1024 字节，那么，这个时候 entryX+1 中的 prevlen 就需要变成 5 个字节了。注意：后面的元素可能也要进行更新。
当删除 entryX 的时候，entryX+1 的 prevlen 就变成了 5 字节，那么 entryX+1 的长度就变成了 257 字节；又导致后面进行更新，这种叫做连锁更新。
由于，每次扩展都将重新分配内存，导致效率很低，当更新到一次不变时，那么就不向后检查了。比如说后面有一个 entryX+3 为 100 字节，那么就不会进行检查了。
小总结：
ZipList特性：
- 压缩列表的可以看做一种连续内存空间的"双向链表"
- 列表的节点之间不是通过指针连接(连续空间也没必要)，而是记录上一节点和本节点长度来寻址，内存占用较低
- 如果列表数据过多，导致链表过长，可能影响查询性能
- 增或删较大数据时有可能发生连续更新问题
QuickList
问题1：ZipList虽然节省内存，但申请内存必须是连续空间，如果内存占用较多，申请内存效率很低。怎么办？
答：为了缓解这个问题，我们必须限制ZipList的长度和entry大小。
问题2：但是我们要存储大量数据，超出了ZipList最佳的上限该怎么办？
答：我们可以创建多个ZipList来分片存储数据。
问题3：数据拆分后比较分散，不方便管理和查找，这多个ZipList如何建立联系？
答：Redis在3.2版本引入了新的数据结构QuickList，它是一个双端链表，只不过链表中的每个节点都是一个ZipList。
为了避免QuickList中的每个ZipList中entry过多，Redis提供了一个配置项：list-max-ziplist-size来限制。
-
如果值为正，则代表ZipList的允许的entry个数的最大值
-
如果值为负，则代表ZipList的最大内存大小，分5种情况：
- -1：每个ZipList的内存占用不能超过4kb
- -2：每个ZipList的内存占用不能超过8kb
- -3：每个ZipList的内存占用不能超过16kb
- -4：每个ZipList的内存占用不能超过32kb
- -5：每个ZipList的内存占用不能超过64kb
其默认值为 -2：
以下是QuickList的和QuickListNode的结构源码：
我们接下来用一段流程图来描述当前的这个结构
总结：
QuickList的特点：
- 是一个节点为ZipList的双端链表
- 节点采用ZipList，解决了传统链表的内存占用问题
- 控制了ZipList大小，解决连续内存空间申请效率问题
- 中间节点可以压缩，进一步节省了内存
SkipList
SkipList（跳表）首先是链表，但与传统链表相比有几点差异：
- 元素按照升序排列存储
- 节点可能包含多个指针，指针跨度不同。
如何理解跳表？在了解跳表之前，我们先从普通链表开始，一点点揭开跳表的神秘面纱~
首先，普通单链表来说，即使链表是有序的，我们要查找某个元素，也需要从头到尾遍历整个链表。这样效率很低，时间复杂度是O(n)。
那么有没有方法提升查询效率呢？我们可以尝试为链表建立“索引”来提升查询效率。如下图，我们在原始链表的基础上，每两个元素提取一个索引，down指向原始链表的节点：
此时，假如我们要查询值为19的节点，我们从索引层开始遍历，当遍历到16时，下个节点的值为23，所以，19一定在这两个节点之间。我们通过16节点的down指针来到原始链表，将继续遍历，直到找到值为19的节点。在没有建“索引”之前，我们需要遍历8次，才能找到19，而在建立“索引”后，需要6次就能找到，也就是，索引帮我们减少了查询的次数。
那如果我们再建一级索引呢？哈哈哈，没想到吧也是6次，这是因为我们的数据量太少，即便加了两级索引，优化效果也不是很明显。在数据量大时，优化效果还是很明显的，有兴趣可以自己动手画一画。
这种查找跟二分查找的时间复杂度一样O(log2n)。换句话说，我们是基于单链表实现了二分查找。但是，这种查询效率的提升是有代价的，也就是我们需要维护多层级索引，才能实现。这也是一种空间换时间的思路。
跳表的插入和删除
- 我们想在跳表中插入和删除一个节点，第一步是要找到插入和删除的位置，然后再执行插入或者删除，因为跳表的查询时间复杂度是O(log2n)，插入和删除的时间复杂度也是O(log2n)。
- 插入
- 删除操作就需要注意一下，如果删除的节点也存在于索引节点中，那么，索引中的节点也要删除。单链表中的删除，需要拿到前驱节点的指针，如果是双向链表就不用考虑了。
跳表索引的动态更新
当我们一直往跳表中添加元素，如果不更新索引就可能出现，某2个索引之间的索引数过多，极端情况下，会退化为单向链表。
作为一种动态数据结构，我们需要某种手段作为索引节点和原始链表大小的平衡，也就是说，当链表中的节点数增多时，也响应的增加一些索引节点，避免复杂度的退化。红黑树和AVL树是通过左旋和右旋来维持左右子树的平衡。
而跳表是一种基于概率的数据结构,它通过随机决定每个元素的层数,来保证整个跳表的平衡。具体做法是:
当插入一个新元素时,Redis会随机决定它的层数,层数可以是1层,2层,3层,直到最大层数。层数的随机分布遵循几何分布,层数越高,其出现的概率越低。
举例来说,如果我们设置最大层数为5,那么:
- 层数为1的概率50%
- 层数为2的概率25%
- 层数为3的概率12.5%
- 层数为4的概率6.25%
- 层数为5的概率3.125%
从这个分布可以看出,层数越高的元素出现的概率会显著下降。这就使得高层元素较为“稀疏”,而低层较为“密集”。
这样,高层元素就像是跳表的快速通道,用于快速遍历和查找。而低层则包含更丰富的元素,可以精确查找每一个元素。
这种随机分布的层数,显著减少了跳表的倾斜几率,使其总体来说是均衡的。因为高层元素较稀疏,所以遍历和查找能够快速跳过大量低层元素,获得较高性能。
而相比AVL树和红黑树等平衡树,跳表的随机性使其逻辑更简单,无须进行频繁旋转来维持平衡,这也使其性能更高。这也是Redis选择跳表的一个重要原因。
总之,跳表通过为每个新元素随机分配层数,来保证其总体平衡。层数遵循几何分布,高层较稀疏,低层较密集。这使得跳表既有快速查找的能力,也可以精确访问每个元素。
跳表源码结构
小总结：
SkipList的特点：
- 跳跃表是一个双向链表，每个节点都包含score和ele值
- 节点按照score值排序，score值一样则按照ele字典排序
- 每个节点都可以包含多层指针，层数是1到32之间的随机数
- 不同层指针到下一个节点的跨度不同，层级越高，跨度越大
- 增删改查效率与红黑树基本一致，实现却更简单
RedisObject
redisObject是一个C语言构造,所有的Redis对象的数据类型以及值都存储在这个结构中。我们平时操作的字符串、列表、散列等对象,其内部实现全部用redisObject来构造的。
举个例子,一个Redis字符串对象在内存中大致结构如下:
redisObject
- type: REDIS_STRING
- encoding: REDIS_ENCODING_EMBSTR
- ptr: 指向embstr字符串结构
embstr
- size: 字符串长度
- buf: char数组,保存字符串值
redisObject是一个非常轻量级的结构,里面只包含必要的字段,这使得Redis可以创建和销毁对象的代价非常低,这也是Redis可以达到亚秒级响应的原因之一。
同时,将不同对象通过type字段区分,encoding字段指定值的具体存储结构,这使得Redis的对象系统非常灵活和易扩展。Redis可以很容易地添加新的数据类型。
redis使用redisObject对象来表示数据库中的各种键值对数据。这种做法有以下几个主要好处:
- 统一管理不同数据类型。redis支持5种数据类型：字符串、列表、集合、散列、有序集合。使用redisObject对象表示这些数据类型，可以统一进行内存管理、编码转换等操作。
- 方便内存回收。redis使用内存池来节省malloc的调用次数，使用redisObject可以很容易地实现对这些对象的释放，并将内存返还给内存池以供其他对象使用。
- 容易实现内部编码转换。redis的字符串和列表支持多种内部编码来节省空间，使用redisObject对象可以根据实际内容动态更改编码，这增加了redis的灵活性。
- 方便实现字典的通用操作。redis的数据库本质上是一个字典结构，使用redisObject对象作为字典的键值，可以利用该对象实现通用的操作，比如setting、getting、deleting等等。
- 简化编码解码逻辑。在网络通信、RDB持久化以及AOF重写等场景中，都需要对各种类型的数据进行编码与解码。使用redisObject对象作为这些编码与解码的中间表示，可以简化相关逻辑。
- 支持共享对象。redis的内部有一定的数据共享机制，比如在集群下的数据库重合数据，使用redisObject对象可以更容易地实现对象共享，避免相同数据的重复存储。
redisObject源码
Redis的编码方式
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中最常见的数据存储类型
底层实现⽅式：动态字符串SDS或者 Long
-
其基本编码方式是RAW，基于简单动态字符串（SDS）实现，存储上限为512MB。
-
如果存储的SDS长度小于44字节，则会采用EMBSTR编码，此时object head与SDS是一段连续空间。申请内存时只需要调用一次内存分配函数，效率更高。
-
如果存储的字符串是整数值，并且大小在LONG_MAX范围内，则会采用INT编码：直接将数据保存在RedisObject的ptr指针位置（刚好8字节），不再需要SDS了。
确切地说，String在Redis中是⽤⼀个robj来表示的。
用来表示String的robj可能编码成3种内部表⽰：OBJ_ENCODING_RAW，OBJ_ENCODING_EMBSTR，OBJ_ENCODING_INT。
其中前两种编码使⽤的是SDS来存储，最后⼀种OBJ_ENCODING_INT编码直接把string存成了Long型。
在对string进行incr, decr等操作的时候，如果它内部是OBJ_ENCODING_INT编码，那么可以直接行加减操作；如果它内部是OBJ_ENCODING_RAW或OBJ_ENCODING_EMBSTR编码，那么Redis会先试图把SDS存储的字符串转成Long型，如果能转成功，再进行加减操作。
对⼀个内部表示成Long型的string执行append, setbit, getrange这些命令，针对的仍然是string的值（即十进制表示的字符串），而不是针对内部表⽰的long型进⾏操作。
比如字符串”32”，如果按照字符数组来解释，它包含两个字符，它们的ASCII码分别是0x33和0x32。当我们执行命令setbit key 7 0的时候，相当于把字符0x33变成了0x32，这样字符串的值就变成了”22”。⽽如果将字符串”32”按照内部的64位long型来解释，那么它是0x0000000000000020，在这个基础上执⾏setbit位操作，结果就完全不对了。因此，在这些命令的实现中，会把long型先转成字符串再进行相应的操作。
List
Redis的List类型可以从首、尾操作列表中的元素：
哪一个数据结构能满足上述特征？
- LinkedList ：普通链表，可以从双端访问，内存占用较高，内存碎片较多
- ZipList ：压缩列表，可以从双端访问，内存占用低，存储上限低
- QuickList：LinkedList + ZipList，可以从双端访问，内存占用较低，包含多个ZipList，存储上限高
Redis的List结构类似一个双端链表，可以从首、尾操作列表中的元素：
在3.2版本之前，Redis采用ZipList和LinkedList来实现List，当元素数量小于512并且元素大小小于64字节时采用ZipList编码，超过则采用LinkedList编码。
在3.2版本之后，Redis统一采用QuickList来实现List：
Set结构
Set是Redis中的单列集合，满足下列特点：
- 不保证有序性
- 保证元素唯一
- 求交集、并集、差集
可以看出，Set对查询元素的效率要求非常高，思考一下，什么样的数据结构可以满足？
HashTable，也就是Redis中的Dict，不过Dict是双列集合（可以存键、值对）
Set是Redis中的集合，不一定确保元素有序，可以满足元素唯一、查询效率要求极高。
为了查询效率和唯一性，set采用HT编码（Dict）。Dict中的key用来存储元素，value统一为null。
当存储的所有数据都是整数，并且元素数量不超过set-max-intset-entries时，Set会采用IntSet编码，以节省内存
结构如下：
ZSET
ZSet也就是SortedSet，其中每一个元素都需要指定一个score值和member值：
- 可以根据score值排序后
- member必须唯一
- 可以根据member查询分数
因此，zset底层数据结构必须满足键值存储、键必须唯一、可排序这几个需求。之前学习的哪种编码结构可以满足？
- SkipList：可以排序，并且可以同时存储score和ele值（member）
- HT（Dict）：可以键值存储，并且可以根据key找value
当元素数量不多时，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的键是member，值是score；hash的键和值都是任意值
- zset要根据score排序；hash则无需排序
（1）底层实现方式：压缩列表ziplist 或者 字典dict
当Hash中数据项比较少的情况下，Hash底层才⽤压缩列表ziplist进⾏存储数据，随着数据的增加，底层的ziplist就可能会转成dict，具体配置如下：
-
hash-max-ziplist-entries 512
-
hash-max-ziplist-value 64
当满足上面两个条件其中之⼀的时候，Redis就使⽤dict字典来实现hash。
Redis的hash之所以这样设计，是因为当ziplist变得很⼤的时候，它有如下几个缺点：
- 每次插⼊或修改引发的realloc操作会有更⼤的概率造成内存拷贝，从而降低性能。
- ⼀旦发生内存拷贝，内存拷贝的成本也相应增加，因为要拷贝更⼤的⼀块数据。
- 当ziplist数据项过多的时候，在它上⾯查找指定的数据项就会性能变得很低，因为ziplist上的查找需要进行遍历。
总之，ziplist本来就设计为各个数据项挨在⼀起组成连续的内存空间，这种结构并不擅长做修改操作。⼀旦数据发⽣改动，就会引发内存realloc，可能导致内存拷贝。
hash结构如下：
zset集合如下：
因此，Hash底层采用的编码与Zset也基本一致，只需要把排序有关的SkipList去掉即可：
Hash结构默认采用ZipList编码，用以节省内存。 ZipList中相邻的两个entry 分别保存field和value
当数据量较大时，Hash结构会转为HT编码，也就是Dict，触发条件有两个：
- ZipList中的元素数量超过了hash-max-ziplist-entries（默认512）
- ZipList中的任意entry大小超过了hash-max-ziplist-value（默认64字节）
