- RDB：快照形式是直接把内存中的数据保存到一个 dump 文件中，恢复时是将快照文件直接读到内存里。
- AOF：把全部的对Redis的服务器进行修改的命令都存到一个文件里，命令的集合。
Redis默认是快照RDB的持久化方式java
RDB
RDB 有两种触发方式，分别是自动触发和手动触发redis
-
自动触发缓存
在 redis.conf 配置文件中的 SNAPSHOTTING 下，加上以下配置：安全
save 900 1：表示900 秒内若是至少有 1 个 key 的值变化，则保存 save 300 10：表示300 秒内若是至少有 10 个 key 的值变化，则保存 save 60 10000：表示60 秒内若是至少有 10000 个 key 的值变化，则保存
固然若是你只是用Redis的缓存功能，不须要持久化，那么你能够注释掉全部的 save 行来停用保存功能，也可使用`redis-cli config set save ""命令服务器
-
手动触发app
手动触发Redis进行RDB持久化的命令有两种：异步
-
save函数
该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其余命令，直到RDB过程完成为止工具
-
bgsave性能
执行该命令时，Redis会在后台异步进行快照操做，快照同时还能够响应客户端请求。具体操做是Redis进程执行fork操做建立子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，通常时间很短
-
基本上 Redis 内部全部的RDB操做都是采用 bgsave 命令
恢复数据
将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务便可，redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工做完成为止。
获取 redis 的安装目录可使用 config get dir 命令
RDB优点与劣势
优点：
- RDB是一个很是紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件很是适合用于进行备份和灾难恢复
- 生成RDB文件的时候，redis主进程会fork()一个子进程来处理全部保存工做，主进程不须要进行任何磁盘IO操做
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快
劣势：
- RDB方式数据没办法作到实时持久化/秒级持久化。由于bgsave每次运行都要执行fork操做建立子进程，属于重量级操做(内存中的数据被克隆了一份，大体2倍的膨胀性须要考虑)，频繁执行成本太高(影响性能)
- RDB文件使用特定二进制格式保存，Redis版本演进过程当中有多个格式的RDB版本，存在老版本Redis服务没法兼容新版RDB格式的问题(版本不兼容)
- 在必定间隔时间作一次备份，因此若是redis意外down掉的话，就会丢失最后一次快照后的全部修改(数据有丢失)
AOF
AOF配置
在 redis.conf 配置文件的 APPEND ONLY MODE 下：
- appendonly no 默认配置，表示不开启AOF持久化
- appendfilename “appendonly.aof” AOF日志文件名
- appendfsync： aof持久化策略的配置；
- no表示不执行fsync，由操做系统保证数据同步到磁盘，速度最快，可是不太安全；
- always表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低；
- everysec表示每秒执行一次fsync，可能会致使丢失这1s数据。一般选择 everysec ，兼顾安全性和效率
AOF文件恢复
重启 Redis 以后就会进行 AOF 文件的载入
AOF重写
AOF文件不断变大，Redis为了解决这种状况，在文件大小达到必定阈值后，进行AOF重写，对AOF文件进行压缩，只保留能够恢复数据的最小指令集
举个例子：
sadd key "A" "B" "C"
若是不重写会保留三条sadd指令，可是重写只会保留一条
- 执行AOF重写的时候，会直接读取服务器内存的全部键值对，不是对以前的AOF文件进行整理
- 子进程进行 AOF 重写期间，服务器进程（父进程）能够继续处理其余命令
- 子进程带有父进程的数据副本，使用子进程而不是线程，能够在避免使用锁的状况下，保证数据的安全性
主进程和子进程以前可能会产生数据不一致，解决方案：
Redis 服务器设置了一个 AOF 重写缓冲区，这个缓冲区是在建立子进程后开始使用，当Redis服务器执行一个写命令以后，就会将这个写命令也发送到 AOF 重写缓冲区。当子进程完成 AOF 重写以后，就会给父进程发送一个信号，父进程接收此信号后，就会调用函数将 AOF 重写缓冲区的内容都写到新的 AOF 文件中
AOF优缺点
优势：
- AOF 持久化的方法提供了多种的同步频率，即便使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已
- AOF 文件使用 Redis 命令追加的形式来构造，所以，即便 Redis 只能向 AOF 文件写入命令的片段，使用 redis-check-aof 工具也很容易修正 AOF 文件
- AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，若是咱们不当心错用了 FLUSHALL 命令，在重写还没进行时，咱们能够手工将最后的 FLUSHALL 命令去掉，而后再使用 AOF 来恢复数据。
缺点：
- 对于具备相同数据的的 Redis，AOF 文件一般会比 RDF 文件体积更大
- 在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证
- AOF可能存在bug