1. 什么是Redis持久化?
Redis作为一个键值对内存数据库(NoSQL)，数据都存储在内存当中，在处理客户端请求时，所有操作都在内存当中进行。
见下图:
那么，接下来有人会问，内存数据库会不会很不稳定啊，万一服务器宕机了怎么办，或者强制重启了?
问得好！
事实上，redis的设计者早就想到了这种风险，因此redis是支持持久化的。
Redis提供了RDB和AOF两种不同的数据持久化方式，后面我就来详细介绍一下这2种不同的持久化方式。
2. RDB持久化方式
RDB是一种快照存储持久化方式，具体就是将Redis某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为dump.rdb。
当Redis服务器启动时，会重新加载dump.rdb文件的数据到内存当中恢复数据。
如何开启RDB持久化方式
开启RDB持久化方式很简单:
1) 客户端可以通过向Redis服务器发送save或bgsave命令让服务器生成rdb文件 2) 或者通过服务器配置文件指定触发RDB条件
下面详细介绍下这2种触发方式:
1. save命令
save命令相当于一个同步操作。
# 同步数据到磁盘上
> save
缺点:
如果数据量太大，同步数据会执行很久，而这期间Redis服务器也无法接收其他请求。
所以，最好不要在生产环境使用save命令, 即使要用也应该在服务器空闲期。
2. bgsave
与save命令不同，bgsave命令是一个异步操作。
# 异步保存数据集到磁盘上
> bgsave
详细解释:
当客户端发出bgsave命令时，Redis服务器主进程会forks一个子进程来数据同步问题，在将数据保存到rdb文件之后，子进程会退出。
所以，与save命令相比，Redis服务器在处理bgsave采用子线程进行IO写入，而主进程仍然可以接收其他请求
缺点:
forks子进程是同步的，所以forks子进程时，一样不能接收其他请求
这意味着，如果forks一个子进程花费的时间太久(一般是很快的)，bgsave命令仍然有阻塞其他客户的请求的情况发生。
3. 服务器配置自动触发
这种方式是指在Redis配置文件中的save指定到达触发RDB持久化的条件，比如(多少秒内至少达到多少写操作)就开启RDB数据同步。
开启步骤：
redis.conf指定如下的选项：
# 900s内至少达到一条写命令 save 900 1 # 300s内至少达至10条写命令 save 300 10 # 60s内至少达到10000条写命令 save 60 10000
启动服务器时加载配置文件:
# 启动服务器加载配置文件
redis-server redis.conf
详细解释:
这种通过服务器配置文件触发RDB的方式，与bgsave命令类似，达到触发条件时，会forks一个子进程进行数据同步。
建议:
最好不要通过这方式来触发RDB持久化，因为设置触发的时间太短，则容易频繁写入rdb文件，影响服务器性能，时间设置太长则会造成数据丢失。
rdb文件的自定义配置:
# 是否压缩rdb文件 rdbcompression yes # rdb文件的名称 dbfilename redis-6379.rdb # rdb文件保存目录 dir ~/redis/
RDB的优点:
1) 与AOF方式相比，通过rdb文件恢复数据比较快。
2) rdb文件非常紧凑，适合于数据备份。
3) 通过RDB进行数据备，由于使用子进程生成，所以对Redis服务器性能影响较小。
RDB的缺点:
1) 如果服务器宕机的话，采用RDB的方式会造成某个时段内数据的丢失，比如我们设置10分钟同步一次或5分钟达到1000次写入就同步一次，如果还没达到触发条件服务器就死机了，那么这个时间段的数据会丢失。
2) 使用save命令会造成服务器阻塞，直接数据同步完成才能接收后续请求。
3) 使用bgsave命令在forks子进程时，如果数据量太大，forks的过程也会发生阻塞，另外，forks子进程会耗费内存。
3. AOF持久化方式
AOF(Append-only file)与RDB存储某个时刻的快照不同，AOF持久化方式会记录客户端对服务器的每一次写操作命令，
并将这些写操作以Redis协议追加保存到以后缀为aof文件末尾，
在Redis服务器重启时，会加载并运行aof文件的命令，以达到恢复数据的目的。
开启AOF持久化方式
Redis默认不开启AOF持久化方式，我们可以在配置文件中开启并进行更加详细的配置。
redis.conf：
# 开启aof机制 appendonly yes # aof文件名 appendfilename "appendonly.aof" # 写入策略,always表示每个写操作都保存到aof文件中,也可以是everysec或no appendfsync always # 默认不重写aof文件 no-appendfsync-on-rewrite no # 保存目录 dir ~/redis/
三种写入策略
1. always
客户端的每一个写操作都保存到aof文件当，这种策略很安全，但是每个写请注都有IO操作，所以也很慢。
2. everysec
appendfsync的默认写入策略，每秒写入一次aof文件，因此，最多可能会丢失1s的数据。
3. no
Redis服务器不负责写入aof，而是交由操作系统来处理什么时候写入aof文件。更快，但也是最不安全的选择，不推荐使用。
AOF文件重写
AOF将客户端的每一个写操作都追加到aof文件末尾，比如对一个key多次执行incr命令，这时候，aof保存每一次命令到aof文件中，aof文件会变得非常大。
aof文件太大，加载aof文件恢复数据时，就会非常慢，为了解决这个问题，Redis支持aof文件重写，通过重写aof，可以生成一个恢复当前数据的最少命令集，比如上面的例子中那么多条命令，可以重写为：
set num 100000
AOF重写方式也是异步操作，即如果要写入aof文件，则Redis主进程会forks一个子进程来处理。
AOF文件损坏
在写入aof日志文件时，如果Redis服务器宕机，则aof日志文件文件会出格式错误，在重启Redis服务器时，Redis服务器会拒绝载入这个aof文件，可以通过以下步骤修复aof并恢复数据。
1、备份现在aof文件，以防万一。
2、使用redis-check-aof命令修复aof文件，该命令格式如下：
# 修复aof日志文件 $ redis-check-aof -fix file.aof
3、重启Redis服务器，加载已经修复的aof文件，恢复数据。
AOF的优点：
AOF只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗的内存较少。
AOF的缺点：
AOF方式生成的日志文件太大，即使通过AFO重写，文件体积仍然很大。
恢复数据的速度比RDB慢。
总结:
