Redis 持久化（10）
持久化机制
Redis速度快，很大一部分原因是因为它所有的数据都存储在内存中。如果断电或者宕机，都会导致内存中的数据丢失。为了实现重启后数据不丢失，Redis提供了两种持久化的方案，一种是RDB快照（RedisDataBase），一种是AOF（AppendOnlyFile）。
RDB
RDB是Redis默认的持久化方案。当满足一定条件的时候，会把当前内存中的数据写入磁盘，生成一个快照文件dump.rdb。Redis重启会通过加载dump.rdb文件恢复数据。
什么时候写入rdb文件？
1、自动触发
a）配置规则触发。redis.conf，SNAPSHOTTING，其中定义了触发把数据保存到磁盘的触发频率。如果不需要RDB方案，注释save或者配置成空字符串""。
save 900 1 // 900秒内至少有一个key被修改（包括添加）
save 300 10 //400秒内至少有10个key被修改
save 60 10000 //60秒内至少有10000个key被修改注意上面的配置是不冲突的，只要满足任意一个都会触发。
RDB文件位置和目录：
#文件路径
dir./
#文件名称
dbfilename dump.rdb
#是否是LZF压缩rdb文件
rdbcompression yes
#开启数据校验
rdbchecksum yes为什么停止Redis服务的时候没有save，重启数据还在？
RDB还有两种触发方式：
b）shutdown触发，保证服务器正常关闭。
c）flushall，RDB文件是空的，没什么意义（删掉dump.rdb演示一下）。
2、手动触发
如果我们需要重启服务或者迁移数据，这个时候就需要手动触RDB快照保存。Redis提供了两条命令：
命令 | 说明 |
|---|---|
save | save在生成快照的时候会阻塞当前Redis服务器，Redis不能处理其他命令。如果内存中的数据比较多，会造成Redis长时间的阻塞。生产环境不建议使用这个命令。 |
bgsave | 执行bgsave时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。 |
具体操作是Redis进程执行fork操作创建子进程（copy-on-write），RDB持久化过程由子进程负责，完成后自动结束。它不会记录fork之后后续的命令。阻塞只发生在fork阶段，一般时间很短。
用lastsave命令可以查看最近一次成功生成快照的时间。
RDB总结：
优势 | 劣势 |
|---|---|
RDB是一个非常紧凑(compact)的文件，它保存了redis在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。 | RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，频繁执行成本过高。 |
生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。 | 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照之后的所有修改（数据有丢失）。 |
RDB在恢复大数据集时的速度比AOF的恢复速度要快。 |
AOF(Append Only File)
Redis默认不开启。AOF采用日志的形式来记录每个写操作，并追加到文件中。开启后，执行更改Redis数据的命令时，就会把命令写入到AOF文件中。
Redis重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。
AOF配置
#开关
appendonly no
#文件名(位置也是通过dir参数配置)
appendfilename "appendonly.aof"数据都是实时持久化到磁盘吗？
由于操作系统的缓存机制，AOF数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。什么时候把缓冲区的内容写入到AOF文件？
#appendfsync everysec参数 | 说明 |
|---|---|
no | 表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全； |
always | 表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低； |
everysec | 表示每秒执行一次fsync，可能会导致丢失这1s数据。通常选择everysec，兼顾安全性和效率。 |
文件越来越大，怎么办？
由于AOF持久化是Redis不断将写命令记录到AOF文件中，随着Redis不断的进行，AOF的文件会越来越大，文件越大，占用服务器内存越大以及AOF恢复要求时间越长。
例如set s1 1000，执行1000次，结果都是s1=1000。
为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
可以使用命令bgrewriteaof来重写。
AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。
#重写触发机制
# 默认值为100。aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，
# 即当aof文件增长到一定大小的时候，Redis能够调用bgrewriteaof对日志文件进行重写。
# 当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
# 默认64M。设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。
auto-aof-rewrite-min-size 64mb重写过程中，AOF文件被更改了怎么办？
参数 | 说明 |
|---|---|
no-appendfsync-on-rewrite | 在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议修改为yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。 |
aof-load-truncated | aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项，出现这种现象。redis宕机或者异常终止不会造成尾部不完整现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。默认值为yes。 |
AOF数据恢复
重启Redis之后就会进行AOF文件的恢复。
优点 | 缺点 |
|---|---|
AOF持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis最多也就丢失1秒的数据而已。 | 对于具有相同数据的的Redis，AOF文件通常会比RDF文件体积更大（RDB存的是数据快照）(AOF存储的是命令)。 |
虽然AOF提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。在高并发的情况下，RDB比AOF具好更好的性能保证。 |
在实际生产环境，不建议只使用一种存储方式，建议两种同时使用。当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。