持久化选项简介 P61
Redis 提供了两种不同的持久化方法来将数据存储到硬盘里面。
RDB(redis database)：可以将某一时刻的所有数据都写入硬盘里面。（保存的是数据本身）
AOF(append only file)：会在执行命令时，将被执行的写命令复制到硬盘里面。（保存的是数据的变更记录）
两种持久化方法既可以同时使用，又可以单独使用，在某些情况下甚至可以两种方法都不使用，具体选择哪种持久化方法需要根据数据以及应用来决定。
快照持久化 P62 配置选项 # 持久化触发条件：seconds 秒内至少有 changes 个键被更改 # save <seconds> <changes> # # 默认配置以下三个触发持久化的条件 # 【注】注释掉所有 save 的配置，就不会开启快照持久化 # # 900 秒(15 分钟)内至少有 1 个键被更改 # 300 秒（5 分钟）内至少有 10 个键被更改 # 60 秒（1 分钟）内至少有 10000 个键被更改 save 900 1 save 300 10 save 60 10000 # 如果快照持久化开启 # yes：后台持久化操作失败时，Redis 就会停止接受更新操作（默认 yes） # no ：后台持久化操作失败时，Redis 仍然可以继续正常工作 stop-writes-on-bgsave-error yes # 在进行镜像备份时，是否进行压缩 # yes：压缩，会有更多 cpu 消耗，时间会更长（默认 yes） # no ：不压缩，需要更多磁盘空间 rdbcompression yes # 数据库文件的文件名 dbfilename dump.rdb # 工作目录，数据库文件的位置 # AOF（append only file）也会在此目录创建 dir ./如果新的快照文件创建完成之前，Redis 、 系统或者硬件这三者之中的任意一个崩溃了，那么 Redis 将丢失最近一次成功创建快照之后写入的所有数据。快照持久化只适用于那些即使丢失一部分数据也不会造成问题的程序，而不接受数据损失的程序可以考虑使用 AOF 持久化。 P63
创建快照的方法 P63
客户端可以通过向 Redis 发送 BGSAVE 命令来主动创建快照。对于支持 BGSAVE 命令的平台（除了 Windows 平台）来说，由 fork 创建出的子进程负责将快照写入硬盘，父进程继续处理命令请求。
客户端可以通过向 Redis 发送 SAVE 命令来主动创建快照，接到 SAVE 命令的 Redis 服务器在快照创建完毕之前不会响应任何命令。
设置了 save 配置选项，那么当任意一个条件满足时， Redis 就会自动触发一次 BGSAVE 命令。
当 Redis 通过 SHUTDOWN 命令接收到关闭服务器的请求时，或者接收到标准 TERM 信号时，会执行一个 SAVE 命令，阻塞所有客户端，不再执行客户端发送的任何命令，并在 SAVE 命令执行完毕之后关闭服务器。
当一个 Redis 服务器连接另一个 Redis 服务器，并向对方发送 SYNC 命令来开始一次复制操作的时候，如果主服务器目前没有在执行 BGSAVE 操作，或者并非刚刚执行完 BGSAVE 操作，那么主服务器就会执行 BGSAVE 命令。
the master Redis server will start a BGSAVE operation if one isn’t already executing or recently completed.
斜体加粗的部分感觉有点难理解，第二个就已经包含在第一个条件里了，然后找到英文原文还有点懵。
不同场景下的使用 P64个人开发：主要考虑尽可能地降低快照持久化带来的资源消耗，只设置 save 900 1 这一条规则。 P64
对日志进行聚合计算：主要考虑 Redis 因为崩溃而未能成功创建新的快照，那么我们能承受丢失多长时间以内产生的新数据。还需要设计如何恢复被中断的聚合计算，可以记录每次处理的日志文件名及偏移量，恢复时按升序从记录处开始处理。 P64
大数据：当 Redis 存储的出具了达到即使 GB 时，执行 BGSAVE 可能会导致系统长时间地停顿，也可能引发系统大量地使用虚拟内存，从而导致 Redis 的性能降低至无法使用的程度。 可以考虑手动发送 BGSAVE 或者 SAVE 来进行持久化，避免自动执行而造成停顿。P65
RDB 的优点非常紧凑
适合用于灾难恢复
可以最大化 Redis 的性能
恢复大数据集时的速度比 AOF 的恢复速度要快
RDB 的缺点宕机时丢失数据可能较多
每次持久化时都要 fork() 一个子进程，当数据集比较庞大时可能非常耗时
AOF 持久化 P66 配置选项 # AOF 持久化是否开启 # yes：开启 AOF 持久化，Redis 在启动时会载入 AOF，而忽略快照持久化文件 # no ：不开启 AOF 持久化（默认不开启） appendonly no # AOF 文件名（默认为 appendonly.aof） appendfilename "appendonly.aof" # Redis 支持三种不同的回写模式 # always ：每次写操作都调用 fsync()，立刻写入 AOF 文件。非常慢但是很安全。 # everysec：每秒调用一次 fsync()。折衷方案。（默认为 everysec） # no ：不调用 fsync()，等待操作系统刷数据。很快。 # appendfsync always appendfsync everysec # appendfsync no # 如果有延迟问题就将该选项设置为 yes # 否则就保持 no，这是最安全的方式 no-appendfsync-on-rewrite no # 自动重写 AOF 文件，若百分比设置为 0，则表示禁用自动重写 AOF 文件 # 如果当前 AOF 文件大小以及比上次 AOF 文件大小大了 指定的百分比，则会重写 AOF 文件 # 同时需要指定 AOF 文件重写的最小大小，以避免百分比过小而频繁重写 AOF 文件 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb 重写 AOF 文件 P67