redis的知识总结

君莫笑_0808

已于 2023-09-21 09:33:46 修改

阅读量293

点赞数

文章标签： redis 数据库缓存

于 2020-04-13 14:17:51 首次发布

本文链接：https://blog.csdn.net/qq_16803227/article/details/105487783

版权

一、数据类型:

“Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。”

redis的数据结构

1.1 字符串(SDS simple dynamic string)简单动态字符串

String类型的编码方式，即encoding有三种：int、embstr、raw。
value的值是整数，encoding为int，没有对应底层数据结构；
value长度小于32，encoding为embstr，长度大于，32编码为raw，embstr和raw都使用SDS数据结构存储。

struct sdshdr{
//记录buf数组中已使用字节的数量
//等于 SDS 保存字符串的长度
int len;
//记录 buf 数组中未使用字节的数量
int free;
//字节数组，用于保存字符串
char buf[];
}

好处: 长度直接取出，常数复杂度获取字符串长度，由于 len 属性的存在，我们获取 SDS 字符串的长度只需要读取 len 属性，时间复杂度为 O(1)。空闲区: 杜绝缓冲区溢出

1.2 链表 redis的链表底层实现就是双端链表

typedef struct listNode {
//前置节点
struct listNode *prev;
//后置节点
struct listNode *next;
//节点的值
void *value;
}listNode

Redis链表特性：

双端：链表具有前置节点和后置节点的引用，获取这两个节点时间复杂度都为O(1)。

无环：表头节点的 prev 指针和表尾节点next 指针都指向 NULL,对链表的访问都是以 NULL 结束。

带链表长度计数器：通过 len 属性获取链表长度的时间复杂度为 O(1)。

多态：链表节点使用 void* 指针来保存节点值，可以保存各种不同类型的值。

1.3 Hash

hash底层实现：一种是ziplist，另外一种是hashtable。

1.3.1 zipList：

压缩列表并不是说以某种算法压缩存储数据，它是一组连续的内存块，能够节省空间。

hash对象保存的键和值字符串长度都小于64字节
hash对象保存的键值对数量小于512

一个entry节点包含以下三部分：
previous_entry_ength：记录前一个节点entry的长度，可用于计算前一个节点的起始地址，因为它们的地址是连续的；
encoding：content的内容类型和长度；
content：每个节点的内容。

1.4 set

集合类型使用intset、hashtable这两种底层数据结构存储

如果集合中的所有元素都可以转换成整数值，且长度小于512，使用intset，否则用hashtable。

1.5 zset

ziplist、skiplist+dict这两种底层数据结构存储，

跳跃表， zset的实现普通单链表查询一个元素的时间复杂度为O(n)，即使该单链表是有序的。

ziplist: 当集合长度小于128，并且所有的元素长度都小于64字节时。

typedef struct zskiplistNode {
//层
struct zskiplistLevel{
//前进指针
struct zskiplistNode *forward;
//跨度
unsigned int span;
}level[];
整数集合
整数集合（intset）是集合（set）的底层实现之一，当一个集合（set）只包含整数值元素，并且这个
集合的元素不多时，Redis就会使用整数集合(intset)作为该集合的底层实现。整数集合（intset）是
Redis用于保存整数值的集合抽象数据类型，它可以保存类型为int16_t、int32_t 或者int64_t 的整数
值，并且保证集合中不会出现重复元素。
压缩列表
压缩列表（ziplist）是列表键和哈希键的底层实现之一。当一个列表只包含少量列表项时，并且每个列
表项时小整数值或短字符串，那么Redis会使用压缩列表来做该列表的底层实现。
压缩列表（ziplist）是Redis为了节省内存而开发的，是由一系列特殊编码的连续内存块组成的顺序型数
据结构，一个压缩列表可以包含任意多个节点（entry），每个节点可以保存一个字节数组或者一个整
数值。
放到一个连续内存区
//后退指针
struct zskiplistNode *backward;
//分值
double score;
//成员对象
robj *obj;
} zskiplistNode
--链表
typedef struct zskiplist{
//表头节点和表尾节点
structz skiplistNode *header, *tail;
//表中节点的数量
unsigned long length;
//表中层数最大的节点的层数
int level;
}zskiplist;

1.6 对象

Redis不是用这些数据结构直接实现Redis的键值对数据库，而是基于这些数据结构创建了一个对象系统。包含字符串对象，列表对象，哈希对象，集合对象和有序集合对象。根据对象的类型可以判断一个对象是否可以执行给定的命令，也可针对不同的使用场景，对象设置有多种不同的数据结构实现，从而优化对象在不同场景下的使用效率。

二、redis的持久化: RDB和AOF

Redis 持久化之RDB和AOF

Redis 有两种持久化方案，RDB （Redis DataBase）和 AOF （Append Only File）。如果你想快速了解和使用RDB和AOF，可以直接跳到文章底部看总结。本章节通过配置文件，触发快照的方式，恢复数据的操作，命令操作演示，优缺点来学习 Redis 的重点知识持久化。

RDB 详解

RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。

从配置文件了解RDB

打开 redis.conf 文件，找到 SNAPSHOTTING 对应内容
1 RDB核心规则配置（重点）

save <seconds> <changes>
# save ""
save 900 1
save 300 10
save 60 10000

解说：save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是

15分钟内有1个更改，

5分钟内有10个更改，

1分钟内有10000个更改，则将内存中的数据快照写入磁盘。
若不想用RDB方案，可以把 save "" 的注释打开，下面三个注释。

2 指定本地数据库文件名，一般采用默认的 dump.rdb

dbfilename dump.rdb

3 指定本地数据库存放目录，一般也用默认配置

dir ./

4 默认开启数据压缩

rdbcompression yes

解说：配置存储至本地数据库时是否压缩数据，默认为yes。Redis采用LZF压缩方式，但占用了一点CPU的时间。若关闭该选项，但会导致数据库文件变的巨大。建议开启。

触发RDB快照

1 在指定的时间间隔内，执行指定次数的写操作
2 执行save（阻塞，只管保存快照，其他的等待）或者是bgsave （异步）命令
3 执行flushall 命令，清空数据库所有数据，意义不大。
4 执行shutdown 命令，保证服务器正常关闭且不丢失任何数据，意义...也不大。

通过RDB文件恢复数据

将dump.rdb 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb 。可以从下面的操作演示中可以体会到。

RDB 的优缺点

优点：
1 适合大规模的数据恢复。
2 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。

缺点：
1 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

操作演示

[root@itdragon bin]# vim redis.conf
save 900 1
save 120 5
save 60 10000
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set key1 value1
OK
127.0.0.1:6379> set key2 value2
OK
127.0.0.1:6379> set key3 value3
OK
127.0.0.1:6379> set key4 value4
OK
127.0.0.1:6379> set key5 value5
OK
127.0.0.1:6379> set key6 value6
OK
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# cp dump.rdb dump_bk.rdb
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> FLUSHALL 
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# cp dump_bk.rdb  dump.rdb
cp: overwrite `dump.rdb'? y
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "key5"
2) "key1"
3) "key3"
4) "key4"
5) "key6"
6) "key2"

第一步：vim 修改持久化配置时间，120秒内修改5次则持久化一次。
第二步：重启服务使配置生效。
第三步：分别set 5个key，过两分钟后，在bin的当前目录下会自动生产一个dump.rdb文件。（set key6 是为了验证shutdown有触发RDB快照的作用）
第四步：将当前的dump.rdb 备份一份（模拟线上工作）。
第五步：执行FLUSHALL命令清空数据库数据（模拟数据丢失）。
第六步：重启Redis服务，恢复数据.....咦？？？？( ′◔ ‸◔`)。数据是空的？？？？这是因为FLUSHALL也有触发RDB快照的功能。
第七步：将备份的 dump_bk.rdb 替换 dump.rdb 然后重新Redis。

注意点：SHUTDOWN 和 FLUSHALL 命令都会触发RDB快照，这是一个坑，请大家注意。

其他命令：

keys * 匹配数据库中所有 key
save 阻塞触发RDB快照，使其备份数据
FLUSHALL 清空整个 Redis 服务器的数据(几乎不用)
SHUTDOWN 关机走人（很少用）

AOF 详解

AOF ：Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

从配置文件了解AOF

打开 redis.conf 文件，找到 APPEND ONLY MODE 对应内容
1 redis 默认关闭，开启需要手动把no改为yes

appendonly yes

2 指定本地数据库文件名，默认值为 appendonly.aof

appendfilename "appendonly.aof"

3 指定更新日志条件

# appendfsync always
appendfsync everysec
# appendfsync no

解说：
always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）
everysec：出厂默认推荐，每秒异步记录一次（默认值）
no：不同步

4 配置重写触发机制

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

解说：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。

触发AOF快照

根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。

根据AOF文件恢复数据

正常情况下，将appendonly.aof 文件拷贝到redis的安装目录的bin目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复。从下面的操作演示中体会。

AOF的重写机制

前面也说到了，AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。

重写的原理：Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（你都那么大了，我还去读你？？？ o(ﾟДﾟ)っ傻啊！）。最后替换旧的aof文件。

触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。

AOF 的优缺点

优点：数据的完整性和一致性更高
缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

操作演示

[root@itdragon bin]# vim appendonly.aof
appendonly yes
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> set keyAOf valueAof
OK
127.0.0.1:6379> FLUSHALL 
OK
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "keyAOf"
127.0.0.1:6379> SHUTDOWN
not connected> QUIT
[root@itdragon bin]# vim appendonly.aof
fjewofjwojfoewifjowejfwf
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> QUIT
[root@itdragon bin]# redis-check-aof --fix appendonly.aof 
'x              3e: Expected prefix '*', got: '
AOF analyzed: size=92, ok_up_to=62, diff=30
This will shrink the AOF from 92 bytes, with 30 bytes, to 62 bytes
Continue? [y/N]: y
Successfully truncated AOF
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379> keys *
1) "keyAOf"

第一步：修改配置文件，开启AOF持久化配置。
第二步：重启Redis服务，并进入Redis 自带的客户端中。
第三步：保存值，然后模拟数据丢失，关闭Redis服务。
第四步：重启服务，发现数据恢复了。（额外提一点：有教程显示FLUSHALL 命令会被写入AOF文件中，导致数据恢复失败。我安装的是redis-4.0.2没有遇到这个问题）。
第五步：修改appendonly.aof，模拟文件异常情况。
第六步：重启 Redis 服务失败。这同时也说明了，RDB和AOF可以同时存在，且优先加载AOF文件。
第七步：校验appendonly.aof 文件。重启Redis 服务后正常。

补充点：aof 的校验是通过 redis-check-aof 文件，那么rdb 的校验是不是可以通过 redis-check-rdb 文件呢？？？

总结

Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。
RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。
Redis 针对 AOF文件大的问题，提供重写的瘦身机制。
若只打算用Redis 做缓存，可以关闭持久化。
若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。
解决redis分布式锁过期时间到了业务没执行完问题_分布式锁过期时间问题_new life new dream的博客-CSDN博客 redis分布式锁实现redisson。
https://www.jianshu.com/p/c7c352cb14fe 常见问题