简介
背景
Redis是一种内存数据库，在断电时数据可能会丢失。比如你redis整个挂了，然后redis不可用了，如果没有持久化的话，redis就会丢失所有的数据，如果通过持久化将数据搞一份儿到磁盘上去，然后再定期同步到一些云存储服务上去，那么就可以保证一些数据不丢失，保证数据的可靠性。
持久化方式
Redis中为了保证在系统宕机(类似进程被杀死)情况下，能更快的进行故障恢复，设计了两种数据持久化方案，分别为rdb和aof方式。
配置准备工作
第一步:从redis.io官方下载对应版本的redis.conf文件,地址如下:
https://redis.io/topics/config/第二步:停止redis并删除挂载目录下(/usr/local/docker/redis01/conf)的redis.conf配置文件.
第三步:将下载的redis.conf文件拷贝到redis挂载目录(/usr/local/docker/redis01/conf)
第四步:基于vim打开redis.conf文件,然后注释 bind 127.0.0.1这一行,并修改protected-mode的值修改为no.(java连接redis需要改这两项目)
第五步:重启redis服务,并检查启动日志(docker logs 容器id)
Rdb方式持久化
概述
Rdb方式是通过手动(save-阻塞式，bgsave-异步)或周期性方式保存redis中key/value的一种机制,Rdb方式一般为redis的默认数据持久化方式.系统启动时会自动开启这种方式的持久化机制。
RDB方式配置
RDB方式的持久化是默认开启的，也可按规则自己配置，例如，打开redis.conf文件，例如
# 这里表示每隔60s，如果有超过1000个key发生了变更，那么就生成一个新的dump.rdb文件，就是当前redis内存中完整的数据快照，这个操作也被称之为snapshotting(快照)。
save 60 1000
# 持久化 rdb文件遇到问题时，主进程是否接受写入，yes 表示停止写入，如果是no 表示redis继续提供服务。
stop-writes-on-bgsave-error yes
# 在进行快照镜像时,是否进行压缩。yes:压缩，但是需要一些cpu的消耗。no:不压缩，需要更多的磁盘空间。
rdbcompression yes
# 一个CRC64的校验就被放在了文件末尾，当存储或者加载rbd文件的时候会有一个10%左右的性能下降，为了达到性能的最大化，你可以关掉这个配置项。
rdbchecksum yes
# 快照的文件名
dbfilename dump.rdb
# 存放快照的目录
dir /var/lib/redisRdb方式持久化实践
试验一
在redis中保存几条数据，然后执行shutdown关闭redis,然后再重启redis，看看刚才插入的数据是否还在？假如数据还在，为什么？
因为,通过redis-cli shutdown这种方式去停掉redis，其实是一种安全退出的模式，redis在退出的时候会将内存中的数据立即生成一份完整的rdb快照,例如
127.0.0.1:6379> set phone 11111111
OK
127.0.0.1:6379> shutdown #默认也会进行持久化
[root@centos7964 ~]# docker start redis01
[root@centos7964 ~]# docker exec -it redis01 redis-cli
127.0.0.1:6379> keys *
1) "pone"试验二
在redis中再保存几条新的数据，用kill -9粗暴杀死redis进程，模拟redis故障异常退出，导致内存数据丢失的场景？
这次就发现，redis进程异常被杀掉，几条最新的数据就丢失了。例如:
首先,打开第一个客户端,先清除redis内存和磁盘对应的数据
[root@centos7964 data]# docker exec -it redis01 redis-cli
127.0.0.1:6379> flushall
OK
127.0.0.1:6379> exit
[root@centos7964 data]# ls
dump.rdb
[root@centos7964 data]# rm –f dump.rdb
[root@centos7964 data]# ls然后,打开并登录第二个客户端,并向redis存储一些数据,例如
[root@centos7964 ~]# docker exec -it redis01 redis-cli
127.0.0.1:6379> set one mybatis
OK
127.0.0.1:6379> set two spring
OK
127.0.0.1:6379> keys *
1) "one"
2) "two"接下来,再次回到第一个客户端,杀掉redis进程,例如
[root@centos7964 data]# ps -ef | grep redis
polkitd 6995 6974 0 14:44 ? 00:00:00 redis-server *:6379
root 7064 6974 0 14:44 pts/0 00:00:00 redis-cli
root 7111 6467 0 14:47 pts/1 00:00:00 docker exec -it redis01 redis-cli
root 7130 6974 0 14:47 pts/1 00:00:00 redis-cli
root 7278 7180 0 14:51 pts/0 00:00:00 grep --color=auto redis
[root@centos7964 data]# kill -9 6995
[root@centos7964 data]# docker start redis01最后,打开第一个客户端,登录redis,检查key是否还存在.
[root@centos7964 ~]# docker exec -it redis01 redis-cli
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379>
[root@centos7964 ~]#试验三
手动调用save(同步保存)或者bgsave(异步保存)执行rdb快照生成.然后杀掉redis进程,再重启检测是否还有刚刚保存的数据.
127.0.0.1:6379> set id 100
OK
127.0.0.1:6379> set name jack
OK
127.0.0.1:6379> save #阻塞式持久化
OK
127.0.0.1:6379> set address beijing
OK
127.0.0.1:6379> bgsave #异步方式持久化
Background saving started小节面试分析
触发redis中rdb方式持久化的时机?
1)基于配置文件中的save规则周期性的执行持久化。
2)手动执行了shutdown操作会自动执行rdb方式的持久化。
3)手动调用了save或bgsave指令执行数据持久化。
4)在Master/Slave架构下,当有新的Slave连接Master时,Master会对数据进行rdb方式持久化.
Redis中的save和bgsave有什么不同？
Save 命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。
BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。
RDB持久化机制有哪些优点？
RDB 文件是经过压缩的二进制文件，占用空间很小，它保存了 Redis 某个时间点的数据集，很适合做冷备.
RDB 非常适用于灾难恢复,它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心。
RDB 方式持久化性能较好，执行持久化时可以fork 一个子进程，由子进程处理保存工作，父进程无须执行任何磁盘 I/O 操作。
RDB持久化机制有哪些缺点？
RDB方式在服务器故障时容易造成数据的丢失。实际项目中，我们可通过配置来控制持久化的频率。但是，如果频率太频繁，可能会对 Redis 性能产生影响。所以通常可能设置至少5分钟才保存一次快照，这时如果 Redis 出现宕机等情况，则意味着最多可能丢失5分钟数据。
RDB 方式使用 fork 子进程进行数据的持久化，子进程的内存是在fork操作时父进程中数据快照的大小，如果数据快照比较大的话，fork 时开辟内存会比较耗时，同时这个fork是同步操作，所以，这个过程会导致父进程无法对外提供服务。
3)RDB持久化过程中的fork操作，可能会导致内存占用加倍，Linux系统fork 子进程采用的是 copy-on-write 的方式（写时复制，修改前先复制），在 Redis 执行 RDB 持久化期间，如果 client 写入数据很频繁，那么将增加 Redis 占用的内存，最坏情况下，内存的占用将达到原先的2倍。
Aof方式数据持久化
概述
Aof方式是通过记录写操作日志的方式,实现redis数据持久化的一种机制,这个机制默认是关闭的。
AOF方式配置
# 是否开启AOF，默认关闭
appendonly yes
# 指定 AOF 文件名
appendfilename appendonly.aof
# Redis支持三种刷写模式：
# appendfsync always #每次收到写命令就立即强制写入磁盘，类似MySQL的sync_binlog=1,是最安全的。但该模式下速度也是最慢的，一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次，在性能和持久化方面做平衡，推荐该方式。
# appendfsync no #完全依赖OS的写入，一般为30秒左右一次，性能最好但是持久化最没有保证，不推荐。
#在日志重写时，不进行命令追加操作，而只是将其放在缓冲区里，避免与命令的追加造成DISK IO上的冲突。
#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes
no-appendfsync-on-rewrite yes
#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mbAOF方式持久化实践
第一：打开AOF的开关，启用AOF持久化
第二：写入一些数据，观察AOF文件（appendonly.aof）中的日志内容
第三：kill -9杀掉redis进程，重新启动redis进程，发现数据被恢复回来了，就是从AOF文件中恢复回来的，redis进程启动的时候，直接就会从appendonly.aof中加载所有的日志，把内存中的数据恢复回来。
小节面试分析
如何理解AOF方式中的rewrite操作？
redis中的可以存储的数据是有限的，很多数据可能会自动过期，也可能会被用户删除或被redis用缓存清除的算法清理掉。也就是说redis中的数据会不断淘汰掉旧的，只有一部分常用的数据会被自动保留在redis内存中，所以可能很多之前的已经被清理掉的数据，对应的写日志还停留在AOF中，AOF日志文件就一个，会不断的膨胀，最后导致文件很大。
所以,AOF会自动在后台每隔一定时间做rewrite操作，比如日志里已经存放了针对100w数据的写日志了，但redis内存现在10万数据; 于是，基于内存中当前的10万数据构建一套最新的日志，然后到AOF文件中; 覆盖之前的老日志，从而，确保AOF日志文件不会过大，保持跟redis内存数据量一致。
AOF持久化机制有哪些优点？
AOF 比 RDB更加可靠。你可以设置不同的 fsync 策略（no、everysec 和 always）。默认是 everysec，在这种配置下，redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据。
AOF文件是一个基于纯追加模式的日志文件。即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机等等）， 我们也可以使用 redis-check-aof 工具也可以轻易地修复这种问题。
当 AOF文件太大时，Redis 会自动在后台进行重写。重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写是绝对安全，因为重写是在一个新的文件上进行，同时 Redis 会继续往旧的文件追加数据。当新文件重写完毕，Redis 会把新旧文件进行切换，然后开始把数据写到新文件上。
AOF 文件有序地保存了对数据库执行的所有写入操作，以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析也很轻松。如果你不小心执行了 FLUSHALL 命令把所有数据刷掉了，但只要 AOF 文件没有被重写，那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
AOF持久化机制有哪些缺点？
对于相同的数据集，AOF 文件的大小一般会比 RDB 文件大。根据所使用的 fsync 策略，AOF 的速度可能会比 RDB 慢。通常 fsync 设置为每秒一次就能获得比较高的性能，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快。AOF 可能会因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。
如何选择redis的持久化方式？
第一：不要仅仅使用RDB，因为那样会导致你丢失很多数据。
第二：也不要仅仅使用AOF，因为AOF做冷备没有RDB做冷备进行数据恢复的速度快,并且RDB简单粗暴的数据快照方式更加健壮。
第三：综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备。
总结（Summary）
以上主要是对redis中的持久化方式，持久化机制，应用实践进行基本分析与讲解。重点是如何在生产环境下应用。
