redis持久化是什么
Redis的强大功能很大程度上是由于其将所有数据都存储在内存中，存取数据块。为了使Redis在重启后仍能保证数据不丢失, 需要将数据从内存中以某种形式持久化到硬盘中。Redis支持两种持久化方式,一种是RDB方式,一种是AOF方式。可以单独使用其中一种或两种结合使用。
RDB持久化
原理
RDB持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）
优点
- RDB非常适用于灾难恢复（disaster recovery）它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中
- RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快
缺点
- 无法完全避免在服务器故障时丢失数据
- 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程来进行实际的持久化工作。在数据集比较庞大时，fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端
配置
RDB是Redis默认的持久化方式- 在配置文件中已经预置了三个条件:
# 以下条件是或的关系
save 900 1 # 15分钟内至少有一个键被更改
save 300 10 # 5分钟内至少有10个键被更改
save 60 10000 # 1分钟内至少有10000个键被更改123
- 默认的rdb文件路径是当前目录,文件名是:dump.rdb,可以在配置文件中修改路径和文件名,分别是dir和dbfilename
dir ./ # rdb文件存储路径
dbfilename dump.rdb # rdb文件名
AOF持久化
原理
AOF持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集
优点
- 使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。 AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）
- AOF文件是一个只进行追加操作的日志文件（append only log）
- Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作
- AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存
缺点
- 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积
- 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB
- AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。）
配置
- 配置文件中打开aof
appendonly yes - aof其他配置
- 配置文件中打开aof
appendfilename appendonly.aof #目录和RDB文件目录一样，默认文件名是appendonly.aof,可通过append filename参数修改：
auto-aof-rewrite-percentage 100 #当前的AOF文件大小超过上一次重写的AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF大小为依据。
auto-aof-rewrite-min-size 64mb #限制了允许重写的最小AOF文件,通常在AOF文件很小的时候即使其中有些冗余命令也可是可以忽略的
# appendfsync always 每次都同步(最安全但是最慢)
appendfsync everysec 每秒同步(默认的同步策略)
# appendfsync no 不主动同步,由操作系统来决定(最快但是不安全)
Master-Slave持久化
可以在master中禁用持久化 ，并在slave中开启持久化，如果slave崩溃了，master会自动同步过来，但master崩溃后，手工通过slave 恢复数据时需要严格按照以下两频进行:
- 在slave中使用
SLAVEOF NO ONE命令将从数据库提升成master继续服务 - 启动之前崩溃的master,然后使用salveof命令将其设置成新的master的slave
当开启复制且master关闭持久化功能时，一定不能使用Supervisor以及类似进程管理工具令master自动重启
