对任何一个开发或者运维人员来说，一定要有数据备份的意识，防止出现意外情况导致数据丢失。Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化文件即可实现数据恢复。
RDB持久化
1.RDB解释
RDB持久化是把当前进程数据生成快照保存到硬盘的过程，把数据保存到后缀为rdb的文件，触发RDB持久化过程分为手动触发和自动触发，redis默认开启该方式。
2.触发机制
- 手动触发
手动触发的方式为执行save和bgsave命令。save命令：阻塞当前Redis服务器，知道RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，在后台运行，完成后自动结束。阻塞只发生在fork阶段，一段时间很短。
#save
redis 127.0.0.1:6379>save
ok
#bgsave
redis 127.0.0.1:6379>bgsave
Background saving started
执行后，会在redis的安装目录生成一个后缀为rdb的文件，文件里保存的就是redis里的数据。
-
自动触发
自动触发是在满足某些触发条件时候，redis主动进行持久化操作，不需要手动执行命令。自动触发的场景有如下：
(1).使用save相关配置，如redis.conf文件里设置的"save m n"表示m秒之内数据集存在n次修改时，自动触发rdb持久化。
(2).如果配置了主从，从节点执行全量复制操作，主节点自动触发生成RDB文件并发送给从节点。
(3).执行debug reload命令重新加载Redis时，也会自动触发。
(4).默认情况下执行shutdown关闭redis时，如果没有开启AOF持久化功能则自动执行bgsave。 -
RDB文件处理
保存：RDB文件保存在dir配置指定的目录下，文件名通过redis.conf文件里的dbfilename配置指定，可以通过执行config set dir {newDir} 和 config set dbfilename {newFileName}运行期动态执行，当下次运行时RDB文件会保存到新目录。
压缩：Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可以通过参数config set rdbcompression {yes|no}动态修改。
校验：如果Redis加载损坏的RDB文件时拒绝启动，并打印有如下日志：
Short read or OOM loading DB. Unrecoverable error , aborting now。 这时可以使用Redis提供的redis-check-dump工具检测RDB文件并获取对应的错误报告。 -
RDB优缺点
优点：RDB是一个紧凑压缩的二进制文件，代表Redis在某一个时间点上的数据快照。非常适合用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。Redis加载RDB恢复数据远远快于AOF方式。
缺点：RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高，RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，RDB文件开头会有version版本号标识，存在老版本Redis服务无法兼容新版RDB格式的问题。
AOF持久化
-
AOF解释
AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF文件里记录的并非redis里的真实数据，而是记录的每一条写的命令，只许追加文件但不可以改写文件。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。 -
AOF配置
AOF默认关闭，开启需要设置redis.conf里的appendonly参数值为yes。AOF文件通过appendfilename参数设置保存的aof文件名，默认文件名是appendonly.aof。保存路径同RDB持久化方式一致，通过dir配置指定。AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）。
(1).所有的写入命令会追加到aof_buf（缓冲区）中。
(2).AOF缓冲区根据对应的策略向硬盘做同步操作。
(3).随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
(4).当Redis服务重启时，可以加载AOF文件进行数据恢复。 -
参数解释：
appendonly:是否开启AOF,默认为no。
appendfilename：保存的文件名，默认为appendonly.aof。
appendfsync:持久化策略，默认为每秒。可选值always(同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好),everysec(异步操作，每秒记录，如果一秒钟内宕机，有数据丢失)，no(将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的）。 -
重写(Rewrite)
定义：AOF采用文件追加的方式持久化数据，所以文件会越来越大，为了避免这种情况发生，增加了重写机制。当AOF文件的大小超过了配置所设置的阙值时，Redis就会启动AOF文件压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof。
触发机制：Redis会记录上次重写时的AOF文件大小，默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发 。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
AOF配置文件损坏修复方法：
redis-check-aof –fix AOF配置文件名称 -
AOF优缺点
优点：
(1).该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。
(2).由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
(3).如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
(4).AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。
缺点：
(1).对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
(2).根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。
两种持久化的方式各有优劣，具体选取哪种方式，根据实际情况选择，或者可以两种方式都开启。各位如果觉得还有点意义，烦请点一下推荐，加个关注，互相交流。