redis持久化方式有两种，分别是rdb和aof，本文将会详细介绍两种方式的具体实现与详解，并在合适场景使用哪种持久化方式给出明确的选择。
首先，搬运一下官方文档的解释。
翻译：Redis 提供了多种不同级别的持久化方式：
· RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
· AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
· Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
· 你甚至可以关闭持久化功能，让数据只在服务器运行时存在。
官方文档明确给出两种方式是以什么形式来保证redis持久化，rdb就是时间点快照，aof是把redis所有写操作的命令进行记录，两种方式各有利弊。
RDB：
Redis通过创建快照来获得存储在内存里面的数据在某个时间节点上的副本。
主要是有2中方式，save（同步），bgsave（异步）
rdbSave 函数负责将内存中的数据库数据以 RDB 格式保存到磁盘中， 如果 RDB 文件已存在， 那么新的 RDB 文件将替换已有的 RDB 文件。
在保存 RDB 文件期间， 主进程会被阻塞， 直到保存完成为止。
SAVE 和 BGSAVE 两个命令都会调用 rdbSave 函数，但它们调用的方式各有不同：
SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。
BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。因为 rdbSave在子进程被调用，所以 Redis 服务器在 BGSAVE 执行期间仍然可以继续处理客户端的请求。
两种方式区别save的优势是不消耗额外内存，缺点是阻塞客户端命令，客户端执行命令会有时变慢几毫秒。bgsave需要fork消耗额外的内存但是不阻塞客户端命令。
当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作：
Redis 调用 fork() ，同时拥有父进程和子进程。
子进程将数据集写入到一个临时 RDB 文件中。
当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。
这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。
这里的save可以换成bgsave 三种方式都可以也可以多加几种判定条件。这个数值是根据服务端的测压结果，只调整这个数值调整到一个平均应用qps最高值。
AOF：
AOF持久化将被执行的写命令写到AOF文件的末尾，以达到记录数据的目的。Redis只要从头到尾重新执行一次AOF所有的命令就可以恢复数据
耗时、耗性能：通过bgsave命令进行持久化的的时候，需要fork一个子进程，如果数据量很大的话，需要的内存也会相应的变大，内存的占用会导致Redis性能降低。
不可控、丢失数据：举个例子，上一次创建快照是3:00开始创建并创建成功。如果Redis在4:00开始创建新的快照，如果系统在未完成创建快照之前崩溃，3:00-4:00写入的数据将会丢失；如果系统在快照创建完成之后崩溃，那么4:00之后，创建快照的过程中的数据将会丢失。
aof有三种策略
always：每条Redis写命令都同步写入硬盘。
everysec：每秒执行一次同步，将多个命令写入硬盘。
no：由操作系统决定何时同步。
三种策略的优缺点，always，IO开销较大，一般的SATA盘只有几百TPS，但是不丢失数据，everysec，只丢一秒内的数据。io开销会少很多。no不需要我们关心，但是数据丢失是不可控的。
AOF的实现方式：
AOF 持久化功能的实现可以分为命令追加（append）、文件写入、文件同步（sync）三个步骤。
如果客户端向服务端发送一条命令 SET KEY VALUE后，redis把这句话追加在aof_buf，这就是aof实现原理。
那么问题来了，redis执行set 命令，主线程不能去完成追加操作，如果fork的话，和rdb一样了。这里redis有一个事件循环（loop），这个循环中的文件事件负责接收客户端的命令请求， 以及向客户端发送命令回复， 而时间事件则负责执行像 serverCron 函数这样需要定时运行的函数。因为服务器在处理文件事件时可能会执行写命令， 使得一些内容被追加到 aof_buf 缓冲区里面， 所以在服务器每次结束一个事件循环之前， 它都会调用 flushAppendOnlyFile 函数， 考虑是否需要将 aof_buf 缓冲区中的内容写入和保存到 AOF 文件里面， 这个过程可以用以下伪代码表示：
flushAppendOnlyFile 函数的行为由服务器配置的 appendfsync 选项的值来决定， 各个不同值产生的行为也就是刚才介绍的三种方式。如果用户没有主动为 appendfsync 选项设置值， 那么 appendfsync 选项的默认值为 everysec
总结：
如果拿redis当缓存数据，可以接受数据丢失，建议关闭所有持久化方式。
如果可以接受十几分钟或更多的数据丢失，选择rdb对Redis的性能更加有利
如果只能接受秒级别的数据丢失，应该选择AOF
如果是集群环境，我们都会配置主从环境，slave的存在既可以实现数据的热备，也可以进行读写分离分担Redis读请求，以及在master宕掉后继续提供服务。在这种情况下，一种可行的做法是：master：完全关闭持久化，这样可以让master的性能达到最好slave：关闭快照持久化，开启AOF（如果对数据安全要求不高，开启快照持久化关闭AOF也可以），并定时对持久化文件进行备份（如备份到其他文件夹，并标记好备份的时间）；然后关闭AOF的自动重写，然后添加定时任务，在每天Redis闲时（如凌晨12点）调用bgrewriteaof。
