Redis知识点整理

redis

数据结构

SDS

普通字符串

字符串是Redis中最为常见的数据存储类型，其底层实现是简单动态字符串sds(simple dynamic string)，是可以修改的字符串。
它类似于Java中的ArrayList，它采用预分配冗余空间的方式来减少内存的频繁分配。

如图中所示，内部为当前字符串实际分配的空间 。其中capacity是最大容量，len是实际长度，一般要高于实际字符串长度 len。
当字符串长度小于 1M 时，扩容都是加倍现有的空间，如果超过 1M，扩容时一次只会多扩 1M 的空间。(字符串最大长度为 512M)

动态SDS字符串

SDS本质上就是char *，因为有了表头sdshdr结构的存在，所以SDS比传统C字符串在某些方面更加优秀，并且能够兼容传统C字符串。

sds在Redis中是实现字符串对象的工具，并且完全取代char*…sds是二进制安全的，它可以存储任意二进制数据，不像C语言字符串那样以‘\0’来标识字符串结束，

因为传统C字符串符合ASCII编码，这种编码的操作的特点就是：遇零则止 。即，当读一个字符串时，只要遇到’\0’结尾，就认为到达末尾，就忽略’\0’结尾以后的所有字符。因此，如果传统字符串保存图片，视频等二进制文件，操作文件时就被截断了。

SDS表头的buf被定义为字节数组，因为判断是否到达字符串结尾的依据则是表头的len成员，这意味着它可以存放任何二进制的数据和文本数据，包括’\0’

SDS 和传统的 C 字符串获得的做法不同，传统的C字符串遍历字符串的长度，遇零则止，复杂度为O(n)。而SDS表头的len成员就保存着字符串长度，所以获得字符串长度的操作复杂度为O(1)。

总结下sds的特点是：可动态扩展内存、二进制安全、快速遍历字符串 和与传统的C语言字符串类型兼容。

SDS结构体

而Redis 的字符串共有两种存储方式，在长度特别短时，使用 emb 形式存储 (embedded)，当长度超过 44 时，使用 raw 形式存储。

embstr 存储形式是这样一种存储形式，它将 RedisObject 对象头和 SDS 对象连续存在一起，使用 malloc 方法一次分配。而 raw 存储形式不一样，它需要两次 malloc，两个对象头在内存地址上一般是不连续的。

在字符串比较小时，SDS 对象头的大小是capacity+3——SDS结构体的内存大小至少是 3。意味着分配一个字符串的最小空间占用为 19 字节 (16+3)。

如果总体超出了 64 字节，Redis 认为它是一个大字符串，不再使用 emdstr 形式存储，而该用 raw 形式。而64-19-结尾的\0，所以empstr只能容纳44字节

扩容策略

扩容策略是字符串在长度小于 SDS_MAX_PREALLOC 之前，扩容空间采用加倍策略，也就是保留 100% 的冗余空间。当长度超过 SDS_MAX_PREALLOC 之后，为了避免加倍后的冗余空间过大而导致浪费，每次扩容只会多分配 SDS_MAX_PREALLOC大小的冗余空间

通过SDS的len属性和free属性可以实现两种内存分配的优化策略：空间预分配和惰性空间释放

1.针对内存分配的策略：空间预分配

在对SDS的空间进行扩展的时候，程序不仅会为SDS分配修改所必须的空间，还会为SDS分配额外的未使用的空间

这样可以减少连续执行字符串增长操作所需的内存重分配次数，通过这种预分配的策略，SDS将连续增长N次字符串所需的内存重分配次数从必定N次降低为最多N次，这是个很大的性能提升！

2.针对内存释放的策略：惰性空间释放

在对SDS的字符串进行缩短操作的时候，程序并不会立刻使用内存重分配来回收缩短之后多出来的字节，而是使用free属性将这些字节的数量记录下来等待将来使用，通过惰性空间释放策略，SDS避免了缩短字符串时所需的内存重分配次数，并且为将来可能有的增长操作提供了优化！

链表

Redis使用的链表是双向无环链表，链表节点可用于保存各种不同类型的值。

对于List链表，它的本质是一个双向链表的结构，每个元素都是一个结点。熟悉Java的同学，可以将Redis中的list列表结构，看做是Java中的LinkedList结构。
由于Redis的List结构的是双向链表结构，所以这也代表了它的插入和删除操作非常快，时间复杂度为 O(1)，索引定位很慢，时间复杂度为 O(n)

t_list对链表的描述不仅仅是双向链表那么简单，在早期Redis版本中，它描述了ziplist压缩表和linkedlist普通链表。在元素较少时，使用的是ziplist压缩表，在元素较多时，使用的则是linkedlist。

在Redis 3.2之后的版本中，由于链表的附加空间——prev和next指针，相对太高，需要两个指针大小。这两个指针在32位系统需要占据8个字节，64位更是16字节。所以在后期版本中，推出了quicklist来对ziplist和linkedlist的结构进行了优化。

quicklist 是 ziplist 和 linkedlist 的混合体，它将 linkedlist 按段切分，每一段使用 ziplist 来紧凑存储，多个 ziplist 之间使用双向指针串接起来。这样既满足了快速的插入删除性能，又不会出现太大的空间冗余。

ziplist的结构如图：

压缩列表为了支持双向遍历，所以才会有 ztail_offset 这个字段，通过这个字段，可以快速定位到最后一个元素，然后倒着进行链表的遍历。

除了ziplist本身所使用的存储空间少外，Redis 还会对 ziplist 进行压缩存储，使用 LZF 算法压缩，可以选择压缩深度。

quicklist是由ziplist组成的双向链表，链表中的每一个节点都以压缩列表ziplist的结构保存着数据，而ziplist有多个entry节点，保存着数据。相当与一个quicklist节点保存的是一片数据，而不再是一个数据。

quicklist 内部默认单个 ziplist 长度为 8k 字节，超出了这个字节数，就会新起一个 ziplist。ziplist 的长度由配置参数list-max-ziplist-size决定。

quicklist的特点：

quicklist宏观上是一个双向链表，因此，它具有一个双向链表的有点，进行插入或删除操作时非常方便，虽然复杂度为O(n)，但是不需要内存的复制，提高了效率，而且访问两端元素复杂度为O(1)。
quicklist微观上是一片片entry节点，每一片entry节点内存连续且顺序存储，可以通过二分查找以 [Math Processing Error] 的复杂度进行定位。

字典

字典又称符号表，关联数组或者映射，是一种用于保存键值对的抽象数据结构。
字典中的每个键都是独一无二的，程序可以在字典中根据键值查找与之关联的值，或者通过键来更新值，删除等。

哈希表

Redis字典所使用的哈希表由 dict.h/dictht结构定义：

typedef struct dictht{
     //哈希表数组
     dictEntry **table;
     //哈希表大小
     unsigned long size;
     //哈希表大小掩码，用于计算索引值
     //总是等于 size-1
     unsigned long sizemask;
     //该哈希表已有节点的数量
     unsigned long used;
     }dictht；

table属性是一个数组，数组中的每一个元素都是一个指向dict.h/dictEntry结构的指针，每个dictEntry结构保存着一个键值对。
sizemask属性的值总是等于size-1，这个属性和哈希值一起决定一个键应该被放在什么位置

哈希表节点

哈希表节点使用dictEntry结构表示，每个dictEntry结构都保存着一个键值对；

typedef struct dictEntry{
     //键
     void *key;
     //值
     union{
          void *val;
          uint64_tu64;
          int64_ts64;
     }v;

     //指向下一个哈希表节点，形成链表
     struct dictEntry *next;
}dictEntry；

从源码可以看出，保存的值（v）可以是一个指针，或者一个uint_t整数，又或者是一个int64_t整数。
next属性是指向另一个哈希表节点的指针。
所以多个相同值经过哈希算法可以形成相同索引的一个拉链表结构（每个节点加一个指针，指向相同索引的节点）

字典结构

Redis中的字典是由dict.h/dict结构表示

typedef struct dict{
   //类型特定函数
	dictType *type;
	//私有数据
	void *privdata;
	//哈希表
	dictht ht[2];
	//rehash索引
	//当rehash不在进行时，值为-1
	int rehashidx;
}dict;

ht属性是一个包含两个项的数组，数组中的每个顶都是一个dictht哈希表，一般情况下只使用ht[0]哈希表，ht[1]哈希表只会在进行rehash时使用，我们后面详细说，包括rehashidx也是在rehash时用到的。

接下来我们再看字典的结构，就能清楚很多了吧

解决键冲突

这个就是上面提到的哈希冲突，解决他的办法有两种，开放寻址法和拉链法，Redis很明显采用的是后者，后者很明显更加清晰，存取更加方便，第一种数据不多还好，如果数据量特别大的时候，插入，查找，删除，修改都是一件很困难的事情，时间复杂度太高。

rehash（重新散列）

随着操作的不断执行，哈希表保存的键值会逐渐地增多或者减少，为了让哈希表的负载因子维持在一个哈利的范围之内，当哈希表存储的键值对太多或者太少，程序要对哈希表的大小进行相应的扩展或者收缩。
这就是我们要说的rehash，这里我们解释一下负载因子
负载因子=哈希表以保存的节点数量/哈希表的大小
load_factor=ht[0].used/ht[0].size

那么什么时候才会rehash呢？

条件：
1）服务器目前没有执行的BGSAVE命令或者BGREWRUTEAOF命令，并且哈希表的负载因子大于等于1；
2）服务器目前正在执行BGSAVE命令或者BGREWRUTEAOF命令，并且哈希表的负载因子大于等于5；

这里简单解释一下BGSAVE，这个命令是redis进行RDB持久化时所用到的命令，持久化会在后面讲到，就是从内存写入磁盘的过程；BGREWRUTEAOF就是另一种AOF持久化方式的工作方式，也就是在Redis进行持久化的时候，可能会触发rehash。

rehash的实现原理

如何进行rehash呢，再将具体的步骤，方法时，我先用自己的话说一下原理，方便大家理解。

既然要进行重新散列，那么原来的表肯定是不适合了，所以要重新开辟一张表，这就是上面我们所说的ht[1],之所以维持两张表就是这个原因，如果需要扩容，
那么扩容后的长度也就是ht[1].size=ht[0].used*2的2^n,缩小
的话就是ht[1].size=ht[0].used的2^n,准备条件好了就要开始移动了，

直到0号哈希表中没有保存的节点，这时候释放空表的空间，将ht[1]更名为ht[0]，然后将ht[1]置为空，就完成了rehash。

！！！如果像这样rehash的话，如果你的字典中存储这几万条，几十万条，几百万条的数据时，如果我们一次性的，集中式的把这些数据rehash，那估计服务器就不能再进行其它服务了，高性能的Redis是绝对不允许这种事情发生的，所以接下来就是我们重点说的，渐进式rehash。

渐进式rehash

我们还是先解释再看源码，先说一下是怎么渐进式的

不知道大家是否还记得之前提到过的一个字段rehashidx，没错就是他，索引计数器，记录了rehash的进度。

以下是哈希表渐进式 rehash 的详细步骤：

1）为 ht[1] 分配空间， 让字典同时持有 ht[0] 和 ht[1] 两个哈希表。
2）在字典中维持一个索引计数器变量 rehashidx ， 并将它的值设置为 0 ， 表示 rehash 工作正式开始。
3）在 rehash 进行期间， 每次对字典执行添加、删除、查找或者更新操作时， 程序除了执行指定的操作以外， 还会顺带将 ht[0] 哈希表在 rehashidx 索引上的所有键值对 rehash 到 ht[1] ， 当 rehash 工作完成之后， 程序将 rehashidx 属性的值增一。
4）随着字典操作的不断执行， 最终在某个时间点上， ht[0] 的所有键值对都会被 rehash 至 ht[1] ， 这时程序将 rehashidx 属性的值设为 -1 ， 表示 rehash 操作已完成。

看下来rehashidx一共有三种状态，0表示要开始进行rehash，-1表示rehash结束或目前没有进行，其它就是rehash过程中的进度表示了

跳表

这种带多级索引的链表，就是跳表。

跳表有多快？

单链表的查找一个元素的时间复杂度为O(n)，那么跳表的时间复杂度是多少？

假如链表中有 n 个元素，我们每两个节点建立一个索引，那么第 1 级索引的结点个数就是 n/2 ，第二级就是 n/4，第三级就是 n/8, 依次类推，也就是说第 k 级索引的结点个数是第 k-1 级索引的结点个数的 1/2，那么第k级索引的节点个数为 n 除以 2 的 k 次方，即

\frac{n}{2^k}

假设索引有 h 级，最高级的索引有 2 个结点。通过上面的公式，我们可以得到

\frac{n}{2^h} = 2

即 h=log2n - 1

，得到 ，包含原始链表这一层的话，跳表的高度就是 log2n，假设每层需要访问 m 个结点，那么总的时间复杂度就是O(m*log2n)。而每层需要访问的 m 个结点，m 的最大值不超过 3，这里为什么是 3 ，可以自己试着走一个。
因此跳表的时间复杂度为

O(3log2n) = O(log2n)

跳表有多占内存？

天下没有免费的午餐，时间复杂度能做到 O(logn) 是以建立在多级索引的基础之上，这会导致内存占用增加，那么跳表的空间复杂度是多少呢？

假如有 n 个元素的链表，第一级索引为 n/2 个，第二级为 n/4 个，第三级为 n/8 个，…，最后一级为 2 个。这几级索引的结点总和就是n/2+n/4+n/8…+8+4+2=n-2。所以，跳表的空间复杂度是 O(n)。也就是说，如果将包含 n 个结点的单链表构造成跳表，我们需要额外再用接近 n 个结点的存储空间。那我们有没有办法降低索引占用的内存空间呢？

假如每 3 个节点抽取一个作为索引，同样的方法，可以计算出空间复杂度为 O(n/2) ,已经节约一半的存储空间了。

实际上，在软件开发中，我们不必太在意索引占用的额外空间。在讲数据结构和算法时，我们习惯性地把要处理的数据看成整数，但是在实际的软件开发中，原始链表中存储的有可能是很大的对象，而索引结点只需要存储几个指针，并不需要存储对象，所以当对象比索引结点大很多时，那索引占用的额外空间就可以忽略了。

skiplist与平衡树、哈希表的比较

1. skiplist和各种平衡树（如AVL、红黑树等）的元素是有序排列的，而哈希表不是有序的。因此，在哈希表上只能做单个key的查找，不适宜做范围查找。所谓范围查找，指的是查找那些大小在指定的两个值之间的所有节点。
2. 在做范围查找的时候，平衡树比skiplist操作要复杂。在平衡树上，我们找到指定范围的小值之后，还需要以中序遍历的顺序继续寻找其它不超过大值的节点。如果不对平衡树进行一定的改造，这里的中序遍历并不容易实现。而在skiplist上进行范围查找就非常简单，只需要在找到小值之后，对第1层链表进行若干步的遍历就可以实现。
3. 平衡树的插入和删除操作可能引发子树的调整，逻辑复杂，而skiplist的插入和删除只需要修改相邻节点的指针，操作简单又快速。
4. 从内存占用上来说，skiplist比平衡树更灵活一些。一般来说，平衡树每个节点包含2个指针（分别指向左右子树），而skiplist每个节点包含的指针数目平均为1/(1-p)，具体取决于参数p的大小。如果像Redis里的实现一样，取p=1/4，那么平均每个节点包含1.33个指针，比平衡树更有优势。
5. 查找单个key，skiplist和平衡树的时间复杂度都为O(log n)，大体相当；而哈希表在保持较低的哈希值冲突概率的前提下，查找时间复杂度接近O(1)，性能更高一些。所以我们平常使用的各种Map或dictionary结构，大都是基于哈希表实现的。
6. 从算法实现难度上来比较，skiplist比平衡树要简单得多。

2.1 Redis中跳跃表的实现

Redis的跳跃表由zskiplistNode和skiplist两个结构定义,其中 zskiplistNode结构用于表示跳跃表节点,而 zskiplist结构则用于保存跳跃表节点的相关信息,比如节点的数量,以及指向表头节点和表尾节点的指针等等。

Redis跳跃表

  上图展示了一个跳跃表示例,其中最左边的是 skiplist结构,该结构包含以下属性。

header:指向跳跃表的表头节点，通过这个指针程序定位表头节点的时间复杂度就为O(1)

tail:指向跳跃表的表尾节点,通过这个指针程序定位表尾节点的时间复杂度就为O(1)

level:记录目前跳跃表内,层数最大的那个节点的层数(表头节点的层数不计算在内)，通过这个属性可以再O(1)的时间复杂度内获取层高最好的节点的层数。

length:记录跳跃表的长度,也即是,跳跃表目前包含节点的数量(表头节点不计算在内)，通过这个属性，程序可以再O(1)的时间复杂度内返回跳跃表的长度。

结构右方的是四个 zskiplistNode结构,该结构包含以下属性

层(level):

    节点中用1、2、L3等字样标记节点的各个层,L1代表第一层,L代表第二层,以此类推。

    每个层都带有两个属性:前进指针和跨度。前进指针用于访问位于表尾方向的其他节点,而跨度则记录了前进指针所指向节点和当前节点的距离(跨度越大、距离越远)。在上图中,连线上带有数字的箭头就代表前进指针,而那个数字就是跨度。当程序从表头向表尾进行遍历时,访问会沿着层的前进指针进行。

    每次创建一个新跳跃表节点的时候,程序都根据幂次定律(powerlaw,越大的数出现的概率越小)随机生成一个介于1和32之间的值作为level数组的大小,这个大小就是层的“高度”。

后退(backward)指针：

    节点中用BW字样标记节点的后退指针,它指向位于当前节点的前一个节点。后退指针在程序从表尾向表头遍历时使用。与前进指针所不同的是每个节点只有一个后退指针，因此每次只能后退一个节点。

分值(score):

    各个节点中的1.0、2.0和3.0是节点所保存的分值。在跳跃表中,节点按各自所保存的分值从小到大排列。

成员对象(oj):

    各个节点中的o1、o2和o3是节点所保存的成员对象。在同一个跳跃表中,各个节点保存的成员对象必须是唯一的,但是多个节点保存的分值却可以是相同的:分值相同的节点将按照成员对象在字典序中的大小来进行排序,成员对象较小的节点会排在前面(靠近表头的方向),而成员对象较大的节点则会排在后面(靠近表尾的方向)。

Redis跳跃表常用操作的时间复杂度

操作	时间复杂度
创建一个跳跃表	O(1)
释放给定跳跃表以及其中包含的节点	O(N)
添加给定成员和分值的新节点	平均O(logN),最坏O(logN)(N为跳跃表的长度)
删除除跳跃表中包含给定成员和分值的节点	平均O(logN),最坏O(logN)(N为跳跃表的长度)
返回给定成员和分值的节点再表中的排位	平均O(logN),最坏O(logN)(N为跳跃表的长度)
返回在给定排位上的节点	平均O(logN),最坏O(logN)(N为跳跃表的长度)
给定一个分值范围,返回跳跃表中第一个符合这个范围的节点	O(1)
给定一个分值范围,返回跳跃表中最后一个符合这个范围的节点	平均O(logN),最坏O(logN)(N为跳跃表的长度)
给定一个分值范围,除跳跃表中所有在这个范围之内的节点	平均O(logN),最坏O(logN)(N为跳跃表的长度)
给定一个排位范围,鼎除跳跃表中所有在这个范围之内的节点	O(N),N为被除节点数量
给定一个分值范固(range),比如0到15,20到28,诸如此类,如果跳氏表中有至少一个节点的分值在这个范間之内,那么返回1,否则返回0	O(N),N为被除节点数量

跳表总结

跳跃表基于单链表加索引的方式实现
跳跃表以空间换时间的方式提升了查找速度
Redis有序集合在节点元素较大或者元素数量较多时使用跳跃表实现
Redis的跳跃表实现由 zskiplist和 zskiplistnode两个结构组成,其中 zskiplist用于保存跳跃表信息(比如表头节点、表尾节点、长度),而zskiplistnode则用于表示跳跃表节点
Redis每个跳跃表节点的层高都是1至32之间的随机数
在同一个跳跃表中,多个节点可以包含相同的分值,但每个节点的成员对象必须是唯一的跳跃表中的节点按照分值大小进行排序,当分值相同时,节点按照成员对象的大小进行排序。

整数集合

整数集合(intset)并不是一个基础的数据结构，而是Redis自己设计的一种存储结构，是集合键的底层实现之一,当一个集合只包含整数值元素,并且这个集合的元素数量不多时, Redis i就会使用整数集合作为集合键的底层实现。

整数集合(intset)是Redis用于保存整数值的集合抽象数据结构,它可以保存类型为int16_t、int32_t或者int64_t的整数值,并且保证集合中不会出现重复元素。

//每个intset结构表示一个整数集合
typedef struct intset{
    //编码方式
    uint32_t encoding;
    //集合中包含的元素数量
    uint32_t length;
    //保存元素的数组
    int8_t contents[];
} intset;

1. contents数组是整数集合的底层实现，整数集合的每个元素都是 contents数组的个数组项(item),各个项在数组中按值的大小从小到大有序地排列,并且数组中不包含任何重复项。
2. length属性记录了数组的长度。
3. intset结构将contents属性声明为int8_t类型的数组,但实际上 contents数组并不保存任何int8t类型的值, contents数组的真正类型取决于encoding属性的值。encoding属性的值为INTSET_ENC_INT16则数组就是uint16_t类型，数组中的每一个元素都是int16_t类型的整数值(-32768——32767)，encoding属性的值为INTSET_ENC_INT32则数组就是uint32_t类型，数组中的每一个元素都是int16_t类型的整数值(-2147483648——2147483647)。

整数集合升级过程

1. 正如上面所提到的问题，每当我们要将一个新元素添加到整数集合里面,并且新元素的类型比整数集合现有所有元素的类型都要长时,整数集合需要先进行升级,然后才能将新元素添加到整数集合里面。升级整数集合并添加新元素主要分三步来进行。

2. 根据新元素的类型,扩展整数集合底层数组的空间大小,并为新元素分配空间。

3. 将底层数组现有的所有元素都转换成与新元素相同的类型,并将类型转换后的元素放置到正确的位上,而且在放置元素的过程中,需要继续维持底层数组的有序性质不变。

4. 将新元素添加到底层数组里面。

整数集合常用操作时间复杂度

操作	时间复杂度
创建一个新的整数集合	O(1)
添加指定元素到集合	O(N)
移除指定元素	O(N)
判断指定元素是否在集合中	O(logN)
随机返回一个元素	O(1)
取出在指定索引上的元素	O(1)
返回集合包含的元素个数	O(1)
返回集合占用的内存字节数	O(1)

整数集合总结

1. 整数集合是Redis自己设计的一种存储结构,集合键的底层实现之一。
2. 整数集合的底层实现为数组,这个数组以有序、无重复的方式保存集合元素,在有需要时,程序会根据新添加元素的类型,改变这个数组的类型。
3. 升级操作为整数集合带来了操作上的灵活性,并且尽可能地节约了内存。
4. 整数集合只支持升级操作,不支持降级操作。

压缩列表

听到“压缩”两个字，直观的反应就是节省内存。之所以说这种存储结构节省内存,是相较于数组的存储思路而言的。我们知道,数组要求每个元素的大小相同,如果我们要存储不同长度的字符串,那我们就需要用最大长度的字符串大小作为元素的大小(假设是20个字节)。存储小于 20 个字节长度的字符串的时候，便会浪费部分存储空间。

数组的优势占用一片连续的空间可以很好的利用CPU缓存访问数据。如果我们想要保留这种优势，又想节省存储空间我们可以对数组进行压缩。

但是这样有一个问题，我们在遍历它的时候由于不知道每个元素的大小是多少，因此也就无法计算出下一个节点的具体位置。这个时候我们可以给每个节点增加一个lenght的属性。

如此。我们在遍历节点的之后就知道每个节点的长度(占用内存的大小)，就可以很容易计算出下一个节点再内存中的位置。这种结构就像一个简单的压缩列表了。

Redis压缩列表

压缩列表(ziplist)是列表和哈希的底层实现之一。
当一个列表只包含少量列表项,并且每个列表项要么就是小整数值,要么就是长度比较短的字符串,那么Redis就会使用压缩列表来做列表的底层实现。
当一个哈希只包含少量键值对,比且每个键值对的键和值要么就是小整数值,要么就是长度比较短的字符串,那么Redis就会使用压缩列表来做哈希的底层实现。

Redis压缩列表的构成

压缩列表是Redis为了节约内存而开发的,是由一系列特殊编码的连续内存块组成的顺序型(sequential)数据结枃。一个压缩列表可以包含任意多个节点(entry),每个节点可以保存一个字节数组或者一个整数值，如下图。

示例：

如上图，展示了一个总长为80字节，包含3个节点的压缩列表。如果我们有一个指向压缩列表起始地址的指针p，那么表为节点的地址就是P+60。

Redis压缩列表节点的构成

每个压缩列表节点可以保存一个字节数组或者一个整数值。其中，字节数组可以是以下三种长度中的一种。

• 长度小于等于63(2^6-1)字节的字节数组;
• 长度小于等于16383(2^14-1)字节的字节数组
• 长度小于等于4294967295(2^32-1)字节的字节数组

整数值可以是以下6种长度中的一种

• 4位长,介于0至12之间的无符号整数
• 1字节长的有符号整数
• 3字节长的有符号整数
• int16_t类型整数
• int32_t类型整数
• int64_t类型整数

常用操作的时间复杂度

操作	时间复杂度
创建一个新的压缩列表	O(1)
创建一个包含给定值的新节点,并将这个新节点添加到压缩列表的表头或者表尾	平均O(N)，最坏O(N^2)(可能发生连锁更新)
将包含给定值的新节点插人到给定节点之后	平均O(N)，最坏O(N^2)(可能发生连锁更新)
返回压缩列表给定索引上的节点	O(N)
在压缩列表中査找并返回包含了给定值的节点	因为节点的值可能是一个字节数组,所以检查节点值和给定值是否相同的复杂度为O(N),而查找整个列表的复杂度则为(N^2)
返回给定节点的下一个节点	O(1)
返回给定节点的前一个节点	O(1)
获取给定节点所保存的值	O(1)
从压缩列表中删除给定的节点	平均O(N)，最坏O(N^2)(可能发生连锁更新)
删除压缩列表在给定索引上的连续多个	平均O(N)，最坏O(N^2)(可能发生连锁更新)
返回压缩列表目前占用的内存字节数	O(1)
返回压缩列表目前包含的节点数量	点数量小于65535时为O(1),大于65535时为O(N)

压缩列表总结

• 压缩列表是Redis为节约内存自己设计的一种顺序型数据结构。
• 压缩列表被用作列表键和哈希键的底层实现之一。
• 压缩列表可以包含多个节点,每个节点可以保存一个字节数组或者整数值。
• 添加新节点到压缩列表,或者从压缩列表中删除节点,可能会引发连锁更新操作,但这种操作出现的几率并不高。

Streams

认识Streams

为了理解Redis流是什么以及如何使用它们，我们将忽略所有高级功能，而是根据用于操作和访问它的命令来关注数据结构本身。这基本上是大多数其他Redis数据类型共有的部分，如列表，集合，排序集等。但是，请注意，列表还有一个可选的更复杂的阻塞API，由BLPOP等命令导出。因此，流与这方面的列表没有太大的不同，只是附加的API更复杂，更强大。

详细介绍

事物

Redis事务的概念：

Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。

总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

Redis事务没有隔离级别的概念：

批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到。

Redis不保证原子性：

Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

Redis事务的三个阶段：

• 开始事务
• 命令入队
• 执行事务

Redis事务相关命令：

watch key1 key2 … : 监视一或多个key,如果在事务执行之前，被监视的key被其他命令改动，则事务被打断 （ 类似乐观锁 ）

• multi : 标记一个事务块的开始（ queued ）
• exec : 执行所有事务块的命令（一旦执行exec后，之前加的监控锁都会被取消掉 ）
• discard : 取消事务，放弃事务块中的所有命令
• unwatch : 取消watch对所有key的监控

Redis事务使用案例：

（1）正常执行

（2）放弃事务

（3）若在事务队列中存在命令性错误（类似于java编译性错误），则执行EXEC命令时，所有命令都不会执行

（4）若在事务队列中存在语法性错误（类似于java的1/0的运行时异常），则执行EXEC命令时，其他正确命令会被执行，错误命令抛出异常。

（5）使用watch
案例一：使用watch检测balance，事务期间balance数据未变动，事务执行成功

案例二：使用watch检测balance，在开启事务后（标注1处），在新窗口执行标注2中的操作，更改balance的值，模拟其他客户端在事务执行期间更改watch监控的数据，然后再执行标注1后命令，执行EXEC后，事务未成功执行。

一但执行 EXEC 开启事务的执行后，无论事务使用执行成功， WARCH 对变量的监控都将被取消。
故当事务执行失败后，需重新执行WATCH命令对变量进行监控，并开启新的事务进行操作。

总结：

watch指令类似于乐观锁，在事务提交时，如果watch监控的多个KEY中任何KEY的值已经被其他客户端更改，则使用EXEC执行事务时，事务队列将不会被执行，同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

lua脚本

版本：自2.6.0起可用。
时间复杂度：取决于执行的脚本。

使用Lua脚本的好处：

1. 减少网络开销。可以将多个请求通过脚本的形式一次发送，减少网络时延。
2. 原子操作。redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。因此在编写脚本的过程中无需担心会出现竞态条件，无需使用事务。
3. 复用。客户端发送的脚本会永久存在redis中，这样，其他客户端可以复用这一脚本而不需要使用代码完成相同的逻辑。

使用参考

持久化

Redis 分别提供了 RDB 和 AOF 两种持久化机制：

1. RDB 将数据库的快照（snapshot）以二进制的方式保存到磁盘中。
2. AOF 则以协议文本的方式，将所有对数据库进行过写入的命令（及其参数）记录到 AOF 文件，以此达到记录数据库状态的目的。

AOF

同步命令到 AOF 文件的整个过程可以分为三个阶段：

1. 命令传播：Redis 将执行完的命令、命令的参数、命令的参数个数等信息发送到 AOF 程序中。
2. 缓存追加：AOF 程序根据接收到的命令数据，将命令转换为网络通讯协议的格式，然后将协议内容追加到服务器的 AOF 缓存中。
3. 文件写入和保存：AOF 缓存中的内容被写入到 AOF 文件末尾，如果设定的 AOF 保存条件被满足的话， fsync 函数或者 fdatasync 函数会被调用，将写入的内容真正地保存到磁盘中。

AOF 保存模式

Redis 目前支持三种 AOF 保存模式，它们分别是：

1. AOF_FSYNC_NO ：不保存。
2. AOF_FSYNC_EVERYSEC ：每一秒钟保存一次。
3. AOF_FSYNC_ALWAYS ：每执行一个命令保存一次

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ivxE8MHz-1578291944048)(https://redisbook.readthedocs.io/en/latest/_images/graphviz-1b226a6d0f09ed1b61a30d899372834634b96504.svg)]

AOF 保存模式对性能和安全性的影响

在上一个小节， 我们简短地描述了三种 AOF 保存模式的工作方式， 现在， 是时候研究一下这三个模式在安全性和性能方面的区别了。

对于三种 AOF 保存模式， 它们对服务器主进程的阻塞情况如下：

1. 不保存（AOF_FSYNC_NO）：写入和保存都由主进程执行，两个操作都会阻塞主进程。
2. 每一秒钟保存一次（AOF_FSYNC_EVERYSEC）：写入操作由主进程执行，阻塞主进程。保存操作由子线程执行，不直接阻塞主进程，但保存操作完成的快慢会影响写入操作的阻塞时长。
3. 每执行一个命令保存一次（AOF_FSYNC_ALWAYS）：和模式 1 一样。

因为阻塞操作会让 Redis 主进程无法持续处理请求， 所以一般说来， 阻塞操作执行得越少、完成得越快， Redis 的性能就越好。

模式 1 的保存操作只会在AOF 关闭或 Redis 关闭时执行， 或者由操作系统触发， 在一般情况下， 这种模式只需要为写入阻塞， 因此它的写入性能要比后面两种模式要高， 当然， 这种性能的提高是以降低安全性为代价的： 在这种模式下， 如果运行的中途发生停机， 那么丢失数据的数量由操作系统的缓存冲洗策略决定。

模式 2 在性能方面要优于模式 3 ， 并且在通常情况下， 这种模式最多丢失不多于 2 秒的数据， 所以它的安全性要高于模式 1 ， 这是一种兼顾性能和安全性的保存方案。

模式 3 的安全性是最高的， 但性能也是最差的， 因为服务器必须阻塞直到命令信息被写入并保存到磁盘之后， 才能继续处理请求。

综合起来，三种 AOF 模式的操作特性可以总结如下：

模式	WRITE 是否阻塞？	SAVE 是否阻塞？	停机时丢失的数据量
AOF_FSYNC_NO	阻塞	阻塞	操作系统最后一次对 AOF 文件触发 SAVE 操作之后的数据。
AOF_FSYNC_EVERYSEC	阻塞	不阻塞	一般情况下不超过 2 秒钟的数据。
AOF_FSYNC_ALWAYS	阻塞	阻塞	最多只丢失一个命令的数据。

AOF 重写

优化指令，有些被频繁操作的键， 对它们所调用的命令可能有成百上千、甚至上万条， 如果这样被频繁操作的键有很多的话， AOF 文件的体积就会急速膨胀， 对 Redis 、甚至整个系统的造成影响

为了解决以上的问题， Redis 需要对 AOF 文件进行重写（rewrite）： 创建一个新的 AOF 文件来代替原有的 AOF 文件， 新 AOF 文件和原有 AOF 文件保存的数据库状态完全一样， 但新 AOF 文件的体积小于等于原有 AOF 文件的体积。

AOF 后台重写

上一节展示的 AOF 重写程序可以很好地完成创建一个新 AOF 文件的任务， 但是， 在执行这个程序的时候， 调用者线程会被阻塞。

很明显， 作为一种辅佐性的维护手段， Redis 不希望 AOF 重写造成服务器无法处理请求， 所以 Redis 决定将 AOF 重写程序放到（后台）子进程里执行， 这样处理的最大好处是：

• 子进程进行 AOF 重写期间，主进程可以继续处理命令请求。
• 子进程带有主进程的数据副本，使用子进程而不是线程，可以在避免锁的情况下，保证数据的安全性。

不过， 使用子进程也有一个问题需要解决： 因为子进程在进行 AOF 重写期间， 主进程还需要继续处理命令， 而新的命令可能对现有的数据进行修改， 这会让当前数据库的数据和重写后的 AOF 文件中的数据不一致。

为了解决这个问题， Redis 增加了一个 AOF 重写缓存， 这个缓存在 fork 出子进程之后开始启用， Redis 主进程在接到新的写命令之后， 除了会将这个写命令的协议内容追加到现有的 AOF 文件之外， 还会追加到这个缓存中：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nhYGlxhP-1578291944051)(https://redisbook.readthedocs.io/en/latest/_images/graphviz-982033b83f571a133367a8830ee5cca84f6a08e5.svg)]

换言之， 当子进程在执行 AOF 重写时， 主进程需要执行以下三个工作：

• 处理命令请求。
• 将写命令追加到现有的 AOF 文件中。
• 将写命令追加到 AOF 重写缓存中。

这样一来可以保证：

1. 现有的 AOF 功能会继续执行，即使在 AOF 重写期间发生停机，也不会有任何数据丢失。
2. 所有对数据库进行修改的命令都会被记录到 AOF 重写缓存中。

当子进程完成 AOF 重写之后， 它会向父进程发送一个完成信号， 父进程在接到完成信号之后， 会调用一个信号处理函数， 并完成以下工作：

1. 将 AOF 重写缓存中的内容全部写入到新 AOF 文件中。
2. 对新的 AOF 文件进行改名，覆盖原有的 AOF 文件。

当步骤 1 执行完毕之后， 现有 AOF 文件、新 AOF 文件和数据库三者的状态就完全一致了。

当步骤 2 执行完毕之后， 程序就完成了新旧两个 AOF 文件的交替。

这个信号处理函数执行完毕之后， 主进程就可以继续像往常一样接受命令请求了。 在整个 AOF 后台重写过程中， 只有最后的写入缓存和改名操作会造成主进程阻塞， 在其他时候， AOF 后台重写都不会对主进程造成阻塞， 这将 AOF 重写对性能造成的影响降到了最低。

以上就是 AOF 后台重写， 也即是 BGREWRITEAOF 命令的工作原理。

AOF 后台重写的触发条件

AOF 重写可以由用户通过调用 BGREWRITEAOF 手动触发。

另外， 服务器在 AOF 功能开启的情况下， 会维持以下三个变量：

• 记录当前 AOF 文件大小的变量 aof_current_size 。
• 记录最后一次 AOF 重写之后， AOF 文件大小的变量 aof_rewrite_base_size 。
• 增长百分比变量 aof_rewrite_perc 。

每次当 serverCron 函数执行时， 它都会检查以下条件是否全部满足， 如果是的话， 就会触发自动的 AOF 重写：

• 没有 BGSAVE 命令在进行。
• 没有 BGREWRITEAOF 在进行。
• 当前 AOF 文件大小大于 server.aof_rewrite_min_size （默认值为 1 MB）。
• 当前 AOF 文件大小和最后一次 AOF 重写后的大小之间的比率大于等于指定的增长百分比。

默认情况下， 增长百分比为 100% ， 也即是说， 如果前面三个条件都已经满足， 并且当前 AOF 文件大小比最后一次 AOF 重写时的大小要大一倍的话， 那么触发自动 AOF 重写。

小结

• AOF 文件通过保存所有修改数据库的命令来记录数据库的状态。
• AOF 文件中的所有命令都以 Redis 通讯协议的格式保存。
• 不同的 AOF 保存模式对数据的安全性、以及 Redis 的性能有很大的影响。
• AOF 重写的目的是用更小的体积来保存数据库状态，整个重写过程基本上不影响 Redis 主进程处理命令请求。
• AOF 重写是一个有歧义的名字，实际的重写工作是针对数据库的当前值来进行的**，程序既不读写、也不使用原有的 AOF 文件**。
• AOF 可以由用户手动触发，也可以由服务器自动触发

RDB

RDB是Redis用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里。

RDB触发方式

自动触发

1、save：这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave（这个命令下面会介绍，手动触发RDB持久化的命令）
　
默认如下配置：

save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存

当然如果你只是用Redis的缓存功能，不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。可以直接一个空字符串来实现停用：save “”

2、stop-writes-on-bgsave-error ：默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了

3、rdbcompression ；默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。

4、rdbchecksum ：默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

5、dbfilename ：设置快照的文件名，默认是 dump.rdb

6、dir：设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。默认是和当前配置文件保存在同一目录。

也就是说通过在配置文件中配置的 save 方式，当实际操作满足该配置形式时就会进行 RDB 持久化，将当前的内存快照保存在 dir 配置的目录中，文件名由配置的 dbfilename 决定。

手动触发

手动触发Redis进行RDB持久化的命令有两种：

1、save

该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。

显然该命令对于内存比较大的实例会造成长时间阻塞，这是致命的缺陷，为了解决此问题，Redis提供了第二种方式。

2、bgsave

执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。

基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。

ps:执行执行 flushall 命令，也会产生dump.rdb文件，但里面是空的，无意义

RDB 的优势和劣势

优势

1.RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。

2.生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

3.RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

劣势

1、RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高(影响性能)

2、RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)

3、在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改(数据有丢失)

管道

Pipeline指的是管道技术，指的是客户端允许将多个请求依次发给服务器，过程中而不需要等待请求的回复，在最后再一并读取结果即可。
管道技术使用广泛，例如许多POP3协议已经实现支持这个功能，大大加快了从服务器下载新邮件的过程。
Redis很早就支持管道（pipeline）技术

注意事项

• pipeline机制可以优化吞吐量，但无法提供原子性/事务保障，而这个可以通过Redis-Multi等命令实现。
• 部分读写操作存在相关依赖，无法使用pipeline实现，可利用Script机制，但需要在可维护性方面做好取舍。

高可用

redis有三种集群方式：主从复制，哨兵模式和集群。

复制

主从复制原理：

• 从服务器连接主服务器，发送SYNC命令；
• 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
• 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
• 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
• 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
• 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；（从服务器初始化完成）
• 主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令（从服务器初始化完成后的操作）

主从复制优缺点：

优点：

• 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离
• 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成
• Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。
• Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。
• Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据

缺点：

• Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
• 主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
• Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

集群

redis的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。

Redis-Cluster采用无中心结构,它的特点如下：

• 所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
• 节点的fail是通过集群中超过半数的节点检测失效时才生效。
• 客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

工作方式：

在redis的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的key到达的时候，redis会根据crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

哨兵

当主服务器中断服务后，可以将一个从服务器升级为主服务器，以便继续提供服务，但是这个过程需要人工手动来操作。 为此，Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能。

哨兵的作用就是监控Redis系统的运行状况。它的功能包括以下两个。

• （1）监控主服务器和从服务器是否正常运行。
• （2）主服务器出现故障时自动将从服务器转换为主服务器。

哨兵的工作方式：

• 每个Sentinel（哨兵）进程以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他Sentinel（哨兵）进程发送一个 PING 命令。
• 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel（哨兵）进程标记为主观下线（SDOWN）
• 如果一个Master主服务器被标记为主观下线（SDOWN），则正在监视这个Master主服务器的所有 Sentinel（哨兵）进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态
• 当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）
• 在一般情况下， 每个 Sentinel（哨兵）进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。
• 当Master主服务器被 Sentinel（哨兵）进程标记为客观下线（ODOWN）时，Sentinel（哨兵）进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
• 若没有足够数量的 Sentinel（哨兵）进程同意 Master主服务器下线， Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel（哨兵）进程发送 PING 命令返回有效回复，Master主服务器的主观下线状态就会被移除。

哨兵模式的优缺点

优点：

• 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。
• 主从可以自动切换，系统更健壮，可用性更高。

缺点：

• Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

数据淘汰机制

Redis内存淘汰机制

Redis内存淘汰机制是指当内存使用达到上限（可通过maxmemory配置，0为不限制，即服务器内存上限），根据一定的算法来决定淘汰掉哪些数据，以保证新数据的存入。

常见的内存淘汰机制分为四大类：

1. LRU：LRU是Least recently used，最近最少使用的意思，简单的理解就是从数据库中删除最近最少访问的数据，该算法认为，你长期不用的数据，那么被再次访问的概率也就很小了，淘汰的数据为最长时间没有被使用，仅与时间相关。
2. LFU：LFU是Least Frequently Used，最不经常使用的意思，简单的理解就是淘汰一段时间内，使用次数最少的数据，这个与频次和时间相关。
3. TTL：Redis中，有的数据是设置了过期时间的，而设置了过期时间的这部分数据，就是该算法要解决的对象。如果你快过期了，不好意思，我内存现在不够了，反正你也要退休了，提前送你一程，把你干掉吧。
4. 随机淘汰：生死有命，富贵在天，是否被干掉，全凭天意了。

通过maxmemroy-policy可以配置具体的淘汰机制，看了网上很多文章说只有6种，其实有8种，可以看Redis5.0的配置文件，上面有说明：

1. volatile-lru -> 找出已经设置过期时间的数据集，将最近最少使用（被访问到）的数据干掉。
2. volatile-ttl -> 找出已经设置过期时间的数据集，将即将过期的数据干掉。
3. volatile-random -> 找出已经设置过期时间的数据集，进行无差别攻击，随机干掉数据。
4. volatile-lfu -> 找出已经设置过期时间的数据集，将一段时间内，使用次数最少的数据干掉。
5. allkeys-lru ->与第1个差不多，数据集从设置过期时间数据变为全体数据。
6. allkeys-lfu -> 与第4个差不多，数据集从设置过期时间数据变为全体数据。
7. allkeys-random -> 与第3个差不多，数据集从设置过期时间数据变为全体数据。
8. no-enviction -> 什么都不干，报错，告诉你内存不足，这样的好处是可以保证数据不丢失，这也是系统默认的淘汰策略。

Redis过期Key清除策略

Redis中大家会对存入的数据设置过期时间，那么这些数据如果过期了，Redis是怎么样把他们消灭掉的呢？我们一起来探讨一下。下面介绍三种清除策略：

惰性删除：当访问Key时，才去判断它是否过期，如果过期，直接干掉。这种方式对CPU很友好，但是一个key如果长期不用，一直存在内存里，会造成内存浪费。

定时删除：设置键的过期时间的同时，创建一个定时器，当到达过期时间点，立即执行对Key的删除操作，这种方式最不友好。

定期删除：隔一段时间，对数据进行一次检查，删除里面的过期Key，至于要删除多少过期Key，检查多少数据，则由算法决定。举个例子方便大家理解：Redis每秒随机取100个数据进行过期检查，删除检查数据中所有已经过期的Key，如果过期的Key占比大于总数的25%，也就是超过25个，再重复上述检查操作。

Redis服务器实际使用的是惰性删除和定期删除两种策略：通过配合使用这两种删除策略，可以很好地在合理使用CPU和避免浪费内存之间取得平衡。

---

本文属于整理内容