Redis 是一个基于内存的、可持久化的开源键值对存储数据库。
大家都知道哈，内存中的数据在断电后会丢失。
对于只是把Redis当做缓存来用的项目来说，数据消失或许问题不大，重新把数据加载进来就可以了。
对于把Redis作为数据库来使用的项目来说，数据丢失所造成的影响是毁灭性的。
那有没有什么办法可以解决这个问题？
有，那就是今天要讲的主题《Redis持久化》
什么是Redis持久化？
持久化就是把内存中的数据保存到硬盘中，使数据可以持久化保存。
linux一切皆文件，如有执行
rm -rf *
者，本文皆为空谈。
Redis 提供了RDB和AOF两种不同的数据持久化方式。下面详细介绍一下这两种不同的持久化方式。
RDB
将Redis某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为dump.rdb, 而在Redis服务器启动时，会重新加载dump.rdb 文件的数据到内存中。
开启RDB持久化方式
开启RDB持久化方式很简单，客户端可以通过向Redis服务器发送save或bgsave命令让服务器生成rdb文件，或者通过服务器配置文件指定触发RDB条件。
1、save命令
127.0.0.1:6379> save
OK复制
save命令是一个同步操作。当客户端向服务器发送save命令请求进行持久化时，服务器会阻塞save命令之后的其他客户端的请求，直到数据同步完成。
如果数据量太大，同步数据会执行很久， 这期间Redis服务器也无法接收其他请求。
最好不要在生产环境中使用save命令
2、bgsave
127.0.0.1:6379> bgsave
Background saving started复制
与save命令不同，bgsave命令是一个异步操作。当客户端发出bgsave命令时，Redis服务器主进程会forks一个子进程来数据同步问题，子进程会在数据保存到rdb文件后退出。
与save命令相比，Redis服务器在处理bgsave采用子线程进行IO写入，而主进程仍然可以接收其他请求，但forks子进程是同步的，所以forks子进程时，一样不能接收其他请求。如果forks一个子进程花费的时间太久(一般是很快的)，bgsave命令仍然有阻塞其他客户的请求的情况发生。
3、服务器配置自动触发
通过Redis配置文件中的save指定触发RDB持久化的条件。配置项如下：
# save 3600 1 # 3600s内至少达到一条写命令
# save 300 100 # 300s内至少达到100条写命令
# save 60 10000 # 60s内至少达到10000条写命令复制
通过配置文件触发持久化的方式与bgsave命令类似，达到触发条件时会forks一个子进程进行数据保存。
最好不要通过这种方式。因为设置触发的时间太短，则容易频繁写入rdb文件，影响服务器性能，时间设置太长则会造成数据丢失。
rbd文件
前面三种生成rdb文件的方式，其过程都是如下：
生成临时rdb文件，并写入数据。对应函数： /src/rdb.c/rdbLoad()完成数据写入，用临时文件替代正式的rdb文件 删除原来的db文件
默认生成的文件名为 dump.rdb， 文件的名称可在配置文件中修改。
rdbcompression yes # 是否压缩rdb文件
dbfilename dump.rdb # rdb文件名
dir ./ # rdb文件保存的目录复制
AOF(Append-only file)
AOF持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以Redis协议追加保存到以后缀为aof文件末尾，在Redis服务器重启时，会加载并运行aof文件的命令，以达到恢复数据的目的。
开启AOF持久化方式
Redis默认不开启AOF持久化方式，我们可以在配置文件中开启并进行更加详细的配置。
appendonly no # 默认不开启，开启改成yes
appendfilename "appendonly.aof" # aof文件名
# appendfsync always # 写入策略
appendfsync everysec # 写入策略
# appendfsync no # 写入策略
no-appendfsync-on-rewrite no # 默认不重写aof文件复制
写入策略
上面的配置文件中，我们看到通过appendfsync选项指定写入策略有三个选项：
always: 客户端的每一个写操作都保存到aof文件当中，这种策略很安全，但是每个写请求都有IO操作，所以也很慢。 everysec: appendfsync的默认写入策略，每秒写入一次aof文件，因此，最多可能会丢失1s的数据。 no: Redis服务器不负责写入aof，而是交由操作系统来处理什么时候写入aof文件。更快，但也是最不安全的选择，不推荐使用。
AOF文件重写
AOF将客户端的每一个写操作都追加到aof文件末尾，比如对一个key多次执行incr命令，这时候，aof保存每一次命令到aof文件中，aof文件会变得非常大。
127.0.0.1:6379> incr age
(integer) 1
127.0.0.1:6379> incr age
(integer) 2
127.0.0.1:6379> incr age
(integer) 3
...
127.0.0.1:6379> incr age
(integer) 100复制
aof文件太大，加载aof文件恢复数据时，就会非常慢，为了解决这个问题，Redis支持aof文件重写，通过重写aof，可以生成一个恢复当前数据的最少命令集，比如上面的例子中那么多条命令，可以重写为：
set age 100复制
aof文件是一个二进制文件，并不是像上面的例子一样，直接保存每个命令，而使用Redis自己的格式。具体的内容可以看appendonly.aof
文件。
两种重写方式
通过在redis.conf
配置文件中的选项no-appendfsync-on-rewrite
可以设置是否开启重写，这种方式会在每次fsync
时都重写，影响服务器性，因此默认值为no
，不推荐使用。
客户端向服务器发送bgrewriteaof命令，也可以让服务器进行AOF重写。
127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started复制
AOF重写方式也是异步操作，即如果要写入aof文件，则Redis主进程会forks一个子进程来处理。
重写aof文件的好处
压缩aof文件，减少磁盘占用量。 将aof的命令压缩为最小命令集，加快了数据恢复的速度。
AOF文件损坏
在写入aof日志文件时，如果Redis服务器宕机，则aof日志文件文件会出格式错误，在重启Redis服务器时，Redis服务器会拒绝载入这个aof文件，可以通过以下步骤修复aof并恢复数据。
1、备份现在的aof文件
2、使用 redis-check-aof
命令修复aof文件，命令格式如下
redis-check-aof [--fix] <file.aof>复制
3、重启Redis服务器，加载已经修复的aof文件恢复数据。
两种方式的优缺点
RDB
优点：
与AOF方式相比，通过rdb文件恢复数据比较快。 rdb文件非常紧凑，适合于数据备份。 通过RDB进行数据备份，由于使用子进程生成，所以对Redis服务器性能影响较小。
缺点：
如果服务器宕机的话，采用RDB的方式会造成某个时段内数据的丢失，比如我们设置5分钟达到1000次写入就同步一次，那么如果还没达到触发条件服务器就死机了，那么这个时间段的数据会丢失。 使用save命令会造成服务器阻塞，直接数据同步完成才能接收后续请求。 使用bgsave命令在forks子进程时，如果数据量太大，forks的过程也会发生阻塞，另外，forks子进程会耗费内存。
AOF
优点：
AOF只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗的内存较少。
缺点：
生成的日志文件太大，即使通过AFO重写，文件体积仍然很大。 恢复数据的速度比RDB慢。
选择RDB还是AOF呢?
如果想要数据足够安全，可以两种方式都开启，但两种持久化方式同时进行IO操作，会严重影响服务器性能，因此有时候不得不做出选择。
下面给出一个表格，可以从这几个方面对比一下RDB和AOF,根据自己的实际需求去选择。
| 方式 | RDB | AOF |
|---|---|---|
| 启动优先级 | 低 | 高 |
| 体积 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 会丢数据 | 由策略决定 |
| 轻重 | 重 | 轻 |
当RDB与AOF两种方式都开启时，Redis会优先使用AOF日志来恢复数据，因为AOF保存的文件比RDB文件更完整。
