众所周知，redis的强劲性很大程度是因为将数据存储在了内存中，这样的优点显而易见，读取速度快；但是缺点也比较明显，过分依赖、占用内存，当redis重启后，存储在内存中的数据就会丢失。这时候就需要掌握一门新的技巧--redis持久化。
redis持久化方式
- RDB方式
根据指定规则，定时将内存中的数据存储在硬盘上。
- AOF方式
每次执行命令后将命令本身记录在硬盘上。
下面我们来详细了解下这两种持久化方式。
RDB方式
保存方式：文件快照（dump.rdb 文件）。
什么情况下会保存快照呢？
1、根据配置规则进行自动快照。
- 保存快照的触发条件可以在配置文件中设置，两个重要的参数：M 时间，单位是 s，N 键的个数。例如：save 300 6 表示300秒内有6个键被修改则进行快照。
- 快照可以存在多个触发条件，多个条件之间的关系为 ‘或’。
2、用户执行 SAVE 或 BGSAVE 命令。
- 执行 SAVE 命令会同步保存快照，但是阻塞来自客户端的请求。
- 推荐使用 BGSAVE 命令，后台异步进行快照。
3、执行 FLUSHALL 命令。
- 执行 FLUSHALL 命令时，会清楚数据库中的所有数据，若存在快照触发保存条件，即使没达到条件的限制，也会保存快照。
4、执行复制时。
- 使用主从模式，复制初始化时会进行快照生成。
优缺点。
RDB文件是经过压缩的二进制格式，占用空间会小于内存中的数据大小；
redis 异常退出，会丢失最后一次快照以后更改的所有数据。
AOF方式
默认情况下 AOF 没有打开，可以通过 appendonly yes 命令来开启。AOF 会将 redis 执行的每一条命令都追加到硬盘中，显然会影响 redis 性能，综合考虑后使用。
保存方式：appendonly.aof 文件。
AOF 重写
- 可以通过配置文件的设置来达到重写 AOF 文件的目的。
- 手动执行 BGREWRITEAOF 命令来重写 AOF 文件。
注：由于操作系统的缓存机制问题，AOF 数据并没有真正的写入硬盘，而是记录在了系统的硬盘缓存中，然后系统默认每 30s 向硬盘同步一次。redis 中可以通过配置 appendfsync 参数来设置同步时机。
备注
- 不管是 RDB 快照重新生成，还是 AOF 文件的重写，只和内存中的数据有关，和之前生成的文件无关。
- redis 允许同时开启 RDB 和 AOF，同时启动后，redis重新启动会优先使用 AOF 文件来恢复数据。