Redis - 原理篇

✨作者：猫十二懿

❤️‍账号：CSDN 、掘金 、个人博客 、Github、语雀

公众号：猫十二懿

Redis(原理篇)

一、数据结构

1.1 动态字符串SDS

我们都知道Redis中保存的Key是字符串，value往往是字符串或者字符串的集合。可见字符串是Redis中最常用的一种数据结构。

不过Redis没有直接使用C语言中的字符串，因为C语言字符串存在很多问题

1. 获取字符串的长度需要通过计算（因为c语言中其实没有字符串而是字符数组，通过最后的 ‘\0’ 来表示结束，所以在计算数组长度的时候需要减去这个’\0’）
2. 非二进制安全(因为是通过使用 ‘\0’ 来表示结束那么在这个字符串的中间都不能有特殊符号)
3. 不可修改

Redis构建了一种新的字符串结构，称为简单动态字符串（Simple Dynamic String），简称SDS。
例如，我们执行命令：

那么Redis将在底层创建两个SDS，其中一个是包含“name”的SDS，另一个是包含“虎哥”的SDS。

Redis是C语言实现的，其中SDS是一个结构体，源码如下：

例如，一个包含字符串“name”的sds结构如下：

SDS之所以叫做动态字符串，是因为它具备动态扩容的能力，例如一个内容为“hi”的SDS：

假如我们要给SDS追加一段字符串“,Amy”，这里首先会申请新内存空间：

• 如果新字符串小于1M，则新空间为扩展后字符串长度的两倍+1；

• 如果新字符串大于1M，则新空间为扩展后字符串长度+1M+1。称为内存预分配。

动态字符串优点：

1. 获取字符串长度的时间复杂度为0(1)[因为长度已经存在于结构体中]
2. 支持动态扩容
3. 减少内存分配次数
4. 二进制安全（可以存储特殊字符，无需考虑结束符的问题）

1.2 Redis数据结构-IntSet

IntSet是Redis中set集合的一种实现方式，基于整数数组来实现，并且具备长度可变、有序等特征。
结构如下：

其中的encoding包含三种模式，表示存储的整数大小不同：

为了方便查找，Redis会将intset中所有的整数按照升序依次保存在contents数组中，结构如图：

寻址公式：startPtr【开始的起始地址为0】+（sizeof(int16) 【数据类型的字节大小】* index【它对应的下标】）就可以快速找到对应的数据

现在，数组中每个数字都在int16_t的范围内，因此采用的编码方式是INTSET_ENC_INT16，每部分占用的字节大小为：

• encoding：4字节
• length：4字节
• contents：2字节 * 3 = 6字节

1.2.1 IntSet 升级

现在，假设有一个intset,元素为{5,10,20}，采用的编码是INTSET_ENC_INT16，则每个整数占2字节：

我们向该其中添加一个数字：50000，这个数字超出了int16_t的范围，intset会自动升级编码方式到合适的大小。
以当前案例来说流程如下：

• 升级编码为INTSET_ENC_INT32, 每个整数占4字节，并按照新的编码方式及元素个数扩容数组
• 倒序依次将数组中的元素拷贝到扩容后的正确位置（倒叙放是为了防止，正序放的时候，字节扩大的时候会将后面的数据给覆盖掉）
• 将待添加的元素放入数组末尾
• 最后，将inset的encoding属性改为INTSET_ENC_INT32，将length属性改为4

在length+prepend中如果我们之前判断的prepend如果是正数那么就是0即在倒序插入的时候原来元素的角标不会改变，只在扩容后的数组或者原数组最后加上新的数据就行，如果为负数那么prepend的值就是为1，那么所有元素就要向前移动一位

小总结：

Intset可以看做是特殊的整数数组，具备一些特点：

• Redis会确保Intset中的元素唯一、有序

• 具备类型升级机制，可以节省内存空间

• 底层采用二分查找方式来查询

  

1.3 Redis数据结构-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由三部分组成，分别是：哈希表（DictHashTable）、哈希节点（DictEntry）、字典（Dict）

1.3.1 Dict 扩容 / 收缩

Dict中的HashTable就是数组结合单向链表的实现，当集合中元素较多时，必然导致哈希冲突增多，链表过长，则查询效率会大大降低。
Dict在每次新增键值对时都会检查负载因子（LoadFactor = used/size） ，满足以下两种情况时会触发哈希表扩容：
哈希表的 LoadFactor >= 1，并且服务器没有执行 BGSAVE 或者 BGREWRITEAOF 等后台进程（因为这种操作对性能要求高，如果我在在进行rehash的操作就可能导致阻塞）；
哈希表的 LoadFactor > 5 ；

dict_force_resize_ratio是5

HASHTABLE_MIN_FILL是10

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.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最终为空

整个过程可以描述成：

当ht[0]大小只有4的时候这个时候，新添加了一个dictEntry，这个时候就ht[1]就会申请一个大小 >=userd+1大小的2^n的dictht1，将原来在ht[0]的数据渐进的转移到ht[1]中，最后ht[0]指针指向ht[1],将dict.ht[1]初始化为空哈希表，释放原来的dict.ht[0]的内存

1.4 Redis数据结构-ZipList

ZipList 是一种特殊的“双端链表” ，由一系列特殊编码的连续内存块组成。可以在任意一端进行压入/弹出操作, 并且该操作的时间复杂度为 O(1)。

这里的尾偏移量的作用就是为了可以直接定位到最后一个entry节点，当我们知道了起始地址在加上尾偏移量就可以找到最后一个节点

属性	类型	长度	用途
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：负责保存节点的数据，可以是字符串或整数

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”

ZipListEntry中的encoding编码分为字符串和整数两种：

• 整数：如果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后结果为实际值

1.4.1 Redis数据结构-ZipList的连锁更新问题

ZipList的每个Entry都包含previous_entry_length来记录上一个节点的大小，长度是1个或5个字节：
如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值
如果前一节点的长度大于等于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据
现在，假设我们有N个连续的、长度为250~253字节之间的entry，因此entry的previous_entry_length属性用1个字节即可表示，如图所示：

ZipList这种特殊情况下产生的连续多次空间扩展操作称之为连锁更新（Cascade Update）。新增、删除都可能导致连锁更新的发生。

小总结：

ZipList特性：

• 压缩列表的可以看做一种连续内存空间的"双向链表"
• 列表的节点之间不是通过指针连接，而是记录上一节点和本节点长度来寻址，内存占用较低
• 如果列表数据过多，导致链表过长，可能影响查询性能
• 增或删较大数据时有可能发生连续更新问题

1.5 Redis数据结构-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个数的最大值(但是这样的话，如果我每一个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大小，解决连续内存空间申请的效率问题
• 中间节点可以压缩，进一步节省内存

1. 6 Redis数据结构-SkipList

SkipList（跳表）首先是链表，但与传统链表相比有几点差异：
元素按照升序排列存储
节点可能包含多个指针，指针跨度不同。

SkipList（跳表）首先是链表，但与传统链表相比有几点差异：
元素按照升序排列存储
节点可能包含多个指针，指针跨度不同。

SkipList（跳表）首先是链表，但与传统链表相比有几点差异：
元素按照升序排列存储
节点可能包含多个指针，指针跨度不同。

总结

SkipList的特点：

• 跳跃表是一个双向链表，每一个节点都包含score和ele值
• 节点按照score值排序，score值一样则按照ele字典排序
• 每个节点都可以包含多层指针，层数是1到32之间的随机数
• 不同层指针到下一个节点的跨度不同，层级越高，跨度越大
• 增删改查效率与红黑树基本一致，实现却更简单

1.7 Redis数据结构-RedisObject

Redis中的任意数据类型的键和值都会被封装为一个RedisObject，也叫做Redis对象，源码如下：

1、什么是redisObject：
从Redis的使用者的角度来看，⼀个Redis节点包含多个database（非cluster模式下默认是16个，cluster模式下只能是1个），而一个database维护了从key space到object space的映射关系。这个映射关系的key是string类型，⽽value可以是多种数据类型，比如：
string, list, hash、set、sorted set等。我们可以看到，key的类型固定是string，而value可能的类型是多个。
⽽从Redis内部实现的⾓度来看，database内的这个映射关系是用⼀个dict来维护的。dict的key固定用⼀种数据结构来表达就够了，这就是动态字符串sds。而value则比较复杂，为了在同⼀个dict内能够存储不同类型的value，这就需要⼀个通⽤的数据结构，这个通用的数据结构就是robj，全名是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

1.8 Redis数据结构-String

String是Redis中最常见的数据存储类型：

其基本编码方式是RAW，基于简单动态字符串（SDS）实现，存储上限为512mb。

如果存储的SDS长度小于44字节，则会采用EMBSTR编码，此时object head与SDS是一段连续空间。申请内存时只需要调用一次内存分配函数，效率更高。

（1）底层实现⽅式：动态字符串sds 或者 long String的内部存储结构⼀般是sds（Simple Dynamic String，可以动态扩展内存），但是如果⼀个String类型的value的值是数字，那么Redis内部会把它转成long类型来存储，从⽽减少内存的使用。

如果存储的字符串内存大小是小于44个字节的那么，就会采用的是EMBSTR编码

确切地说，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型先转成字符串再进行相应的操作。

1.9 Redis数据结构-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：

1.10 Redis数据结构-Set结构

Set是Redis中的单列集合，满足下列特点：

• 不保证有序性
• 保证元素唯一
• 求交集、并集、差集

可以看出，Set对查询元素的效率要求非常高，思考一下，什么样的数据结构可以满足？
HashTable，也就是Redis中的Dict，不过Dict是双列集合（可以存键、值对）

Set是Redis中的集合，不一定确保元素有序，可以满足元素唯一、查询效率要求极高。
为了查询效率和唯一性，set采用HT编码（Dict）。Dict中的key用来存储元素，value统一为null。
当存储的所有数据都是整数，并且元素数量不超过set-max-intset-entries时，Set会采用IntSet编码，以节省内存

1.11 Redis数据结构-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在后(当我们查询的时候就可以直接遍历即可，当我们要找m1的score，只需要找到m1在找下一个即可)
• score越小越接近队首，score越大越接近队尾，按照score值升序排列

1.12 Redis数据结构-Hash

Hash结构与Redis中的Zset非常类似：

• 都是键值存储
• 都需求根据键获取值
• 键必须唯一

区别如下：

• zset的键是member，值是score；hash的键和值都是任意值
• zset要根据score排序；hash则无需排序

底层实现方式：压缩列表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，触发条件有两个：

是否需要转换成HT

这里就是在判断插入的时候key是否重复

1.13 数据结构总结

1. IntSet（整数集合）：IntSet 是一种优化的数据结构，用于存储只包含整数值的集合。它在内存占用和性能方面都具有优势，适用于需要存储大量整数值的场景，比如计数器、唯一ID生成器等。
2. Dict（字典）：Dict 是 Redis 中的哈希表实现，用于存储键值对。它是 Redis 中很多数据结构的底层实现，适用于存储任意类型的键值对数据，常用于缓存数据、用户会话管理等。
3. ZipList（压缩列表）：ZipList 是一种紧凑的、压缩的列表实现。它在元素较少且每个元素较小的情况下可以节省内存，并且支持快速的插入和删除操作。ZipList 适用于存储较小规模的列表数据。
4. QuickList（快速列表）：QuickList 是一种特殊的列表实现，它将多个 ZipList 组合在一起形成一个链表结构。它可以在列表元素较多时节省内存，并且支持在列表两端进行插入和删除操作。QuickList 适用于存储较大规模的列表数据。
5. SkipList（跳跃表）：SkipList 是一种有序的链表数据结构，可以快速进行元素的插入、删除和查找操作。SkipList 在有序集合 ZSet 的实现中被使用，适用于需要快速的有序集合操作的场景，比如排行榜、范围查询等。
6. RedisObject（Redis 对象）：RedisObject 是 Redis 中所有数据结构的基础对象，它封装了不同数据结构的值和类型信息。RedisObject 在 Redis 内部使用，作为数据结构的统一表示方式。
7. String（字符串）：String 是最基本的数据结构，可以存储字符串、整数或者浮点数。它的使用场景非常广泛，例如缓存数据、计数器、分布式锁等。
8. List（列表）：List 是一个有序的字符串列表，可以在两端进行元素的插入和删除操作。它常用于实现队列、栈、消息发布与订阅等场景。
9. Set（集合）：Set 是一个无序的、不重复的字符串集合，支持对集合进行交集、并集、差集等操作。它适用于存储唯一值的场景，比如社交网络中的关注列表、标签系统等。
10. Hash（哈希）：Hash 是一个键值对的无序散列表，可以存储多个字段和对应的值。Hash 适用于存储对象，例如用户信息、商品信息等，每个字段对应对象的一个属性。
11. ZSet（有序集合）：ZSet 是一个有序的字符串集合，每个成员都关联一个分数，根据分数进行排序。它常用于实现排行榜、优先级队列等场景。

二、Redis网络模型

2.1 用户空间和内核态空间

服务器大多都采用Linux系统，这里我们以Linux为例来讲解:

ubuntu和Centos 都是Linux的发行版，发行版可以看成对linux包了一层壳，任何Linux发行版，其系统内核都是Linux。我们的应用都需要通过Linux内核与硬件交互

用户的应用，比如redis，mysql等其实是没有办法去执行访问我们操作系统的硬件的，所以我们可以通过发行版的这个壳子去访问内核，再通过内核去访问计算机硬件

计算机硬件包括，如cpu，内存，网卡等等，内核（通过寻址空间）可以操作硬件的，但是内核需要不同设备的驱动，有了这些驱动之后，内核就可以去对计算机硬件去进行 内存管理，文件系统的管理，进程的管理等等

我们想要用户的应用来访问，计算机就必须要通过对外暴露的一些接口，才能访问到，从而简介的实现对内核的操控，但是内核本身上来说也是一个应用，所以他本身也需要一些内存，cpu等设备资源，用户应用本身也在消耗这些资源，如果不加任何限制，用户去操作随意的去操作我们的资源，就有可能导致一些冲突，甚至有可能导致我们的系统出现无法运行的问题，因此我们需要把用户和内核隔离开

进程的寻址空间划分成两部分：内核空间、用户空间

什么是寻址空间呢？我们的应用程序也好，还是内核空间也好，都是没有办法直接去物理内存的，而是通过分配一些虚拟内存映射到物理内存中，我们的内核和应用程序去访问虚拟内存的时候，就需要一个虚拟地址，这个地址是一个无符号的整数，比如一个32位的操作系统，他的带宽就是32，他的虚拟地址就是2的32次方，也就是说他寻址的范围就是0~2的32次方， 这片寻址空间对应的就是2的32个字节，就是4GB，这个4GB，会有3个GB分给用户空间，会有1GB给内核系统

在linux中，他们权限分成两个等级，0和3，用户空间只能执行受限的命令（Ring3），而且不能直接调用系统资源，必须通过内核提供的接口来访问内核空间可以执行特权命令（Ring0），调用一切系统资源，所以一般情况下，用户的操作是运行在用户空间，而内核运行的数据是在内核空间的，而有的情况下，一个应用程序需要去调用一些特权资源，去调用一些内核空间的操作，所以此时他俩需要在用户态和内核态之间进行切换。

比如：

Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区：

写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备

读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区

针对这个操作：我们的用户在写读数据时，会去向内核态申请，想要读取内核的数据，而内核数据要去等待驱动程序从硬件上读取数据，当从磁盘上加载到数据之后，内核会将数据写入到内核的缓冲区中，然后再将数据拷贝到用户态的buffer中，然后再返回给应用程序，整体而言，速度慢，就是这个原因，为了加速，我们希望read也好，还是wait for data也最好都不要等待，或者时间尽量的短。

2.2 网络模型-阻塞IO

在《UNIX网络编程》一书中，总结归纳了5种IO模型：

• 阻塞IO（Blocking IO）
• 非阻塞IO（Nonblocking IO）
• IO多路复用（IO Multiplexing）
• 信号驱动IO（Signal Driven IO）
• 异步IO（Asynchronous IO）

应用程序想要去读取数据，他是无法直接去读取磁盘数据的，他需要先到内核里边去等待内核操作硬件拿到数据，这个过程就是1，是需要等待的，等到内核从磁盘上把数据加载出来之后，再把这个数据写给用户的缓存区，这个过程是2，如果是阻塞IO，那么整个过程中，用户从发起读请求开始，一直到读取到数据，都是一个阻塞状态。

整体流程如下图：

用户去读取数据时，会去先发起recvform一个命令，去尝试从内核上加载数据，如果内核没有数据，那么用户就会等待，此时内核会去从硬件上读取数据，内核读取数据之后，会把数据拷贝到用户态，并且返回ok，整个过程，都是阻塞等待的，这就是阻塞IO

总结如下：

顾名思义，阻塞IO就是两个阶段都必须阻塞等待：

阶段一：

• 用户进程尝试读取数据（比如网卡数据）
• 此时数据尚未到达，内核需要等待数据
• 此时用户进程也处于阻塞状态

阶段二：

• 数据到达并拷贝到内核缓冲区，代表已就绪
• 将内核数据拷贝到用户缓冲区
• 拷贝过程中，用户进程依然阻塞等待
• 拷贝完成，用户进程解除阻塞，处理数据

可以看到，阻塞IO模型中，用户进程在两个阶段都是阻塞状态。

2.3 网络模型-非阻塞IO

顾名思义，非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。

阶段一：

• 用户进程尝试读取数据（比如网卡数据）
• 此时数据尚未到达，内核需要等待数据
• 返回异常给用户进程
• 用户进程拿到error后，再次尝试读取
• 循环往复，直到数据就绪

阶段二：

• 将内核数据拷贝到用户缓冲区
• 拷贝过程中，用户进程依然阻塞等待
• 拷贝完成，用户进程解除阻塞，处理数据
• 可以看到，非阻塞IO模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

2.4 网络模型-IO多路复用

无论是阻塞IO还是非阻塞IO，用户应用在一阶段都需要调用recvfrom来获取数据，差别在于无数据时的处理方案：

• 如果调用recvfrom时，恰好没有数据，阻塞IO会使CPU阻塞，非阻塞IO使CPU空转，都不能充分发挥CPU的作用。
• 如果调用recvfrom时，恰好有数据，则用户进程可以直接进入第二阶段，读取并处理数据

所以怎么看起来以上两种方式性能都不好

而在单线程情况下，只能依次处理IO事件，如果正在处理的IO事件恰好未就绪（数据不可读或不可写），线程就会被阻塞，所有IO事件都必须等待，性能自然会很差。

就比如服务员给顾客点餐，分两步：

1. 顾客思考要吃什么（等待数据就绪）
2. 顾客想好了，开始点餐（读取数据）

要提高效率有几种办法？

1. 方案一：增加更多服务员（多线程）
2. 方案二：不排队，谁想好了吃什么（数据就绪了），服务员就给谁点餐（用户应用就去读取数据）

那么问题来了：用户进程如何知道内核中数据是否就绪呢？

所以接下来就需要详细的来解决多路复用模型是如何知道到底怎么知道内核数据是否就绪的问题了

这个问题的解决依赖于提出的文件描述符。

文件描述符（File Descriptor）：简称FD，是一个从0 开始的无符号整数，用来关联Linux中的一个文件。在Linux中，一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字（Socket）。

通过FD，我们的网络模型可以利用一个线程监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

阶段一：

• 用户进程调用select，指定要监听的FD集合
• 核监听FD对应的多个socket
• 任意一个或多个socket数据就绪则返回readable
• 此过程中用户进程阻塞

阶段二：

• 用户进程找到就绪的socket
• 依次调用recvfrom读取数据
• 内核将数据拷贝到用户空间
• 用户进程处理数据

当用户去读取数据的时候，不再去直接调用recvfrom了，而是调用select的函数，select函数会将需要监听的数据交给内核，由内核去检查这些数据是否就绪了，如果说这个数据就绪了，就会通知应用程序数据就绪，然后来读取数据，再从内核中把数据拷贝给用户态，完成数据处理，如果N多个FD一个都没处理完，此时就进行等待。

用IO复用模式，可以确保去读数据的时候，数据是一定存在的，他的效率比原来的阻塞IO和非阻塞IO性能都要高

IO多路复用：是利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。不过监听FD的方式、通知的方式又有多种实现，常见的有：

1. select
2. poll
3. epoll

其中select和poll相当于是当被监听的数据准备好之后，他会把你监听的FD整个数据都发给你，你需要到整个FD中去找，哪些是处理好了的，需要通过遍历的方式，所以性能也并不是那么好

就类似于有人想好吃什么，按下了灯泡，服务员灯亮了，但是服务员却不知道是谁准备好点餐了，需要一个一个的询问。

而epoll，则相当于内核准备好了之后，他会把准备好的数据，直接发给你，咱们就省去了遍历的动作。

2.4.1 网络模型-IO多路复用-select方式

select是Linux最早是由的I/O多路复用技术：

简单说，就是我们把需要处理的数据封装成FD，然后在用户态时创建一个fd的集合（这个集合的大小是要监听的那个FD的最大值+1，但是大小整体是有限制的 ），这个集合的长度大小是有限制的，同时在这个集合中，标明出来我们要控制哪些数据，

比如要监听的数据，是1,2,5三个数据，此时会执行select函数，然后将整个fd发给内核态，内核态会去遍历用户态传递过来的数据，如果发现这里边都数据都没有就绪，就休眠，直到有数据准备好时，就会被唤醒，唤醒之后，再次遍历一遍，看看谁准备好了，然后再将处理掉没有准备好的数据，最后再将这个FD集合写回到用户态中去，此时用户态就知道了，奥，有人准备好了，但是对于用户态而言，并不知道谁处理好了，所以用户态也需要去进行遍历，然后找到对应准备好数据的节点，再去发起读请求，我们会发现，这种模式下他虽然比阻塞IO和非阻塞IO好，但是依然有些麻烦的事情， 比如说频繁的传递fd集合，频繁的去遍历FD等问题

seletc模式存在的问题：

1. 需要将整个fd_set 用户空间拷贝到内核空间，select:结束还要再次拷贝回用户空间
2. select无法得知具体是哪个fd就绪，需要遍历整个fd_set
3. fd set监听的fd数量不能超过1024

2.4.2 网络模型-IO多路复用模型-poll模式

poll模式对select模式做了简单改进，但性能提升不明显，部分关键代码如下：

IO流程：

1. 创建pollfd数组，向其中添加关注的fd信息，数组大小自定义
2. 调用poll函数，将pollfd数组拷贝到内核空间，转链表存储，无上限
3. 内核遍历fd，判断是否就绪
4. 数据就绪或超时后，拷贝pollfd数组到用户空间，返回就绪fd数量n
5. 用户进程判断n是否大于0,大于0则遍历pollfd数组，找到就绪的fd

与select对比：

1. select模式中的fd_set大小固定为1024，而pollfd在内核中采用链表，理论上无上限
2. 监听FD越多，每次遍历消耗时间也越久，性能反而会下降

2.4.3 网络模型-IO多路复用模型-epoll函数

epoll模式是对select和poll的改进，它提供了三个函数：

epoll_ctl中的epfd就是表明要将监听的fd添加到那个一个eventepoll中

第一个是：eventpoll的函数，他内部包含两个东西

一个是：

1、红黑树–> 记录的事要监听的FD

2、一个是链表->一个链表，记录的是就绪的FD

紧接着调用epoll_ctl操作，将要监听的数据添加到红黑树上去，并且给每个fd设置一个监听函数，这个函数会在fd数据就绪时触发，就是准备好了，现在就把fd把数据添加到list_head中去

3、调用epoll_wait函数

就去等待，在用户态创建一个空的events数组，当就绪之后，我们的回调函数会把数据添加到list_head中去，当调用这个函数的时候，会去检查list_head，当然这个过程需要参考配置的等待时间，可以等一定时间，也可以一直等， 如果在此过程中，检查到了list_head中有数据会将数据添加到链表中，此时将数据放入到events数组中，并且返回对应的操作的数量，用户态的此时收到响应后，从events中拿到对应准备好的数据的节点，再去调用方法去拿数据。

小总结：

select模式存在的三个问题：

• 能监听的FD最大不超过1024
• 每次select都需要把所有要监听的FD都拷贝到内核空间
• 每次都要遍历所有FD来判断就绪状态

poll模式的问题：

• poll利用链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如果监听较多，性能会下降

epoll模式中如何解决这些问题的？

• 基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高
• 每个FD只需要执行一次epoll_ctl添加到红黑树，以后每次epol_wait无需传递任何参数，无需重复拷贝FD到内核空间
• 利用ep_poll_callback机制来监听FD状态，无需遍历所有FD，因此性能不会随监听的FD数量增多而下降

1、网络模型-epoll中的ET和LT

当FD有数据可读时，我们调用epoll_wait（或者select、poll）可以得到通知。但是事件通知的模式有两种：

• LevelTriggered：简称LT，也叫做水平触发。只要某个FD中有数据可读，每次调用epoll_wait都会得到通知。
• EdgeTriggered：简称ET，也叫做边沿触发。只有在某个FD有状态变化时，调用epoll_wait才会被通知。

举个栗子：

• 假设一个客户端socket对应的FD已经注册到了epoll实例中
• 客户端socket发送了2kb的数据
• 服务端调用epoll_wait，得到通知说FD就绪
• 服务端从FD读取了1kb数据回到步骤3（再次调用epoll_wait，形成循环）

结论

如果我们采用LT模式，因为FD中仍有1kb数据，则第⑤步依然会返回结果，并且得到通知
如果我们采用ET模式，因为第③步已经消费了FD可读事件，第⑤步FD状态没有变化，因此epoll_wait不会返回，数据无法读取，客户端响应超时。

2、网络模型-基于epoll的服务器端流程

我们来梳理一下这张图

服务器启动以后，服务端会去调用epoll_create，创建一个epoll实例，epoll实例中包含两个数据

1、红黑树（为空）：rb_root 用来去记录需要被监听的FD

2、链表（为空）：list_head，用来存放已经就绪的FD

创建好了之后，会去调用epoll_ctl函数，此函数会会将需要监听的数据添加到rb_root中去，并且对当前这些存在于红黑树的节点设置回调函数，当这些被监听的数据一旦准备完成，就会被调用，而调用的结果就是将红黑树的fd添加到list_head中去(但是此时并没有完成)

3、当第二步完成后，就会调用epoll_wait函数，这个函数会去校验是否有数据准备完毕（因为数据一旦准备就绪，就会被回调函数添加到list_head中），在等待了一段时间后(可以进行配置)，如果等够了超时时间，则返回没有数据，如果有，则进一步判断当前是什么事件，如果是建立连接时间，则调用accept() 接受客户端socket，拿到建立连接的socket，然后建立起来连接，如果是其他事件，则把数据进行写出

其中当获取到客户端的socket之后还要将对应的客户端soket的fd注册到rb_root中，去查看是否有客户端发送请求

2.4.4 IO多路复用-三种方式之间的对比

方式	select	poll	epoll
平台	可用于所有平台	可用于所有平台	仅限于Linux 2.6及更高版本
性能	随着文件描述符数量增加，性能下降	随着文件描述符数量增加，性能下降	高性能，支持大量并发连接
优点	实现简单，跨平台支持好	没有文件描述符数限制，解决了select模型的缺点	只返回活跃的文件描述符，无需遍历整个文件描述符集合
缺点	遍历整个文件描述符集合，效率低下，最大文件描述符数限制（通常是1024）	遍历整个文件描述符集合，效率较低	仅在Linux平台上可用，不具备跨平台性
文件描述符限制	有最大文件描述符限制	无最大文件描述符限制	无最大文件描述符限制
编程简易性	相对较简单	相对较简单	相对复杂
支持的事件类型	仅支持读写事件	支持读写事件和异常事件	支持读写事件和异常事件
可扩展性	受文件描述符数量限制（低）	受文件描述符数量限制（中等）	可以轻松处理大量并发连接（高）
内存消耗	随着文件描述符数量增加，内存消耗增加	随着文件描述符数量增加，内存消耗增加	内存消耗较小
实现原理	基于轮询	基于轮询	基于事件通知
事件触发模式	水平触发	水平触发	边缘触发和水平触发
处理效率	低	中等	高
使用场景	适用于连接数较少的情况，适合于简单的应用程序或测试用途	适用于连接数较多，但不是非常大的情况下，适合于中等规模的应用程序	适用于高并发、连接数非常大的情况，适合于大规模的应用程序，具有最佳的性能和扩展性

补充说明：

• epoll的实现相对于select和poll而言，更加高效，在高并发请求下，epoll可以支持上万个连接的读写操作。
• select采用轮询的方式查找有数据可读写的socket，效率比较低，并且随着监控的文件描述符数量的增加，其效率会快速下降。
• poll改进了select的问题，用链表来存储文件描述符，但是它还是采用了轮询的方式，所以效率依然不高，但是相对于select而言，poll的可扩展性更好一些。
• epoll是基于事件通知的方式，因此可以避免无效遍历，从而提高了效率。
• 在事件触发模式方面，epoll支持边缘触发和水平触发，灵活性更高，能够满足更多场景的需求。
• 在使用难度方面，select最简单易用，poll稍微复杂一点，而epoll则需要进行更加复杂的操作。

2.5 网络模型-信号驱动

信号驱动IO是与内核建立SIGIO的信号关联并设置回调，当内核有FD就绪时，会发出SIGIO信号通知用户，期间用户应用可以执行其它业务，无需阻塞等待。

阶段一：

• 用户进程调用sigaction，注册信号处理函数
• 内核返回成功，开始监听FD
• 用户进程不阻塞等待，可以执行其它业务
• 当内核数据就绪后，回调用户进程的SIGIO处理函数

阶段二：

• 收到SIGIO回调信号
• 调用recvfrom，读取
• 内核将数据拷贝到用户空间
• 用户进程处理数据

当有大量IO操作时，信号较多，SIGIO处理函数不能及时处理可能导致信号队列溢出，而且内核空间与用户空间的频繁信号交互性能也较低。

1、异步IO

这种方式，不仅仅是用户态在试图读取数据后，不阻塞，而且当内核的数据准备完成后，也不会阻塞

他会由内核将所有数据处理完成后，由内核将数据写入到用户态中，然后才算完成，所以性能极高，不会有任何阻塞，全部都由内核完成，可以看到，异步IO模型中，用户进程在两个阶段都是非阻塞状态。

IO操作是同步还是异步，关键看数据在内核空间与用户空间的拷贝过程（数据读写的IO操作），也就是阶段二是同步还是异步

2.6 网络模型-Redis是单线程的吗？为什么使用单线程

Redis到底是单线程还是多线程？

• 如果仅仅聊Redis的核心业务部分（命令处理），答案是单线程

• 如果是聊整个Redis，那么答案就是多线程

在Redis版本迭代过程中，在两个重要的时间节点上引入了多线程的支持：

• Redis v4.0：引入多线程异步处理一些耗时较久的任务，例如异步删除命令unlink
• Redis v6.0 ：在核心网络模型中引入多线程，进一步提高对多核cpu的利用率

因此，对于Redis的核心网络模型，在Redis 6.0之前确实都是单线程。是利用epoll（Linux系统）这样的IO多路复用技术在事件循环中不断处理客户端情况。

为什么Redis要选择单线程？

1. 抛开持久化不谈，Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，因此多线程并不会带来巨大的性能提升。
2. 多线程会导致过多的上下文切换，带来不必要的开销
3. 引入多线程会面临线程安全问题，必然要引入线程锁这样的安全手段，实现复杂度增高，而且性能也会大打折扣

2.7 Redis的单线程模型-Redis单线程和多线程网络模型变更

Redis通过IO多路复用来提高网络性能，并且支持各种不同的多路复用实现，并且将这些实现进行封装， 提供了统一的高性能事件库API库 AE：

看一下Redis单线程网络模型的整个流程

现在main函数中进行函数的初始化

createSocketAcceptHandler他做了两件事情，第一个就是监听我们的socket，第二就是给我们Socket上发生的事件做一个处理器，以前我们直接注册上去就完了在真正发生事件的时候再去做处理，现在是提前准备好一个Socket事件发生的时候做处理的准备。下面这张图就是具体的处理Socket事件的处理方法

接受到客户端的请求，并且关联客户端的fd，监听客户端socket的fd，connSetReadHandler(conn, readQueryFromClient)这个方法就是用来监听客户端的socket的读事件（所以第二参数就是读处理器），其中参数conn，已经赋值给了fd，所以实际传递的还是fd

redis单线程网络模型的整个流程：

创建serverSocket，并且会创建一个对应的fd，这个fd就会注册到我们的Eventloop上，同时我们还给serverSocket绑定一个处理器，tcpAccepthandler,专门处理serverSocket上的可读事件，然后就是去调用beforesleep,调用ApiPoll等待就绪，如果当serverSocket就绪之后就会调用tcpAccepthandler,这个时候就表明有客户端连上来了，这个时候又去执行这个循环事件，但是这个时候的读事件可能就不止一个了（有可能是客户端的），于是就给客户端绑定一个readQueryFromClient来处理客户端的读命令，我们知道在原来的epoll中这个时候就是读的是客户端的数据，那么在redis中是怎么操作的呢，下图就是readQueryFromClient的部分源码

即readQueryFromClient将每一个客户端的请求封装成为一个client，每一个client都一个querybuf，接下来读出请求中的命令放到querybuf中，然后调用processInputBuffer解析缓冲区的字符变成redis命令放到agv的数组当中，然后读出argv中的第0字符，去找到他是属于什么命令，执行，在返回结果的时候他会先尝试向c-buf中写入数据，如果c-buf写不下了，那么他就会写道c-reply这个链表当中写，理论是容量无上限，然后将客户端添加到server.client_pending_write这个队列（是服务器已经定义好的队列），等待被写出，到这里readQueryFromClient函数就结束了，但是这个时候结果还没写出，还在队列当中。这个是时候beforesleep就开始发挥作用了

以下是beforesleep的部分源码

这里就是给每一个客户端都绑定了一个写处理器（sendReplyToClient）

当我们的客户端想要去连接我们服务器，会去先到IO多路复用模型去进行排队，会有一个连接应答处理器，他会去接受读请求，然后又把读请求注册到具体模型中去，此时这些建立起来的连接，如果是客户端请求处理器去进行执行命令时，他会去把数据读取出来，然后把数据放入到client中， clinet去解析当前的命令转化为redis认识的命令，接下来就开始处理这些命令，从redis中的command中找到这些命令，然后就真正的去操作对应的数据了，当数据操作完成后，会去找到命令回复处理器，再由他将数据写出。

总结

Redis是一个基于内存的数据存储系统，它使用单线程网络模型来处理客户端请求。下面是Redis单线程网络模型的执行流程：

1. 监听端口：Redis服务器开始监听指定的端口，等待客户端连接。
2. 接收客户端连接：当有客户端请求连接到Redis服务器时，服务器会接受连接请求，并创建一个客户端套接字，用于与客户端通信。
3. 接收命令：一旦客户端与服务器建立连接，客户端可以发送命令请求到服务器。Redis服务器通过套接字接收到客户端发送的命令。
4. 命令解析：服务器会对接收到的命令进行解析，以确定客户端请求的具体操作。
5. 执行命令：根据解析的结果，服务器会执行相应的命令操作。由于Redis使用单线程模型，每个命令都会按顺序依次执行，不会并发执行。
6. 数据读写：在执行命令期间，如果需要读取或修改数据，服务器会从内存中读取数据或将修改后的数据写回内存。
7. 命令回复：执行完命令后，服务器会将执行结果封装为响应，并通过套接字发送回客户端。
8. 关闭连接：命令执行完成后，服务器会关闭与客户端的连接，等待下一个连接请求。

Redis单线程网络模型是指Redis服务器使用单个线程来处理所有客户端请求和命令操作。它的执行流程包括监听端口、接收客户端连接、接收命令、命令解析、执行命令、数据读写、命令回复和关闭连接。由于单线程的特性，Redis在处理请求时是顺序执行的，不会并发执行命令。这种模型简化了并发控制和线程同步的复杂性，但也限制了Redis服务器的处理能力。然而，通过高效利用CPU和异步IO操作，Redis仍然能够提供出色的性能和响应速度。

三、Redis通信协议-RESP协议

Redis是一个CS架构的软件，通信一般分两步（不包括pipeline和PubSub）：

1. 客户端（client）向服务端（server）发送一条命令

2. 服务端解析并执行命令，返回响应结果给客户端

因此客户端发送命令的格式、服务端响应结果的格式必须有一个规范，这个规范就是通信协议。

而在Redis中采用的是RESP（Redis Serialization Protocol）协议：

1. Redis 1.2版本引入了RESP协议

2. Redis 2.0版本中成为与Redis服务端通信的标准，称为RESP2

3. Redis 6.0版本中，从RESP2升级到了RESP3协议，增加了更多数据类型并且支持6.0的新特性–客户端缓存

但目前，默认使用的依然是RESP2协议，也是我们要学习的协议版本（以下简称RESP）。

在RESP中，通过首字节的字符来区分不同数据类型，常用的数据类型包括5种：

1. 单行字符串：首字节是 ‘+’ ，后面跟上单行字符串，以CRLF（ "\r\n" ）结尾。例如返回"OK"： "+OK\r\n"

2. 错误（Errors）：首字节是 ‘-’ ，与单行字符串格式一样，只是字符串是异常信息，例如："-Error message\r\n"

3. 数值：首字节是 ‘:’ ，后面跟上数字格式的字符串，以CRLF结尾。例如：":10\r\n"

4. 多行字符串：首字节是 ‘$’ ，表示二进制安全的字符串，最大支持512MB：

   1. 如果大小为0，则代表空字符串："$0\r\n\r\n"

   2. 如果大小为-1，则代表不存在："$-1\r\n"

5. 数组：首字节是 ‘*’， 后面跟上数组元素个数，再跟上元素，元素数据类型不限：

3.1 Redis通信协议-基于Socket自定义Redis的客户端

Redis支持TCP通信，因此我们可以使用Socket来模拟客户端，与Redis服务端建立连接：

public class Main {

    static Socket s;
    static PrintWriter writer;
    static BufferedReader reader;

    public static void main(String[] args) {
        try {
            // 1.建立连接
            String host = "127.0.0.1";
            int port = 6379;
            s = new Socket(host, port);
            // 2.获取输出流、输入流
            writer = new PrintWriter(new OutputStreamWriter(s.getOutputStream(), StandardCharsets.UTF_8));
            reader = new BufferedReader(new InputStreamReader(s.getInputStream(), StandardCharsets.UTF_8));

            // 3.发出请求
            // 3.1.获取授权 auth 123321
            sendRequest("auth", "123456 ");
            Object obj = handleResponse();
            System.out.println("obj = " + obj);

            // 3.2.set name 虎哥
            sendRequest("set", "name", "虎哥");
            // 4.解析响应
            obj = handleResponse();
            System.out.println("obj = " + obj);

            // 3.2.set name 虎哥
            sendRequest("get", "name");
            // 4.解析响应
            obj = handleResponse();
            System.out.println("obj = " + obj);

            // 3.2.set name 虎哥
            sendRequest("mget", "name", "num", "msg");
            // 4.解析响应
            obj = handleResponse();
            System.out.println("obj = " + obj);
        } catch (IOException e) {
            e.printStackTrace();
        } finally {
            // 5.释放连接
            try {
                if (reader != null) reader.close();
                if (writer != null) writer.close();
                if (s != null) s.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }

    private static Object handleResponse() throws IOException {
        // 读取首字节
        int prefix = reader.read();
        // 判断数据类型标示
        switch (prefix) {
            case '+': // 单行字符串，直接读一行
                return reader.readLine();
            case '-': // 异常，也读一行
                throw new RuntimeException(reader.readLine());
            case ':': // 数字
                return Long.parseLong(reader.readLine());
            case '$': // 多行字符串
                // 先读长度
                int len = Integer.parseInt(reader.readLine());
                if (len == -1) {
                    return null;
                }
                if (len == 0) {
                    return "";
                }
                // 再读数据,读len个字节。我们假设没有特殊字符，所以读一行（简化）
                return reader.readLine();
            case '*':
                return readBulkString();
            default:
                throw new RuntimeException("错误的数据格式！");
        }
    }

    private static Object readBulkString() throws IOException {
        // 获取数组大小
        int len = Integer.parseInt(reader.readLine());
        if (len <= 0) {
            return null;
        }
        // 定义集合，接收多个元素
        List<Object> list = new ArrayList<>(len);
        // 遍历，依次读取每个元素
        for (int i = 0; i < len; i++) {
            list.add(handleResponse());
        }
        return list;
    }

    // set name 虎哥
    private static void sendRequest(String ... args) {
        writer.println("*" + args.length);
        for (String arg : args) {
            writer.println("$" + arg.getBytes(StandardCharsets.UTF_8).length);
            writer.println(arg);
        }
        writer.flush();
    }
}

3.2 总结

RESP（REdis Serialization Protocol）是Redis使用的通信协议，用于在客户端和服务器之间传输数据。RESP协议采用文本协议格式，具有简单、高效和可读性好的特点。下面是RESP协议的一些关键特点和示例：

1. 简单的数据类型：
   • RESP协议支持以下几种数据类型：简单字符串（Simple Strings）、错误信息（Errors）、整数（Integers）、大块字符串（Bulk Strings）和数组（Arrays）。
   • 每种数据类型都有对应的表示格式和解析规则。
2. 固定格式：
   • RESP协议的每个数据类型都以特定的前缀字符作为标识符。
   • 简单字符串以"+“作为前缀，例如："+OK\r\n"表示一个简单字符串"OK”。
   • 错误信息以"-"作为前缀，例如："-Error message\r\n"表示一个错误信息"Error message"。
   • 整数以":"作为前缀，例如：":1000\r\n"表示一个整数1000。
   • 大块字符串以"$"作为前缀，后跟字符串的字节数和实际字符串内容，例如："$5\r\nHello\r\n"表示一个长度为5的字符串"Hello"。
   • 数组以"*"作为前缀，后跟数组元素的数量和实际元素内容，例如："*3\r\n$5\r\nHello\r\n$5\r\nWorld\r\n:123\r\n"表示一个包含三个元素的数组，分别是字符串"Hello"、字符串"World"和整数123。
3. 客户端请求和服务器响应：
   • 客户端向服务器发送命令请求时，将命令和参数按RESP协议的格式进行编码，然后通过套接字发送给服务器。
   • 服务器接收到客户端请求后，解析RESP协议的编码格式，执行相应的命令操作，并将执行结果按RESP协议的格式进行编码，发送回客户端。

示例： 下面是一个示例，展示了RESP协议的编码和解码过程：

客户端请求： SET mykey Hello

编码后的请求： *3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$5\r\nHello\r\n

服务器响应： +OK

编码后的响应： "+OK\r\n"

总结： RESP协议是Redis使用的通信协议，采用简单的文本格式，具有固定的数据类型和编码规则。它支持简单字符串、错误信息、整数、大块字符串和数组等数据类型。客户端和服务器通过RESP协议编码和解码数据，实现命令请求和响应的交互。RESP协议的简单性和可读性使其易于实现和调试，并在Redis中发挥着关键作用。

四、Redis内存策略

Redis中的内存策略主要包含下列四点：

1. 内存清除策略（Eviction Policy）：当Redis内存空间不足时，会根据特定的算法删除一些key来释放内存。其中，常用的算法有LRU（最近最少使用）、LFU（最少使用频率）和随机算法。

2. 内存淘汰策略（Expiration）：在插入或更新key的时候，可以指定key的过期时间（expire）时间。过期后，Redis会自动将key删除，释放内存。

3. 内存回收策略（Memory Reclamation）：在使用Redis时，可能会因为未正确释放内存而导致内存泄漏。Redis针对这种情况实现了自动内存回收机制来防止内存泄漏的问题。

4. 内存优化策略（Memory Optimization）：Redis提供了各种内存优化策略，例如使用压缩（压缩整数值、压缩非常短的字符串）、使用哈希对象来优化内存使用等，以最大限度地减少内存使用。Redis也使用专门的数据结构来实现某些特定的数据类型，例如基数计数器和位数组，这些也是为了优化内存使用而设计的。

这些策略可以帮助Redis在处理大量数据时保持高效并避免内存溢出。但也需要注意，在处理大量数据时，仍然需要监控内存使用情况，并及时优化和调整内存策略。

4.1 过期策略 - key处理

Redis之所以性能强，最主要的原因就是基于内存存储。然而单节点的Redis其内存大小不宜过大，会影响持久化或主从同步性能。
我们可以通过修改配置文件来设置Redis的最大内存：

当内存使用达到上限时，就无法存储更多数据了。为了解决这个问题，Redis提供了一些策略实现内存回收：内存过期策略

可以通过expire命令给Redis的key设置TTL（存活时间）：

可以发现，当key的TTL到期以后，再次访问name返回的是nil，说明这个key已经不存在了，对应的内存也得到释放。从而起到内存回收的目的。

4.1.1 Redis是如何知道一个key是否过期呢？

DB结构体

Redis本身是一个典型的key-value内存存储数据库，因此所有的key、value都保存在之前学习过的Dict结构中。

Redis判断一个key是否过期：不过是在其database结构体中，有两个Dict：一个用来记录key-value；另一个用来记录key-TTL

4.1.2 是不是TTL到期就立即删除了呢？

惰性删除

惰性删除：顾明思议并不是在TTL到期后就立刻删除，而是在访问一个key的时候，检查该key的存活时间，如果已经过期才执行删除。也就是在增删改查的时候才会去检查这个key去判断这个key是否有过期。

周期删除

周期删除：顾明思议是通过一个定时任务，周期性的抽样部分过期的key，然后执行删除。执行周期有两种：

1. 在Redis服务**初始化函数initServer()**中设置定时任务serverCron()，按照server.hz的频率来执行过期key清理，模式为SLOW
2. 在Redis的每个事件循环前会调用beforeSleep()函数，执行过期key清理，模式为FAST

SLOW模式规则：

• 执行频率受server.hz影响，默认为10，即每秒执行10次，每个执行周期100ms。
• 执行清理耗时不超过一次执行周期的25%.默认slow模式耗时不超过25ms
• 逐个遍历db，逐个遍历db中的bucket，抽取20个key判断是否过期
• 如果没达到时间上限（25ms）并且过期key比例大于10%(就是过期的key和数据库中总的key进行对比)，再进行一次抽样，否则结束

FAST模式规则（过期key比例小于10%不执行 ）：

• 执行频率受beforeSleep()调用频率影响，但两次FAST模式间隔不低于2ms
• 执行清理耗时不超过1ms
• 逐个遍历db，逐个遍历db中的bucket，抽取20个key判断是否过期
  如果没达到时间上限（1ms）并且过期key比例大于10%，再进行一次抽样，否则结束

4.1.3 小总结

RedisKey的TTL记录方式：

• 在RedisDB中通过一个Dict记录每个Key的TTL时间

过期key的删除策略：

• 惰性清理：每次查找key时判断是否过期，如果过期则删除

• 定期清理：定期抽样部分key，判断是否过期，如果过期则删除。
  定期清理的两种模式：

• SLOW模式执行频率默认为10，每次不超过25ms

• FAST模式执行频率不固定，但两次间隔不低于2ms，每次耗时不超过1ms

4.2 Redis内存回收-内存淘汰策略

内存淘汰：就是当Redis内存使用达到设置的上限时，主动挑选部分key删除以释放更多内存的流程。Redis会在处理客户端命令的方法processCommand()中尝试做内存淘汰

Redis支持8种不同策略来选择要删除的key：

1. noeviction： 不淘汰任何key，但是内存满时不允许写入新数据，默认就是这种策略。
2. volatile-ttl： 对设置了TTL的key，比较key的剩余TTL值，TTL越小越先被淘汰
3. allkeys-random：对全体key ，随机进行淘汰。也就是直接从db->dict中随机挑选
4. volatile-random：对设置了TTL的key ，随机进行淘汰。也就是从db->expires中随机挑选。
5. allkeys-lru： 对全体key，基于LRU算法进行淘汰
6. volatile-lru： 对设置了TTL的key，基于LRU算法进行淘汰
7. allkeys-lfu： 对全体key，基于LFU算法进行淘汰
8. volatile-lfu： 对设置了TTL的key，基于LFI算法进行淘汰。其中比较容易混淆的有两个：
9. LRU（Least Recently Used），最少最近使用。用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高。
10. LFU（Least Frequently Used），最少频率使用。会统计每个key的访问频率，值越小淘汰优先级越高。

Redis的数据都会被封装为RedisObject结构：

LFU的访问次数之所以叫做逻辑访问次数，是因为并不是每次key被访问都计数，而是通过运算：

1. 生成0~1之间的随机数R
2. 计算 (旧次数 * lfu_log_factor + 1)，记录为P
3. 如果 R < P ，则计数器 + 1，且最大不超过255
4. 访问次数会随时间衰减，距离上一次访问时间每隔 lfu_decay_time 分钟，计数器 -1

当Redis使用的内存超出maxmemory设置时，会根据指定的淘汰策略在键空间中选择要删除的键值对。在删除键值对时，Redis会先检查该键值对是否在使用中（例如，有没有客户端正在访问该键值对），然后再根据具体的淘汰策略选择一个待删除的键值对，并将其从缓存中清除。

最后用一副图来描述当前的这个流程吧

如果把redis全部的key都拿出来进行比较在淘汰这样消耗的时间就会大大的增大所以这里就引入了一个叫eviction——pool（驱逐池）eviction_pool就是抽取的一些样本，将样本放到池子里，再去比较看看谁应该被淘汰，这里有一个maxmemory_samples默认值是5，但是策略不同淘汰的方式不同，这样实现就会比较麻烦所以这里进行了统一，就是按照key其中的某一个值的升序排列，值越大的优先淘汰

例如LFU最少频率使用，使用的越少就应该越早被淘汰，但是是升序排列的，那么就用255-LFU计算，LFU越少255-LFU就越大越应该被淘汰

再说说怎么优化Redis内存

4.3 内存优化策略

Redis中的内存优化策略可以帮助Redis在处理大量数据时最大限度地减少内存使用和提升性能。以下是常见的内存优化策略：

1. 压缩整数值：Redis会根据使用的整数值类型（int16、int32）的不同，动态地压缩整数值的内存占用大小，将8字节的long类型压缩到int类型的4字节，将4字节的int类型压缩到short类型的2字节，以此来减少内存占用。（整数值的大小可以影响内存占用，而Redis可以根据数字类型的不同，动态地压缩整数值的内存占用大小）
2. 压缩短字符串：在Redis内部，长度小于一定值的字符串被称为小字符串，并且对小字符串进行压缩。默认情况下，当字符串的长度小于44个字节时，Redis会动态地把它压缩到一个长度更短的编码中，减少内存占用。（当字符串的长度小于一定值时，Redis会自动把它压缩到一个长度更短的编码中）
3. 使用哈希对象：当需要存储一批内存占用相同的键值对对象时，可以使用哈希对象，把所有的对象都存储在一个哈希表里，以此优化内存使用。（当需要存储一批内存占用相同的键值对对象时，可以使用Redis中的哈希对象，把所有的对象都存储在一个哈希表里，以此优化内存使用。）
4. 使用专用数据结构：Redis使用专用的数据结构来优化某些特定类型的数据，例如在位图中，每个位使用1或0来表示某个事件发生或未发生，以此来大大减少内存占用。Redis还在内存里实现了基数估算器，这个数据结构可以帮助快速估算一批数据的唯一值的数量。
5. 删除大列表的尾部：当某个列表的长度很大，比如数百万条甚至数千万条记录时，删除列表头部的记录（从左边开始）可能会变得很慢。此时，可以采用删除列表尾部（从右边开始）的方式，这样就可以在常数时间内完成删除操作。

接下来我将举几个Redis中的内存优化策略的例子：

1. 压缩整数值： 假设您在Redis中存储了一个计数器，每次增加1。如果您的计数器始终保持在0到255之间，Redis会使用8位编码来存储该整数值，而不是使用更大的数据类型。这样，Redis可以节省内存并提高存储效率。

2. 压缩短字符串： 假设您有一个Redis键存储了一组国家名称的字符串，例如"China"、“USA"和"India”。由于这些字符串很短，Redis可以使用intset数据结构来存储它们，而不是使用较大的数据结构。这样可以显著减少内存使用。

3. 使用哈希对象： 假设您在Redis中存储了一个用户对象，其中包含用户名、电子邮件和年龄等信息。当对象较小且字段数量有限时，Redis可能会使用ziplist来存储该哈希对象，而不是使用更大的散列表。这样可以节省内存并提高性能。

4. 使用专用数据结构： 假设您需要在Redis中存储一组用户ID的布隆过滤器，以快速判断某个用户ID是否存在。布隆过滤器是一种空间效率很高的数据结构，它可以用较少的内存占用来判断元素的存在性。通过使用布隆过滤器，您可以节省大量内存而不必存储所有用户ID的实际值。

5. 删除大列表的尾部： 假设您有一个Redis列表用于存储日志消息，每天会不断向该列表中添加新的消息。为了避免内存占用过高，您可以定期使用LTRIM命令来删除列表的尾部元素，只保留最近的一部分日志。这样可以限制列表的长度，减少内存使用，并确保Redis性能良好。

6. 压缩整数值：Redis会根据使用的整数值类型（int16、int32）的不同，动态地压缩整数值的内存占用大小，将8字节的long类型压缩到int类型的4字节，将4字节的int类型压缩到short类型的2字节，以此来减少内存占用。（整数值的大小可以影响内存占用，而Redis可以根据数字类型的不同，动态地压缩整数值的内存占用大小）

7. 压缩短字符串：在Redis内部，长度小于一定值的字符串被称为小字符串，并且对小字符串进行压缩。默认情况下，当字符串的长度小于44个字节时，Redis会动态地把它压缩到一个长度更短的编码中，减少内存占用。（当字符串的长度小于一定值时，Redis会自动把它压缩到一个长度更短的编码中）

8. 使用哈希对象：当需要存储一批内存占用相同的键值对对象时，可以使用哈希对象，把所有的对象都存储在一个哈希表里，以此优化内存使用。（当需要存储一批内存占用相同的键值对对象时，可以使用Redis中的哈希对象，把所有的对象都存储在一个哈希表里，以此优化内存使用。）

9. 使用专用数据结构：Redis使用专用的数据结构来优化某些特定类型的数据，例如在位图中，每个位使用1或0来表示某个事件发生或未发生，以此来大大减少内存占用。Redis还在内存里实现了基数估算器，这个数据结构可以帮助快速估算一批数据的唯一值的数量。

10. 删除大列表的尾部：当某个列表的长度很大，比如数百万条甚至数千万条记录时，删除列表头部的记录（从左边开始）可能会变得很慢。此时，可以采用删除列表尾部（从右边开始）的方式，这样就可以在常数时间内完成删除操作。

接下来我将举几个Redis中的内存优化策略的例子：

1. 压缩整数值： 假设您在Redis中存储了一个计数器，每次增加1。如果您的计数器始终保持在0到255之间，Redis会使用8位编码来存储该整数值，而不是使用更大的数据类型。这样，Redis可以节省内存并提高存储效率。
2. 压缩短字符串： 假设您有一个Redis键存储了一组国家名称的字符串，例如"China"、“USA"和"India”。由于这些字符串很短，Redis可以使用intset数据结构来存储它们，而不是使用较大的数据结构。这样可以显著减少内存使用。
3. 使用哈希对象： 假设您在Redis中存储了一个用户对象，其中包含用户名、电子邮件和年龄等信息。当对象较小且字段数量有限时，Redis可能会使用ziplist来存储该哈希对象，而不是使用更大的散列表。这样可以节省内存并提高性能。
4. 使用专用数据结构： 假设您需要在Redis中存储一组用户ID的布隆过滤器，以快速判断某个用户ID是否存在。布隆过滤器是一种空间效率很高的数据结构，它可以用较少的内存占用来判断元素的存在性。通过使用布隆过滤器，您可以节省大量内存而不必存储所有用户ID的实际值。
5. 删除大列表的尾部： 假设您有一个Redis列表用于存储日志消息，每天会不断向该列表中添加新的消息。为了避免内存占用过高，您可以定期使用LTRIM命令来删除列表的尾部元素，只保留最近的一部分日志。这样可以限制列表的长度，减少内存使用，并确保Redis性能良好。