一、RDB方式（默认）
1.默认方式，如果不想使用rdb方式，在redis.conf文件中，配置save ""
2.rdb方式是通过快照方式进行持久化的
3.rdb方式持久化需要满足一定条件才可以。如何设置条件？需要在redis.conf文件中配置savet条件，多个save条件之间是或的关系
4.RDB优缺点
-
缺点：使用
RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这个时候我们就需要根据具体的应用场景，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受范围。如果数据相对来说比较重要，希望将损失降到最小，则可以使用AOF方式进行持久化 -
优点：
RDB可以最大化Redis的性能：父进程在保存RDB文件时唯一要做的就是fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无需执行任何磁盘I/O操作。同时这个也是一个缺点，如果数据集比较大的时候，fork可以能比较耗时，造成服务器在一段时间内停止处理客户端的请求；
5.当不能容忍数据的丢失时，必须要考虑aof持久化方式
6.AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。通过redis.confi配置文件dir ./ 指定
7.RDB文件名通过redis.confi配置文件 dbfilename dump.rdb 配置
二、AOF方式
1.需手动开启：在redis.conf文件中，配置appendonly yes 。 aof的持久化文件后缀名。aof
2.一旦开启了aof方式的持久化，那么每一次执行增删改操作，就会往磁盘中保存一次（保存的时命令）。导致了性能会有降低，可以使用一些硬件来弥补（SSD硬盘）
3.其实AOF的每次写操作的持久化都不是理论上的实时操作。（磁盘同步理解）
appendfsync always #设置为always时，会极大消弱Redis的性能，因为这种模式下每次write后都会调用fsync（Linux为调用fdatasync）。
appendfsync everysec #每秒落盘一次
appendfsync no #write后不会有fsync调用，由操作系统自动调度刷磁盘，性能是最好的
4.AOF文件优化（AOF重写）
表示当前aof文件大小超过上一次aof文件大小的百分只多少的时候就会进行重写.如果之前没有重写过，以启动时aof文件大小为准：auto-aof-rewrite-percentage 100
限制允许重写最小aof文件大小，也就时文件大小小于64mb的时候，不需要进行优化：auto-aof-rewrite-min-size 64mb
5.AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的。通过redis.confi配置文件dir ./ 指定
6.AOF文件名通过redis.confi配置文件 appendfilename "appendonly.aof"配置
三、AOF文件损坏以后如何修复
服务器可能在程序正在对 `AOF` 文件进行写入时停机， 如果停机造成了 `AOF` 文件出错（`corrupt`）， 那么 `Redis` 在重启时会拒绝载入这个 `AOF` 文件， 从而确保数据的一致性不会被破坏。当发生这种情况时， 可以用以下方法来修复出错的 `AOF` 文件：
1.为现有的 `AOF` 文件创建一个**备份**
2. 使用 `Redis` 附带的 **`redis-check-aof`** 程序，对原来的 `AOF` 文件进行修复
3.redis-check-aof --fix readonly.aof
4. 重启 `Redis` 服务器，等待服务器载入修复后的 `AOF` 文件，并进行数据恢复
四、如何选择RDB和AOF
1.一般来说,如果对数据的安全性要求非常高的话，应该同时使用两种持久化功能。
2.如果可以承受数分钟以内的数据丢失，那么可以只使用 `RDB` 持久化。
3.有很多用户都只使用 `AOF` 持久化， 但并不推荐这种方式： 因为定时生成 `RDB` 快照（`snapshot`）非常便于进行数据库备份， 并且 `RDB` 恢复数据集的速度也要比 `AOF` 恢复的速度要快 。
4.两种持久化策略可以同时使用，也可以使用其中一种。如果同时使用的话， 那么`Redis`重启时，会优先**使用`AOF`文件来**还原数据。