1.快照（snapshats）
1-1：配置文件
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb （存储文件）
含义：指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
1-2：可以自己手动存储
save 命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。
一般来说，在生产环境很少执行 SAVE 操作，因为它会阻塞所有客户端，保存数据库的任务通常由 BGSAVE 命令异步地执行。
然而，如果负责保存数据的后台子进程不幸出现问题时，SAVE 可以作为保存数据的最后手段来使用。
原理
- Redis forks.
- 子进程开始将数据写到临时RDB文件中。
- 当子进程完成写RDB文件，用新文件替换老文件。
- 这种方式可以使Redis使用copy-on-write技术。
特点
快照易恢复，文件也小，但是如果遇到宕机等情况的时候快照的数据可能会不完整。此时可能需要启用另一种持久化方式AOF
2.append only mode (aof)
配置
appendonly yes
appendfsync everysec （可选参数：
appendfsync always #always 表示每次有写操作都进行同步，非常慢，非常安全。
appendfsync everysec #everysec表示对写操作进行累积，每秒同步一次
官方的建议的everysec，安全，就是速度不够快，如果是机器出现问题可能会丢失1秒的数据。
也可以手动执行bgrewriteaof进行AOF备份： bgrewriteaof
）
AOF重写
AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令,
AOF日志也不是完全按客户端的请求来生成日志的，比如命令 INCRBYFLOAT 在记AOF日志时就被记成一条SET记录，
因为浮点数操作可能在不同的系统上会不同，所以为了避免同一份日志在不同的系统上生成不同的数据集，所以这里只将操作后的结果通过SET来记录。
每一条写命令都生成一条日志,AOF文件会很大。
AOF重写是重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。
其生成过程和RDB类似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。
在写入新文件的过程中，所有的写操作日志还是会写到原来老的 AOF文件中，同时还会记录在内存缓冲区中。
当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。然后调用原子性的rename命令用新的 AOF文件取代老的AOF文件
原理：
AOF重写并不需要对原有AOF文件进行任何的读取，写入，分析等操作，这个功能是通过读取服务器当前的数据库状态来实现的。
命令：
BGREWRITEAOF， 我们应该经常调用这个命令来来重写
当redis服务器挂掉时，重启时将按照以下优先级恢复数据到内存：
- 如果只配置AOF,重启时加载AOF文件恢复数据；
- 如果同时 配置了RBD和AOF,启动是只加载AOF文件恢复数据;
- 如果只配置RBD,启动是讲加载dump文件恢复数据。
恢复时需要注意，要是主库挂了不能直接重启主库，否则会直接覆盖掉从库的AOF文件，一定要确保要恢复的文件都正确才能启动，否则会冲掉原来的文件。