第四章、Redis持久化机制

1、RDB方式[了解]

疑问

问：把服务端关闭了，再重新开启服务器，数据会不会丢失？

会部分丢失，因为默认redis服务器每隔一段时间写入一次内存中数据到硬盘上。

演示如下：

1.向redis数据库中存储数据：

name zhangsan

2.关闭服务器

3.重启服务器

4.使用客户端连接redis服务器，查看结果。

通过上述演示我们发现name-zhangsan数据丢失了，但是之前存储的数据都还在。我们可以得知redis属于内存中存储的数据具有一定危险性，数据容易丢失，但是redis中的数据也可以持久保存，这些和redis持久化是有关联的。

Redis持久化概述

什么是Redis的持久化：

Redis是一个内存存储的数据库，内存必须在通电的情况下才能够对数据进行存储。如果，在使用redis的过程中突然发生断电，数据就会丢失。为了防止数据丢失，redis提供了数据持久化的支持。

持久化：把内存中的数据保存到硬盘上。
作用：防止数据在断电的情况下丢失。

redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化。redis支持两种持久化方式，一种是RDB(快照)也是默认方式，另一种是Append Only File(缩写AOF)的方式。下面分别介绍：

注意：redis将内存中数据，写在硬盘文件上。服务器关闭，电脑重启数据也不会丢失。

Redis持久化的两种方式：

RDB：Redis DataBase 默认的持久化方式，以二进制的方式将数据写入文件中。每隔一段时间写入一次。
AOF：Append Only File 以文本文件的方式记录用户的每次操作，数据还原时候，读取AOF文件，模拟用户的操作，将数据还原。

RDB持久化介绍

RDB是默认的持久化方式。这种方式就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为：dump.rdb。

补充：快照：当前内存中数据的状态。

可以通过配置设置自动做快照持久化的方式。如下面配置的是RDB方式数据持久化时机，必须两个条件都满足的情况下才进行持久化的操作：

关键字	时间(秒)	修改键数	解释
save	900	1	到了15分钟修改了1个键，则发起快照保存
save	300	10	到了5分钟修改了10个键，则发起快照保存
save	60	10000	到了1分钟，修改了1万个键，则发起快照保存

我们发现很难模拟上面的配置方式，所以我们这里要自己对配置文件进行一个修改。就可以演示rdb的持久化效果了。

下面详细介绍快照保存过程：

1.在redis.windows.conf配置文件中有如下说明：

语法	说明
save <时间间隔> <修改键数>	过多久(单位是秒)，修改了多少个键(增删改)

2.修改redis.windows.conf 文件的101行添加1行：save 20 3 (表示20秒内修改3个键，则写入到dump.rdb文件中)

save 900 1
save 300 10
save 60 10000
save 20 3

3.使用指定的配置文件启动服务器：redis-server redis.windows.conf

打开dos窗口，使用命令redis-server加载redis.windows.conf 配置文件。

4.打开客户端，向数据库中增加三个键

set name zhangsan
set age 18
set addr sh

直接关闭服务器窗口。然后打开dos窗口，使用命令redis-server加载redis.windows.conf 配置文件，再开启服务器，查看所有的键：

数据没有丢失。表示关闭redis数据库服务器的时候，数据被写入到数据库dump.rdb文件中了。再次启动redis服务器将dump.rdb文件中的数据加载到redis服务器中。

【RDB持久化机制问题】

不能完全避免数据丢失

因为RDB是每隔一段时间写入数据，所以系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

小结

配置命令：
```
save 时间秒 修改的键
```
启动服务器：
```
redis-server 配置文件
```

2、AOF的存储方式[了解]

目标

了解AOF持久化的配置

AOF持久化简介

由于快照方式是在一定间隔时间做一次的，所以如果redis宕机，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用AOF持久化方式。

AOF指的是Append only file,使用AOF持久化方式时，redis会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof).当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。也可以通过该文件完成数据的重建。该机制可以带来更高的数据安全性，所有的操作都是异步完成的。

Redis中提供了3种同步策略	说明
每秒同步	每过一秒中记录一次
每修改同步	每次修改(增删改)都会记录一次
不同步	不记录任何操作

AOF持久化机制配置

开启AOF持久化

AOF默认是关闭的，首先需要开启AOF模式

参数配置	说明
appendonly no/yes	默认是no，关闭。如果要打开，设置成yes。如果打开的AOF，RDB中存储的数据读取不出来。

AOF持久化时机

关键字	持久化时机	解释
appendfsync	everysec	每秒记录
appendfsync	always	每修改记录
appendfsync	no	不记录

everysec：每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中。

always：收到写命令就立即写入磁盘，最慢，但是保证完全的持久化。

no：完全依赖操作系统，性能最好，持久化无法保证。

演示：AOF的持久化

打开AOF的配置文件redis.windows.conf，找到APPEND ONLY MODE配置块，392行。设置appendonly yes

0. 通过redis-server redis.windows.conf 启动服务器，在服务器目录下出现appendonly.aof文件。大小是0个字节。

0. 添加3个键和值

0. 打开appendonly.aof文件，查看文件的变化。会发现文件记录了所有操作的过程。

说明：

1.*2表示有两个命令 select 0 选择第一个数据库

2.表示有六个字符1 表示0有一个字符

5.再次打开redis服务器，查看结果。redis-server redis.windows.conf 启动服务器

查看上述保存的数据依然存在。

小结

AOF是的格式：文本文件
文件名: appendonly.aof
三种配置策略
1. 每秒记录
2. 每修改记录
3. 不记录

3、AOF重写机制介绍[了解]

1.为什么需要AOF 重写

随着命令不断从AOF缓存中写入到AOF文件中，AOF文件会越来越大，为了解决AOF文件体积膨胀的问题，Redis提供了AOF重写功能：Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多。简单来说redis引入了AOF重写机制就是来压缩AOF文件的。

说明：Incr命令表示将 key 中储存的数字值增一

上述情况演示：

1.使用命令行启动redis服务器

2.在客户端输入如下命令：

按照上述的命令，最后name的结果应该是wangwu,但是按照AOF持久化策略特点，上述输入所有的命令都会被写到持久化文件appendonly.aof中。如下：

这样就会导致appendonly.aof文件中的冗余命令比较多，文件会很大。为了避免这种现象，我们需要使用AOF重写机制来解决。

2.AOF重写触发的方式

2.1手动触发

手动触发：用户通过调用bgrewriteaof命令手动触发。

bgrewriteaof命令：
bg:background 后台
re：repeat 重复
write：写

在客户端直接书写bgrewriteaof命令，如下：

这里我们只关注appendonly.aof文件即可。不用关注旧的文件了。

appendonly.aof文件如下：

2.2自动触发

自动触发：如果全部满足的话，就触发自动的AOF重写操作。

全部满足自动触发的条件：

没有RDB持久化/AOF持久化在执行，没有bgrewriteaof在进行；
当前AOF文件大小要大于redis.windows.conf配置的auto-aof-rewrite-min-size大小；
当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比（在配置文件设置了auto-aof-rewrite-percentage参数，不设置默认为100%）

原来的数据：

【演示：AOF后台自动重写】

关闭服务器，删除生成的aof和rdb文件

修改redis.windows.conf配置文件如下：

# 大于原来的10%就自动重写
auto-aof-rewrite-percentage 10
# 自动重写的最小尺寸
auto-aof-rewrite-min-size 10b

3.带配置文件启动服务器： redis-server redis.windows.conf

4.进行如下操作

5.生成的重写文件

6.服务器端的输出

7.数据库结果

8.生成的appendonly.aof文件内容如下：

3.AOF 文件重写的实现原理

AOF重写并不需要对原有AOF文件进行任何的读取，写入，分析等操作，这个功能是通过读取服务器当前的数据库状态来实现的。

# 假设服务器对键list执行了以下命令
127.0.0.1:6379> RPUSH list "A" "B"
(integer) 2
127.0.0.1:6379> RPUSH list "C"
(integer) 3
127.0.0.1:6379> RPUSH list "D" "E"
(integer) 5
127.0.0.1:6379> LPOP list
"A"
127.0.0.1:6379> LPOP list
"B"
127.0.0.1:6379> RPUSH list "F" "G"
(integer) 5
127.0.0.1:6379> LRANGE list 0 -1
1) "C"
2) "D"
3) "E"
4) "F"
5) "G"
127.0.0.1:6379>

结果

当前列表键list在数据库中的值就为["C","D", "E", "F", "G"]。要使用尽量少的命令来记录list键的状态，最简单的方式不是去读取和分析现有AOF文件的内容，而是直接读取list键在数据库中的当前值，然后用一条RPUSH list "C" "D" "E" "F" "G"代替前面的6条命令。

结论

因为AOF如果记录每一步操作，文件会越来越大，通过AOF的重写，可以缩小AOF文件的尺寸。同样可以达到数据还原效果

4.Redis持久化机制RDB和AOF的区别

1.RDB持久化机制优点和缺点

优点

方便备份与恢复

整个Redis数据库将只包含一个文件，默认是dump.rdb，这对于文件备份和恢复而言是非常完美的。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

启动效率更高

相比于AOF机制，如果数据集很大，RDB的启动效率会更高。因为RDB文件中存储的是数据，启动的时候直接加载数据即可，而AOF是将操作数据库的命令存放到AOF文件中，然后启动redis数据库服务器的时候会将很多个命令执行加载数据。如果数据量特别大的时候，那么RDB由于直接加载数据启动效率会比AOF执行命令加载数据更高。

性能最大化

对于Redis的服务进程而言，在开始持久化时，会在后台开辟子线程，由子线程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

缺点

不能完全避免数据丢失