linux12 - Redis -＞02五种数据结构类型与数据持久化AOF+RDB

文章目录

一、redis数据类型

redis中有很多很丰富的数据类型。

1.列表

redis列表就是redis的字符串类型的集合，按照插入顺序排序

[root@redis01 ~]# redis-cli --raw
127.0.0.1:6379> auth 123

#1.从左边插入数据（后进先出）
127.0.0.1:6379> lpush peopel yyy
(integer) 1
127.0.0.1:6379> lrange peopel 0 -1
1) "yyy"
127.0.0.1:6379> lpush peopel yyy man beijing
(integer) 4
127.0.0.1:6379> lrange peopel 0 -1  #从头部插入
1) "beijing"
2) "man"
3) "yyy"
4) "yyy"

#2.从右边插入数据（先进先出）
127.0.0.1:6379> rpush peopel abc
(integer) 5
127.0.0.1:6379> lrange peopel 0 -1
1) "beijing"
2) "man"
3) "yyy"
4) "yyy"
5) "abc"

#3.查看看数据
127.0.0.1:6379> lrange peopel 0 -1  #从开始到结束
1) "beijing"
2) "man"
3) "yyy"
4) "yyy"
5) "abc"
127.0.0.1:6379> lrange peopel 2 4  #从第二位到第四位
1) "yyy"
2) "yyy"
3) "abc"

#4.从左边追加数据（与sting类型中的nx类似，只有当list存在时才会从左边依次追加元素）
127.0.0.1:6379> lrange peopel 0 -1
1) "beijing"
2) "man"
3) "yyy"
4) "yyy"
5) "abc"
127.0.0.1:6379> lpushx peopel 345  #从头部追加345
(integer) 6
127.0.0.1:6379> lrange peopel 0 -1
1) "345"
2) "beijing"
3) "man"
4) "yyy"
5) "yyy"
6) "abc"

#5.从右边追加数据（只有当list存在时才会从右边依次追加元素）
127.0.0.1:6379> lrange peopel 0 -1
1) "345"
2) "beijing"
3) "man"
4) "yyy"
5) "yyy"
6) "abc"
127.0.0.1:6379> rpushx peopel 123  #从尾部追加123
(integer) 7
127.0.0.1:6379> lrange peopel 0 -1
1) "345"
2) "beijing"
3) "man"
4) "yyy"
5) "yyy"
6) "abc"
7) "123"

#6.在某个key的前面或者后面追加一个数据
127.0.0.1:6379> lrange peopel 0 -1
1) "345"
2) "beijing"
3) "man"
4) "yyy"
5) "yyy"
6) "abc"
7) "123"
127.0.0.1:6379> linsert peopel before beijing 111  #在北京的前边添加111
(integer) 8
127.0.0.1:6379> lrange peopel 0 -1
1) "345"
2) "111"
3) "beijing"
4) "man"
5) "yyy"
6) "yyy"
7) "abc"
8) "123"

#7.指定删除多少个values（从列表左侧开始移除）
127.0.0.1:6379> lrange peopel 0 -1
123
beijing
shanghai
man
yyy
127.0.0.1:6379> lrem peopel 1 123  #从列表左侧开始删除1个123
(integer) 1
127.0.0.1:6379> lrange peopel 0 -1
beijing
shanghai
man
yyy

#8.修改数据（指定下标修改数据）
127.0.0.1:6379> lrange peopel 0 -1
123
23
man
yyy
127.0.0.1:6379> lset peopel 1 beijing  #指定第1位修改成beijing
OK
127.0.0.1:6379> lrange peopel 0 -1
123
beijing
man
yyy

#9.截取字符串
127.0.0.1:6379> lrange peopel 0 -1
123
beijing
man
yyy
127.0.0.1:6379> ltrim peopel 1 3  #截取从1到3
OK
127.0.0.1:6379> lrange peopel 0 -1
beijing
man
yyy
#10.查看长度
127.0.0.1:6379> llen peopel
3
127.0.0.1:6379> LRANGE peopel 0 -1
beijing
man
yyy

#11.根据下标查询数据
127.0.0.1:6379> lrange peopel 0 -1
1) "man"
2) "yyy"
3) "yyy"
127.0.0.1:6379> lindex peopel 2
"yyy"

#12.从左边开始消费
127.0.0.1:6379> lrange peopel 0 -1
1) "man"
2) "yyy"
3) "yyy"
127.0.0.1:6379> lpop peopel 
"man"
127.0.0.1:6379> lrange peopel 0 -1
1) "yyy"
2) "yyy"

#13.从右边开始消费
127.0.0.1:6379> lrange peopel 0 -1
1) "yyy"
2) "yyy"
127.0.0.1:6379> rpop peopel
"yyy"
127.0.0.1:6379> lrange peopel 0 -1
1) "yyy"

#14.消费一个元素追加另一个列表里 （从尾开始）
127.0.0.1:6379> lrange peopel 0 -1
1) "555"
2) "444"
3) "333"
4) "222"
5) "111"
6) "111"
127.0.0.1:6379> rpoplpush peopel newlist
"111"
127.0.0.1:6379> lrange peopel 0 -1
1) "555"
2) "444"
3) "333"
4) "222"
5) "111"
127.0.0.1:6379> lrange newlist 0 -1
1) "111"

#15.实时获取某一个值
127.0.0.1:6379> blpop peopel 1000
peopel
man
127.0.0.1:6379> blpop peopel 1000

2.无序集合

Redis 的 Set 是 string 类型的无序集合。集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。集合中最大的成员数为 2^32 - 1 (4294967295, 每个集合可存储 40多亿个成员）。

#1.增加数据
127.0.0.1:6379> sadd mysqlset 1
(integer) 0
127.0.0.1:6379> sadd mysqlset 12
(integer) 0

#2.查看数据
127.0.0.1:6379> smembers mysqlset
1) "1"
2) "12"
3) "123"

#3.删除数据
127.0.0.1:6379> smembers mysqlset
1
2
4
127.0.0.1:6379> srem  mysqlset 1
1
127.0.0.1:6379> smembers mysqlset
2
4
#4.移动数据
127.0.0.1:6379> sadd myset qq
1
127.0.0.1:6379> smembers myset
qq
127.0.0.1:6379> smove mysqlset myset 2
1
127.0.0.1:6379> smembers myset
2
qq

#5.返回集合当中的个数
127.0.0.1:6379> smembers myset
1) "qqq"
2) "1234"
127.0.0.1:6379> scard myset
(integer) 2

#6.随机返回两个数据
127.0.0.1:6379> srandmember mysqlset 2
1) "12345"
2) "1"

#7.判断一个数据是否存在一个集合中
127.0.0.1:6379> sismember mysqlset abc
(integer) 0  #不存在返回0
127.0.0.1:6379> sismember mysqlset 12
(integer) 1  #存在返回1

#8.随机消费一个成员并从集合中删除该成员
127.0.0.1:6379> smembers mysqlset
1) "1"
2) "12"
3) "12345"
127.0.0.1:6379> spop mysqlset 1
1) "12"
127.0.0.1:6379> smembers mysqlset
1) "1"
2) "12345"

#9.返回多个集合中的交集
127.0.0.1:6379> sadd myseta 1 2 3 4 5
(integer) 5
127.0.0.1:6379> sadd mysetb 1 2 3 7 8 9
(integer) 6
127.0.0.1:6379> sinter myseta mysetb mysetc
1) "1"
2) "2"
3) "3"

#10.返回多个集合的并集
127.0.0.1:6379> sadd myseta 1 2 3 4 5
(integer) 5
127.0.0.1:6379> sadd mysetc 1 2 3 4 5 6 7 8
(integer) 8
127.0.0.1:6379> sunion myseta mysetb mysetc
1) "1"
2) "2"
3) "3"
4) "4"
5) "5"
6) "6"
7) "7"
8) "8"

#11.返回多个集合的差集
127.0.0.1:6379> sadd myseta 1 2 3 4 5
(integer) 5
127.0.0.1:6379> sadd mysetb 1 2 3 7 8 9
(integer) 6
127.0.0.1:6379> sadd mysetc 1 2 3 4 5 6 7 8
(integer) 8
127.0.0.1:6379> sdiff mysetc mysetb myseta
1) "6"

3.有序集合

Redis 有序集合和集合一样也是 string 类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个 double 类型的分数。redis 正是通过分数来为集合中的成员进行从小到大的排序。有序集合的成员是唯一的, 但分数(score)却可以重复。集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。集合中最大的成员数为 2^32 - 1 (4294967295, 每个集合可存储 40多亿个成员）。

#1.添加数据
127.0.0.1:6379> zadd nn 1 one
1
127.0.0.1:6379> zadd nn 2 two
1
127.0.0.1:6379> zadd nn 123 tree
1
#2.查看数据
127.0.0.1:6379> zrange nn 0 -1
one
two
tree

#3.删除数据
127.0.0.1:6379> zrange nn 0 -1
one
two
tree
127.0.0.1:6379> zrem nn one
1
127.0.0.1:6379> zrange nn 0 -1
two
tree

二、Redis常用命令

1.查看所有key

127.0.0.1:6379> keys *
myseta
mysqlset
myset
mysetc
nn
num
name

2.查看key的类型

127.0.0.1:6379> type nn
zset  #有序集合
127.0.0.1:6379> type name
string  #字符串
127.0.0.1:6379> type peopel
list  #列表

3.随机返回一个key

127.0.0.1:6379> RANDOMKEY
num
127.0.0.1:6379> RANDOMKEY
myset
127.0.0.1:6379> RANDOMKEY
nn

4.删除key

127.0.0.1:6379> del name
(integer) 1  #返回状态0/1，true/false
127.0.0.1:6379> keys *
 1) "newlist"
 2) "myset"
 3) "mysetb"
 4) "myset1"
 5) "peopel"
 6) "myseta"
 7) "people"
 8) "age"
 9) "mysetc"
10) "mysqlset"

5.判断一个key是否存在

127.0.0.1:6379> exists name
(integer) 0  #不存在返回0
127.0.0.1:6379> exists peopel
(integer) 1  #存在返回1

6.重命名一个key

127.0.0.1:6379> rename myset myset0
OK

7.查看key的剩余时间

#1.以秒为单位
127.0.0.1:6379> ttl peopel
(integer) -1  #-1永不过期

#2.以毫秒为单位
127.0.0.1:6379> pttl peopel
(integer) -1  #-1永不过期

三、数据持久化

1.Redis数据安全问题

Redis 是一个缓存中间件，它的最大特点是使用内存从而使其性能强悍。但是使用内存的方 式有一个致命的特点就是数据没办法持久化保存。然而 Redis 持久化存储有两种持久化方案，RDB(Redis DataBase) 和 AOF(Append-Only File)。其中 RDB 是将内存中的数据进行快照存储到磁盘，AOF 则为可回放的命令日志记录 redis 内的所有操作。它们各有特点也相互独立。Redis4 之后支持 RDB-AOF 混合持久化的方式，结合了两者的优 点，可以通过 aof-use-rdb-preamble 配置项可以打开混合开关。

2.快照持久化（RDB）

RDB是将Redis内存中的数据进行snaptshot快照存储在磁盘内存，是Redis的默认持久化方案。使用RDB持久化默认有三种策略，该持久化策略在redis.conf中可配置，会以一段时间内有指定此数据修改的规则触发快照的动作，快照文件名为dump.rdb，该文件默认使用LZF压缩算法。每当Redis服务重启的时候会从该文件中加载数据进内存。

RDB持久化除了可以根据配置文件的策略触发，也可以手动触发,使用save和bgsave命令即可。这两个命令的区别是save会阻塞服务器的进程，在进行save的过程中，服务器不能处理任何请求，而bgsave会通过一个子进程在后台处理rdb持久化。事实上save和bgsave调用的都是sdbsave函数，因此Redis不允许save和bgsave同时运行，这也是为了避免出现竞争导致rdb文件数据不准确。

bgsave操作使用copyonwrite机制进行写时复制，是有一个子进程将内存中的最新数据遍历写入临时文件，此时父进程仍旧处理客户端的操作，当子进程操作完毕后再将该临时文件重命名为dump.rdb替换掉原来的dump.rdb文件，因此无论bgsave是否成功，dump.rdb都不会受到影响。

# 另外在主从全量同步、debug reload以及shutdown的情况下也会触发RDB数据持久化。

[root@redis01 ~]# egrep '^save' /usr/local/redis/conf/redis.conf 
save 900 1
save 300 10
save 60 10000

1、save原理

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9baB2AQ7-1621256853323)(C:\Users\17155\AppData\Roaming\Typora\typora-user-images\1621179389860.png)]$

2、bgsave原理

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EDc21tUg-1621256853325)(C:\Users\17155\AppData\Roaming\Typora\typora-user-images\1621179403064.png)]$

3、快照持久化配置设置

#1.创建持久化文件存储目录
[root@docker ~]# mkdir /usr/local/redis/data

#2.修改持久化文件存储目录
[root@tomcat redis]# vim /usr/local/redis/conf/redis.conf 
dir /usr/local/redis/data

#3.开启数据持久化（RDB触发机制）
[root@docker ~]# vim /usr/local/redis/conf/redis.conf  #默认是开启的
save 900 1     #900秒内至少有1个key被改变则做一次快照
save 300 10    #300秒内至少有10key被改变做一次快照
save 60 10000  #60秒内至少有10000个key被改变则做一次快照

#4.Redis服务在data目录下会生成备份数据文件（dump.rdb）
[root@docker redis]# systemctl start redis
[root@docker redis]# ll
总用量 0
drwxr-xr-x 2 root root 134 4月  30 20:35 bin
drwxr-xr-x 2 root root  24 5月   1 10:36 conf
drwxr-xr-x 2 root root  22 5月   1 10:37 data
[root@docker redis]# cd data/
[root@docker data]# ll
总用量 4
-rw-r--r-- 1 root root 92 5月   1 10:37 dump.rdb

1、配置文件详解

# 1、配置文件详解
save m n
# 2、配置快照(rdb)促发规则，格式：save <seconds> <changes>
save 900 1      900 秒内至少有 1 个 key 被改变则做一次快照
save 300 10     300 秒内至少有 10个 key 被改变则做一次快照
save 60 10000   60 秒内至少有 10000 个 key 被改变则做一次快照
# 3、关闭该规则使用 svae “”
[root@redis01 redis]# egrep 'dump.rdb' /usr/local/redis/conf/redis.conf 
dbfilename dump.rdb
# 4、rdb 持久化存储数据库文件名，默认为 dump.rdb
stop-write-on-bgsave-error yes
# 5、yes 代表当使用 bgsave 命令持久化出错时候停止写 RDB 快照文件,no 表明忽略错误继续写文件。
rdbchecksum yes
# 6、在写入文件和读取文件时是否开启 rdb 文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启
动。
dir "/etc/redis"
# 7、数据文件存放目录，rdb 快照文件和 aof 文件都会存放至该目录，请确保有写权限
rdbcompression yes
# 8、是否开启 RDB 文件压缩，该功能可以节约磁盘空间、

4、RDB的优缺点

# 优点：
RDB是一种表示某个即时点的Redis数据的紧凑文件。RDB文件适合用于备份。例如，你可能想要每小时归档最近24小时的RDB文件，每天保存近30天的RDB快照。这允许你很容易的回复不同版本的数据集以容灾。
RDB非常适合灾难回复，作为一个紧凑的单一文件，可以被传输到远程的数据中心。
RDB最大化了Redis的性能，因为Redis父进程持久化是唯一需要做的启动一个子进程，又子进程完成所有剩余工作。父进程实例不需要执行像磁盘IO这样的操作。
RDB在重启保存了大数据集的实例时比AOF要快
# 缺点：
当你需要在 Redis 停止工作(例如停电)时最小化数据丢失，RDB 可能不太好。你可以配置不同的保存点(save point)来保存 RDB 文件(例如，至少 5 分钟和对数据集 100 次写之后，但是你可以有多个保存点)。然而，你 通常每隔 5 分钟或更久创建一个 RDB 快照，所以一旦 Redis 因为任何原因没有正确关闭而停止工作，你就得 做好最近几分钟数据丢失的准备了。
RDB 需要经常调用 fork()子进程来持久化到磁盘。如果数据集很大的话，fork()比较耗时，结果就是，当数据 集非常大并且 CPU 性能不够强大的话，Redis 会停止服务客户端几毫秒甚至一秒。AOF 也需要 fork()，但是你 可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。

# RDB总结：
# 优点：
速度快，适合用作备份，主从复制也是基于RDB持久化功能实现的
# 致命性缺点：
会有数据丢失、导致服务停止几秒

5、停止备份

在配置文件中设置save“” 或在命令行执行config set save “”

6、手动开始备份

# save：会立即生成 dump.rdb，但是会阻塞往 redis 内存中写入数据。

# bgsave：后台异步备份。

如果是使用 flushdb 命令，会把之前的快照更新成当前的空状态，所以执行了 flushdb 后更新的快照是没有数据的

7、save 与 bgsave 对比

在这里插入图片描述

3.持久化（AOF）

AOF(Append-Only File)记录 Redis 中每次的写命令，类似 mysql 中的 binlog，服务重启时会重新执行 AOF 中的 命令将数据恢复到内存中，RDB(按策略持久化)持久化方式记录的粒度不如 AOF(记录每条写命令)，因此很多生产 环境都是开启 AOF 持久化。AOF 中记录了操作和数据，在日志文件中追加完成后才会将内存中的数据进行变更。
# AOF 类似于数据库的binnlog日志

1、原理

1、客户端的请求写命令会被 append 追加到 AOF 缓冲区内；
2、AOF 缓冲区根据 AOF 持久化策略[always,everysec,no]将操作 sync 同步到磁盘的 AOF 文件中；
3、AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 rewrite 重写，压缩 AOF 文件容量；
4、Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的

2、AOF配置

开启了 AOF 之后，RDB 就默认不使用了。使用下面的配置开启 AOF 以及策略。
(如果使用 AOF，推荐选择 always 方式持久化，否则在高并发场景下，每秒钟会有几万甚至百万条请求，如果使用 everysec 的方式的话，万一服务 器挂了那几万条数据就丢失了)。

[root@redis01 redis]# vim  /usr/local/redis/conf/redis.conf 
# 1、开启 AOF 持久化
appendonly yes
# 2、AOF 文件名
appendfilename "appendonly.aof"
[root@redis01 data]# ll
total 8
-rw-r--r-- 1 root root 97 Jul 19 21:16 appendonly.aof
-rw-r--r-- 1 root root 92 Jul 19 21:16 dump.rdb
# 3、AOF 文件存储路径 与 RDB 是同一个参数
dir "/opt/app/redis6/data"
# 4、AOF策略，一般都是选择第一种[always:每个命令都记录],[everysec:每秒记录一次],[no:看机器的心
情高兴了就记录]
appendfsync always
# appendfsync everysec
# appendfsync no
# 5、AOF文件大小比起上次重写时的大小,增长 100%(配置可以大于 100%)时,触发重写。
[假如上次重写后大小为10MB，当 AOF 文件达到 20MB 时也会再次触发重写，以此类推]
auto-aof-rewrite-percentage 100
# 6、AOF文件大小超过 64MB 时,触发重写
auto-aof-rewrite-min-size 64mb
# 7、是否在后台写时同步单写，默认值 no(表示需要同步).这里的后台写，表示后台正在重写文件(包括 bgsave
和 bgrewriteaof.bgrewriteaof 网上很多资料都没有涉及到。其实关掉 bgsave 之后，主要的即是 aof 重
写文件了).no 表示新的主进程的 set 操作会被阻塞掉，而 yes 表示新的主进程的 set 不会被阻塞，待整个后
台写完成之后再将这部分 set 操作同步到 aof 文件中。但这可能会存在数据丢失的风险(机率很小)，如果对性
能有要求，可以设置为 yes，仅在后台写时会异步处理命令.
no-appendfsync-on-rewrite no
# 8、指 redis 在恢复时，会忽略最后一条可能存在问题的指令。默认值 yes。即在 aof 写入时，可能存在指令写
错的问题(突然断电，写了一半)，这种情况下，yes 会 log 并继续，而 no 会直接恢复失败.
aof-load-truncated

3、AOF持久化策略

#  AOF 分别有三种备份策略，
[always:每个命令都记录],
[everysec:每秒记录一次],
[no:看机器的心情高兴了 就记录]，
针对这三种策略给出如下说明。

4、策略说明

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LRwSLLkt-1621256853329)(C:\Users\17155\AppData\Roaming\Typora\typora-user-images\1621179956149.png)]$

5、策略抉择

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Cj0upSgA-1621256853331)(C:\Users\17155\AppData\Roaming\Typora\typora-user-images\1621179975388.png)]$

6、AOF重写

AOF 持久化机制记录每个写命令，当服务重启的时候会复现 AOF 文件中的所有命令，会消耗太多的资源且 重启很慢。因此为了避免 AOF 文件中的写命令太多文件太大，Redis 引入了 AOF 的重写机制来压缩 AOF 文件体积。 AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新 AOF 文件的过程。

7、AOF重写配置

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OsqZXaEw-1621256853332)(C:\Users\17155\AppData\Roaming\Typora\typora-user-images\1621180027270.png)]$

8、AOF重写触发机制

根据配置，AOF 持久化触发机制如下： 1. aof_current_size > auto-aof-rewrite-min-size 2. (aof_current_size - aof_base_size) / aof_base_size > auto-aof-rewrite-percentage

9、AOF重写流程

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TjxySiDI-1621256853333)(C:\Users\17155\AppData\Roaming\Typora\typora-user-images\1621180094296.png)]$

4.RDB和AOF抉择

1、RDB和AOF比较

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-povPKWtW-1621256853333)(C:\Users\17155\AppData\Roaming\Typora\typora-user-images\1621180253905.png)]$

2、RDB 与 AOF 之间的优劣

# 1、RDB优点：
1、压缩后的二进制文件，适用于备份、全量复制及灾难恢复
2、RDB 恢复数据性能优于 AOF 方式
# 2、RDB 的缺点：
1、无法做到实时持久化，每次都要创建子进程，频繁操作成本过高
2、保存后的二进制文件，不同版本直接存在兼容性问题
# 3、AOF 的优点：
1、以文本形式保存，易读
2、记录写操作保证数据不丢失
# 4、AOF 的缺点：
1、存储所有写操作命令，且文件为文本格式保存，未经压缩，文件体积高。
2、恢复数据时重放 AOF 中所有代码，恢复性能弱于 RDB 方式

5.AOF 与 RDB 混合

看了上面的 RDB 和 AOF 的介绍后，我们可以发现，使用 RDB 持久化会有数据丢失的风险，但是恢复速度快， 而使用 AOF 持久化可以保证数据完整性，但恢复数据的时候会很慢。于是从 Redis4 之后新增了混合 AOF 和 RDB 的模式，先使用 RDB 进行快照存储，然后使用 AOF 持久化记录所有的写操作，当重写策略满足或手动触发重写 的时候，将最新的数据存储为新的 RDB 记录。这样的话，重启服务的时候会从 RDB 何 AOF 两部分恢复数据，即 保证了数据完整性，又提高了恢复的性能。

开启混合模式后，每当 bgrewriteaof 命令之后会在 AOF 文件中以 RDB 格式写入当前最新的数据，之后的新 的写操作继续以 AOF 的追加形式追加写命令。当 redis 重启的时候，加载 aof 文件进行恢复数据：先加载 rdb 的 部分再加载剩余的 aof部分

1、混合配置

修改下面的参数即可开启 AOF，RDB 混合持久化 aof-use-rdb-preamble yes

2、混合模式的使用

开启混合持久化模式后，重写之后的 aof 文件里和 rdb 一样存储二进制的快照数据，继续往 redis 中进行写 操作，后续操作在 aof 中仍然是以命令的方式追加。因此重写后 aof 文件由两部分组成，一部分是类似 rdb 的二 进制快照，另一部分是追加的命令文本。

# step: 进入 Redis， 写入数据
[root@alvin-test-os redis]# redis-cli --raw
127.0.0.1:6379> set name alvin
OK
127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> set add 上海
OK
127.0.0.1:6379> exit
# Step 2: 查看备份文件
[root@alvin-test-os redis]# ll data/
总用量 8
-rw-r--r--. 1 root root 121 11 月 24 15:39 appendonly.aof
-rw-r--r--. 1 root root 116 11 月 24 15:39 dump.rdb
[root@alvin-test-os redis]# cat data/appendonly.aof | grep add
add
[root@alvin-test-os redis]# cat data/appendonly.aof
*2
$6
SELECT
$1
0
# Step 3： 启动备份
[root@alvin-test-os redis]# redis-cli --raw
127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started
127.0.0.1:6379> exit
# Step 4: 查看配置文件发现 AOF 备份文件变成了二进制文件
[root@alvin-test-os redis]# cat data/appendonly.aof
REDIS0009� redis-ver6.0.9�
�edis-bits�@�ctime��_used-mem��4
aof-preamble���namealvinadd 上海 age���6����&[root@alvin-test-os redis]#
# Step 5： 再次写入文件
[root@alvin-test-os redis]# redis-cli --raw
127.0.0.1:6379> set company 上海老男孩
OK
127.0.0.1:6379> exit
# Step 6：再次查看备份文件发现被分成了两份，一份二进制，一份 AOF 备份
[root@alvin-test-os redis]# cat data/appendonly.aof
REDIS0009� redis-ver6.0.9�
�edis-bits�@�ctime��_used-mem��4
aof-preamble���namealvinadd 上海 age���6����&*2
$6
SELECT
$1
0
*3
$3
set
$7
company

posted @ 2021-05-17 21:15 博客之记阅读(32) 评论(0) 编辑收藏举报

刷新页面返回顶部