Redis介绍
Redis是一个内存型的NoSql非关系型数据库，它将所有的数据存储在内存中进行读写操作，这也是Redis为什么非常快的原因之一。但是当Redis服务重启、电脑重启、电脑宕机等原因，Redis在内存中存储的数据就会丢失（不可找回），内存虽然快但是重启之后内存中的数据就被清楚了。所以Redis就提供了两种持久化（将数据存储到磁盘上）方案，分别是RDB和AOF，目的都是在重启Redis服务时根据磁盘文件将数据恢复到内存中，继续提供数据服务，各位童鞋也可以参照：Redis持久化官方文档。
RDB
介绍
RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
配置
在Redis的redis.conf配置文件中RDB是默认开启的。
# 配置持久化文件存储路径
dir "/var/redis-5.0.5/data"
# 配置rdb
# 20s 对key做了5次操作就会进行快照存储,可以配置多个,只要有一个条件成立就会快照
save 20 5
save 300 10
save 60 10000
# rdb文件名 用默认的即可
dbfilename dump.rdb
演示
不使用rdb
启动Redis
进入Redis客户端并添加数据
关闭Redis
开启Redis
进入Redis客户端并获取key
可以发现我们在上面的数据已经丢失了，然后让我们把Redis关掉在使用rdb试一下。
使用rdb
配置文件配置rdb
启动Redis
看一下在配置文件中配置的持久化文件存储路径下是否有rdb文件
可以看到该路径下只有一个pid文件，该文件是Redis启动后存放pid的文件，并没有rdb文件。
进入Redis客户端，在20s内操作5次key并退出
看一下在配置文件中配置的持久化文件存储路径下是否有rdb文件
关闭Redis
开启Redis
进入Redis客户端并获取key
我在20s内写到了 k7，但是可以看到Redis重启之后恢复到内存中的数据只有5个，是因为这五个是我在20s之内操作的，Redis的RDB记录下来了。另外三个数据的丢失，有一个是因为在20s之外操作的所以没有记录，如果想要记录下来的话，那么在配置文件里可以加上save 1 1，这代表在1s内操作1次就会记录下来，还有两个虽然是在20s之内操作的但是也没有记录，是因为我们在配置文件中只设置了三个记录的条件，分别为20s操作5次记录、300s操作10次记录、60s操作10000次记录；很显然，丢失的那两个数据并没有条件成立，所以数据就会丢失，解决办法有两个：一个是加上save 20 7，20s内操作7次记录，另一个就是加上save 3 2，3s内操作2次记录。
特点
- 根据save的配置，在指定时间范围内对key操作达到指定次数才会对内存做快照
- 如果你想立马对内存做快照可以使用 save 命令
- 启动Redis时根据配置文件中的
dir和dbfilename找到快照文件将数据存恢复到内存中 - 有可能丢失一段时间内的数据，快照文件中只有数据，恢复数据是很快的
RDB的优点
- RDB是一个非常紧凑的文件，它保存了某个时间点得数据集，非常适用于数据集的备份，这样即使出了问题你也可以根据需求恢复到不同版本的数据集。
- RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3（可能加密），非常适用于灾难恢复。
- RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能。
- 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些。
RDB的缺点
- 如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据。
- RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度。
AOF
介绍
AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大，AOF默认是关闭的，需要开启。
配置
# 配置持久化文件存储路径
dir "/var/redis-5.0.5/data"
# 开启aof
appendonly yes
# 文件名
appendfilename "appendonly.aof"
# 持久化策略,no:不同步,everysec:每秒一次,always:总是同步,速度比较慢
# appendfsync always
appendfsync everysec
# appendfsync no
演示
开启Redis
看一下在配置文件中配置的持久化文件存储路径下是否有aof文件
&esmp;Redis开启AOF后，启动Redis后，Redis就会创建一个aof的文件，但是文件里面什么都没有，是空的。
进入Redis客户端并获取一下key
看一下aof文件中是否有读操作的命令记录
可以看到aof中并没有读操作的命令，aof只会记录Redis的写操作（添加，修改，删除）而不会去记录读操作。
在Redis客户端添加数据
看一下aof中是否有添加记录
可以看到在aof文件中有我们刚刚添加的k1 v1，k2 v2等数据，aop文件中还有一个SELECT的单词，这里要注意一下，这个SELETE并不是SQL语句中的查询，而是Redis的换库命令。Redis共有16个库，我们当前所处的是Redis的默认0号库，在SELECT下面第二个有一个0，这代表0号库，Redis的数据恢复也一定要注意这些数据是在哪个库里面存着的。
关闭Redis
启动Redis
进入Redis客户端查看是否有数据
可以看到，数据都恢复到了内存中。
特点
- 将Redis服务写命令，存储在aof文件中，并且包含select换库命令
- 默认关闭，需要修改配置打开
- 与RDB一起存在恢复数据时优先使用aof
优点
- 使用AOF 会让你的Redis更加耐久:：你可以使用不同的fsync策略：无fsync，每秒fsync，每次写的时候fsync。使用默认的每秒fsync策略，Redis的性能依然很好(fsync是由后台线程进行处理的，主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据。
- AOF文件是一个只进行追加的日志文件，所以不需要写入seek，即使由于某些原因（磁盘空间已满，写的过程中宕机等等）未执行完整的写入命令，你也也可使用redis-check-aof工具修复这些问题。
- Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
- AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis，就可以将数据集恢复到 FLUSHALL 执行之前的状态。
缺点
- 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
- 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依
然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过
在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。
总结
Redis的持久化东西还是蛮多的，只是配置相对简单一些，这些是一些基础的配置，后面如果Redis做一些主从复制，Redis Cluster集群配置的时候，就会有一些更复杂的难度了。