长久化介绍
redis 提供了两种形式形式进行数据的长久化（将数据存储到硬盘中）；第一种称为快照（snapshotting）RDB，它将某一时刻的所有数据都写入硬盘，所以快照是一次全量备份，并且存储的数据模式是二进制序列化模式；另一种形式是只追加文件（append-only file）AOF, 它会在执行命令时将命令复制一份到硬盘中，AOF 在长期运行中会变的十分宏大，数据库重启加载 AOF 日志将会很慢；
redis 将数据长久化的次要起因就是重用数据，或者避免系统故障，备份数据；
两种形式的长久化是能够同时存在的，然而当 Redis 重启时，AOF 文件会被优先用于重建数据
工作原理
快照工作原理
redis 的快照必须要求文件 IO 操作，单线程的 redis 进行多余的 IO 操作会影响服务器的性能，所以 redis 采纳 COW（copy on write）机制实现快照的长久化；
- 首先 redis 进行会 fork 一个子过程，此时就存在父子过程；
- 父过程负责进行批改操作，内存继续减少；而子过程数据不做任何变动；
- 子过程将霎时数据写入磁盘的 rdb 文件
AOF 工作原理
AOF 日志寄存了 redis 指令程序序列；所以只有从新执行 AOF 文件蕴含所有的命令就能够实现 AOF 文件记录的所有数据；
罕用配置
RDB 配置
默认文件
dbfilename dump.rdb
dir ./
redis 会将数据默认 dump 至 dump.rdb 文件中；咱们能够通过配置批改 dump 的频率；
在 900 秒 (15 分钟) 之后，如果至多有 1 个 key 发生变化，则 dump 内存快照。
save 900 1
在 300 秒 (5 分钟) 之后，如果至多有 10 个 key 发生变化，则 dump 内存快照。
save 300 10
在 60 秒 (1 分钟) 之后，如果至多有 10000 个 key 发生变化，则 dump 内存快照
save 60 10000
如果想要禁用快照性能，正文掉如上配置，开启 save "" 配置
save “”
save 900 1
save 300 10
save 60 10000
手动备份
save 命令是阻塞命令 , 当服务器接管到 save 命令之后就会开始拍摄快照，在此期间不会解决其余申请;
bgsave 命令也是立刻拍摄快照, 非阻塞命令，而是 fork 一个子线程进行备份快照;
毛病
- 每隔一段时间进行一次长久化，如果 redis 解体，可能会导致局部数据失落问题；
- RDB 应用
fork()子过程进行数据的长久化，如果数据量大，可能破费的工夫较长，redis 会造成显著的卡顿几秒景象； - 很好的备份成果，容易进行数据恢复；
长处
- 相比 AOF，在数据量比拟大的状况下，RDB 的启动速度更快；
- RDB 应用
fork()子过程进行数据的长久化，自身不会有多余的 IO 操作；
AOF 配置
启用 AOF
appendonly yes
默认文件
appendfilename “appendonly.aof”
dir ./
fsync
如果 redis 产生宕机事件，有可能没来的及数据写入磁盘；此时 redis AOF 的 fsync 策略可能保障 redis 放弃高性能，和尽可能的缩小数据失落；默认就是应用 1s 执行一次同步；
每次有数据批改产生时都会写入 AOF 文件。
appendfsync always
每秒钟同步一次，该策略为 AOF 的缺省策略。
appendfsync everysec
从不同步。高效然而数据不会被长久化。
appendfsync no
AOF 重写
AOF 日志文件会随着 redis 运行越来越宏大，Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身；也能够应用配置文件进行主动瘦身；
以后 AOF 文件大小是上次日志重写失去 AOF 文件大小的二倍时，主动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
以后 AOF 文件启动新的日志重写过程的最小值，防止刚刚启动 Reids 时因为文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb
要禁用主动的日志重写性能，咱们能够把百分比设置为 0
auto-aof-rewrite-percentage 0
长处
- 应用 fsync 每秒一次同步，数据完整性较高；
- redis 如果产生宕机，反对应用 redis-check-aof 工具修复损坏的 AOF 文件
毛病
- AOF 文件的大小个别会比 RDB 文件大
- AOF 在运行效率上往往会慢于 RDB
关注公众号：常识追寻者，获取一线大厂面经