《Redis使用手册之持久化存储》
目录
持久化
为满足不同的持久化需求，Redis提供了RDB持久化、AOF持久化和RDB-AOF混合持久化等多种持久化方式以供用户选择。
如果用户有需要，也可以完全关闭持久化功能，让服务器处于无持久化状态。
RDB持久化
127.0.0.1:6379> save
OK
127.0.0.1:6379> bgsave
Background saving started
RDB持久化是Redis默认使用的持久化功能，该功能可以创建出一个经过压缩的二进制文件，其中包含了服务器在各个数据库中存储的键值对数据等信息。
RDB持久化产生的文件都以.rdb后缀结尾，其中rdb代表Redis DataBase（Redis数据库）。
Redis提供了多种创建RDB文件的方法，用户既可以使用SAVE命令或者BGSAVE命令手动创建RDB文件，也可以通过设置save配置选项让服务器在满足指定条件时自动执行BGSAVE命令。
SAVE:阻塞服务器并创建RDB文件。
BGSAVE:以非阻塞方式创建RDB文件
当Redis服务器接收到用户发送的BGSAVE命令时，将执行以下操作：
1、创建一个子进程。
2、子进程执行SAVE命令，创建新的RDB文件
3、RDB文件创建完毕之后，子进程退出并通知Redis服务器进程(父进程)新RDB文件已经完成。
4、Redis服务器进程使用新RDB文件替换已有的RDB文件。 通过配置选项自己创建RDB文件 save 如果服务器在seconds秒之内，对其包含的各个数据库总共执行了至少changes次修改，那么服务器将自动执行一次BGSAVE命令。
SAVE：阻塞服务器并创建RDB文件
RDB文件总体结构：
RDB文件标识符
版本号
设备附加信息
数据库数据
Lua脚本缓存
EOF
CRC64校验和
单个数据库的信息结构：数据库号码、键值对总数量、带有过期时间的键值对数量、键值对数据部分
单个数据库的信息结构
载入RDB文件
载入RDB文件具体步骤
1、检查文件开头的标识符是否为“REDIS”,如果是则继续执行后续的载入操作，不是则抛出错误并终止载入操作。
2、检查文件的RDB版本号，以此来判断当前Redis服务器能否读取这一版本的RDB文件。
3、根据文件中记录的设备附加信息，执行相应的操作和设置。
4、检查文件的数据库数据部分是否为空，如果不为空就执行以下子操作：
- 根据文件记录的数据库号码，切换至正确的数据库
- 根据文件记录的键值对总数量以及带有过期时间的键值对数量，设置数据库底层数据结构。
- 一个接一个地载入文件记录的所有键值对数据，并在数据库中重建这些键值对。
5、如果服务器启用了复制功能，那么将之前缓存的Lua脚本重新载入缓存中。
6、遇到EOF标识，确认RDB正文已经全部读取完毕。
7、载入RDB文件末尾记录的CRC64校验和，把它与载入数据期间计算出的CRC校验和进行对比，以此判断被载入的数据是否完好无损。 8、RDB文件载入完毕，服务器开始接受客户端请求。
载入RDB文件
RDB文件记录的是服务器在开始创建文件的那一刻，服务器中包含的所有键值对数据，这种数据持久方式通常被称为时间点快照（point-in-time snapshot）。 时间点快照持久化的一个特点是，系统在停机时将丢失最后一次成功实施持久化之后的所有数据。
RDB文件记录的是服务器在开始创建文件的那一刻，服务器中包含的所有键值对数据，这种数据持久化方式通常被称为时间点快照（point-in-time snapshot）。时间点快照持久化的一个特点是，系统在停机时将丢失最后一次成功实施持久化之后的所有数据。
从RDB持久化的特征来看，它更像是一种数据备份手段而非是一种普通的数据持久化手段。
AOF持久化
AOF持久化 与全量式的RDB持久化功能不同，AOF提供的事增量式的持久化功能，这种持久化的核心原理在于：服务器每次执行完写命令之后，都会以协议文本的方式被执行的文件追加到AOF文件的末尾。这样一来，服务器在停机之后，只要重新执行AOF文件中保存的Redis命令，就可以将数据库恢复至停机之前的状态。
打开AOF持久化的功能
appendonly
开启
appendonly yes
关闭
appendonly no
当AOF持久化功能处于打开状态时，Redis服务器在默认情况下降创建一个名为appendonly.aof的文件作为AOF文件。
设置AOF文件的冲洗频率 appendfsync
appendfsync选项拥有always、everysec和no 3个值可选：
always——每执行一个写命令，就对AOF文件执行一次冲洗操作。
everysec——每隔1s，就对AOF文件执行一次冲洗操作。
no——不主动对AOF文件执行冲洗操作，由操作系统觉得何时对AOF进行冲洗。
这3种不同的冲洗策略不仅会直接影响服务器在停机时丢失的数据量，还会影响服务器在运行时的性能：
- 在使用功能always值的情况下，服务器在停机时最多只会丢失一个命令的数据，但使用这种冲洗方式将使Redis服务器的性能降低至传统关系数据库的水平。
- 在使用everysec值的情况下，服务器在停机时最多只会丢失1s之内产生的命令数据，这是一种兼顾性能和安全性的折中方案。
- 在使用no值的情况下，服务器在停机时将丢失系统最后一次冲洗AOF文件之后产生的所有命令数据，至于数据量的大小则取决于系统冲洗AOF文件的频率。 （因为no策略给可能丢失的数据量带来了不确定性，而always策略对于安全性的追求又牺牲了服务器的性能，所以Redis使用everysec作为appendfsync选项的默认值。除非又明确的需求，否则用户不应该随意修改appendfsync选项的值。）
打开AOF持久化功能
AOF重写
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started
用户可以通过执行BGREWRITEAOF命令或者设置相关的配置选项来触发AOF重写操作。
BGREWRITEAOF命令
AOF重写配置选项
auto-aof-rewrite-min-size
auto-aof-rewrite-percentage
其中auto-aof-rewrite-min-size选项用于设置触发自动AOF文件重写所需的最小AOF文件体积，当AOF文件的体积小于给定值时，服务器将不会自动执行BGREWRITEAOF命令。
在默认情况下，该选项的值为： auto-aof-rewrite-min-sieze 64mb 如果AOF文件的体积小于64MB，那么Redis将不会自动执行BGREWRITEAOF命令。 另一个选项，它控制的事触发自动AOF文件重写所需的文件体积增大比例。 auto-aof-rewrite-percentage 100
AOF持久化的优缺点：
因为AOF文件存储的事协议文本，所以它的体积会比包含相同数据、二进制格式的RDB文件要大得多，并且生产AOF文件所需的时间也会比生成RDB文件所需的时间更长。
其次，因为RDB持久化可以直接通过RDB文件恢复数据库数据，而AOF持久化则需要通过执行AOF文件中保存的命令恢复数据库，所以RDB持久化的数据恢复速度将比AOF持久化的数据恢复速度快很多。
最后，因为AOF重写使用功能的BGREWRITEAOF命令与RDB持久化使用的BGSAVE命令一样都需要创建子进程，所以在数据库体积较大的情况下，进行AOF文件重写将占用大量资源，并导致服务器被短暂地阻塞。
用户可以通过执行BGREWRITEAOF命令或者设置相关的配置选项来触发AOF重写操作
RDB-AOF混合持久化
aof-use-rdb-preamble
选项设置成yes。
通过使用RDB-AOF混合持久化功能，用户可以同时获得RDB持久化和AOF持久化的优点：服务器既可以通过AOF文件包含的RDB数据来实现快速的数据恢复操作，又可以通过AOF文件包含的AOF数据来讲丢失数据的时间窗口限制在1s之内。
（需要注意的是Redis目前默认是没有打开RDB-AOF混合持久化功能的）
aof-use-rdb-preamble no
同时使用RDB持久化和AOF持久化注意事项
同时使用两种持久化功能需要耗费大量系统资源，系统的硬件必须能够支撑运行这两种功能所需的资源消耗，否则会给系统性能带来影响。
Redis服务器在启动时，会有限AOF文件进行数据恢复，只有在没有检测到AOF文件时，才会考虑寻找并使用RDB文件进行数据恢复。
当Redis服务器正在后台生成新的RDB文件时，如果有用户向服务端发送BGREWRITEAOF命令，或者配置选项中设置的AOF重写条件被满足了，那么服务器将把AOF重写操作推延到RDB文件创建完毕之后再执行，以此来避免两种持久化操作同时执行并争抢系统资源。
同样，当服务器正在执行BGREWRITEAOF命令时，用户发送或者触发的BGSAVE命令也会推延到BGREWRITEAOF命令执行完毕之后再执行。
