redis是一个内存数据库，数据保存在内存中，内存的数据变容易发生丢失。需要将内存中的数据存储到磁盘上。
Redis提供了持久化的机制，分别是RDB(Redis DataBase)和AOF(Append Only File)
Redis启动前准备
新建redis配置文件
cat redis.conf | grep -v "#" | grep -v "^$" >redis-6379.conf #过滤配置文件中的注释和空白和新建文件，并将过滤后内容放入新建的文件中
修改配置文件
port 6379 #端口号 daemonize yes #以守护进行方式启动，命令窗口不会出现日志信息 logfile "log_6379.log" #日志文件名 dir ./data #服务文件保存目录，包含日志文件、持久化文件
开启Redis
redis-server redis-config/redis-6379.conf #开启Redis服务 redis-cli -p 6379 #开启Redis客户端
RDB
数据以快照的形式保存在磁盘上。什么是快照，当前时刻中的数据拍成一张照片。
将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。
如何触发快照？？RDB有三种方式：save命令、bgsave命令、自动触发
save命令
#查看data目录 [root@localhost data]# ls log_6319.log
[root@localhost bin]# redis-cli -p 6379 #客户端设置数据 127.0.0.1:6379> set age 18 OK
#查看data目录，没有持久化数据
[root@localhost data]# ls log_6319.log
#执行save
[root@localhost bin]# redis-cli -p 6379 127.0.0.1:6379> save OK
#数据持久化
[root@localhost data]# ls dump.rdb log_6319.log
注意：
1、Save命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令。
2、如果已经存在RDB文件，就需要替换成新的文件。客户端可能都是几万或者是几十万，
这种方式显然不可取
bgsave命令
Redis会在后台异步进行快照操作，不会阻塞当前Redis服务器
具体操作：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。基本上 Redis 内部所有的RDB操作都是采用 bgsave 命令。
127.0.0.1:6379> set addr suzhou OK 127.0.0.1:6379> bgsave Background saving started
#执行前后
[root@localhost data]# ll 总用量 8 -rw-r--r--. 1 root root 104 9月 17 10:48 dump.rdb -rw-r--r--. 1 root root 2891 9月 17 10:48 log_6319.log
#执行后 [root@localhost data]# ll 总用量 8 -rw-r--r--. 1 root root 117 9月 17 11:21 dump.rdb -rw-r--r--. 1 root root 3166 9月 17 11:21 log_6319.log
持久化文件变大了。
自动触发
自动触发是由我们的配置文件来完成的，本质通过设置配置文件save来自动触发bgsave
在redis.conf配置文件中，里面有如下配置
port 6379 daemonize yes logfile "log_6379.log" dir ./data #save m n。表示m秒内数据集（Key）存在n次修改时，自动触发bgsave save 900 1 save 300 10 #存储过程中，出现错误，停止存储操作 stop-writes-on-bgsave-error yes #设置压缩存储 rdbcompression yes #使用CRC64算法来进行数据校验 rdbchecksum yes #设置快照的文件名 dbfilename "dump-6379.rdb"
测i是60秒内修改两次key（可以对同一个key修改两次）
save 60 2 #重启Redis [root@localhost data]# ps -ef | grep redis root 4945 1 0 11:04 ? 00:00:36 redis-server *:6379 root 5418 5387 0 14:12 pts/5 00:00:00 redis-cli -p 6379 root 5936 5900 0 16:03 pts/2 00:00:00 grep --color=auto redis [root@localhost data]# kill -s 9 4945
60秒内
127.0.0.1:6379> set key1 value3 OK 127.0.0.1:6379> set key1 value4 OK
查看RDB生成成功
[root@localhost data]# ll 总用量 8 -rw-r--r--. 1 root root 110 9月 17 16:06 dump-6379.rdb -rw-r--r--. 1 root root 1417 9月 17 16:06 log_6379.log
RDB 的优势和劣势
优势
- RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复
- 生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快
劣势
可能丢失数据
AOF
将Redis写命令存储到磁盘
AOF开启配置
#开启AOF appendonly yes #设置触发AOF持久化机制 appendfsync always #设置持久化文件名 appendfilename "appendonly-6379.aof"
AOF触发机制
- always（每次）：每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
- everysec（每秒）：异步操作，每秒记录 如果一秒内宕机，有数据丢失
- no（系统控制）：由系统控制每次同步到AOF文件的周期，整体过程不可控
AOF持久化文件重写
AOF持久化的文件会变的越来越大。为了压缩aof的持久化文件，redis提供了bgrewriteaof命令。
将内存中的数据以命令的方式保存到临时文件中，同时会fork出一条新进程来将文件重写，
重写aof文件的操作：将整个内存中的数据库内容用命令的方式重写了一个新的aof文件
重写方式
- 手动重写
- 自动重写
非重写
127.0.0.1:6379> set name zhangsan OK 127.0.0.1:6379> set name lisi OK 127.0.0.1:6379> set name wangwu OK 127.0.0.1:6379> INCR num (integer) 1 127.0.0.1:6379> INCR num (integer) 2 127.0.0.1:6379> INCR num (integer) 3
查看持久化文件
[root@localhost data]# ll 总用量 12 -rw-r--r--. 1 root root 197 9月 18 13:24 appendonly-6379.aof
手动重写
127.0.0.1:6379> bgrewriteaof Background append only file rewriting started
查看持久化文件
[root@localhost data]# ll 总用量 12 -rw-r--r--. 1 root root 117 9月 18 13:29 appendonly-6379.aof
AOF自动重写
自动重写触发条件设置两种方式
- 根据大小触发重写
- 根据百分比触发重写
1）auto-aof-rewrite-min-size size #当前aof缓冲区中的内容大小超过设置的值就会触发重写，
条件表达式：aof_current_size > auto-aof-rewrite-min-size
2）auto-aof-rewrite-percentage percent #当前aof缓冲区中的内容达到的百分比就会触发重写，
条件表达式：
(aof_current_size - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage
通过指令info Persistence获取具体信息
aof_current_size #当前aof缓冲区中的内容大小
aof_base_size #默认基数