https://redis.io/docs/manual/persistence/
可以使用RDB (Redis Database)或AOF (Append Only File)，也可以都用，也可以不持久化
RDB (Redis Database)
RDB 持久性以指定的时间间隔执行数据集的时间点快照。RDB保存到磁盘的文件叫dump.rdb，恢复时将rdb文件读到内存
- 优点：
- 适合大规模的数据恢复
- 按照业务定时备份
- 对数据完整性和一致性要求不高
- RDB 文件在内存中的加载速度要比 AOF 快得多
- 缺点：
- 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失从当前至最近一次快照期间的数据，
- 内存数据的全量同步，如果数据量太大会导致I/0严重影响服务器性能
- RDB依赖于主进程的fork，在更大的数据集中，这可能会导致服务请求的瞬间延迟。
- 修复文件 ： redis-check-rdb dump.rdb
- 触发快照条件
- 配置文件中默认的快照配置
- 手动save/bgsave命令
- 执行flushall/flushdb命令也会产生dump.rdb文件
- 执行shutdown且没有设置开启AOF持久化
- 主从复制时，主节点自动触发
- 禁用方法
- 动态所有停止RDB保存规则的方法：redis-cli config set save “”
- 配置文件 save “”
- 优化配置——>配置文件SNAPSHOTTING模块
| 配置项 | 说明 |
|---|---|
| save seconds changes | Redis7 默认save 3600 1 300 100 60 10000 |
| dbfilename | rdb文件名称 |
| dir | rdb文件保存路径 |
| stop-writes-on-bgsave-error | 默认yes;如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制这种不一致，那在快照写入失败时，也能确保redis继续接受新的写请求 |
| rdbcompression | 默认yes;对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能 |
| rdbchecksum | 默认yes;在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能 |
| rdb-del-sync-files | 在没有持久性的情况下删除复制中使用的RDB文件启用。默认情况下no，此选项是禁用的。 |
AOF (Append Only File)
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)只许追加文件但不可以改写文件，重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。保存的文件是appendonly.aof
默认情况不开启aof
- 持久化流程
- Client作为命令的来源，会有多个源头以及源源不断的请求命令。
- 在这些命令到达Redis Server 以后并不是直接写入AOF文件，会将其这些命令先放入AOF缓存中进行保存。这里的AOF缓冲区实际上是内存中的一片区域，存在的目的是当这些命令达到一定量以后再写入磁盘，避免频繁的磁盘IO操作。
- AOF缓冲会根据AOF缓冲区同步文件的三种写回策略将命令写入磁盘上的AOF文件。
- 随着写入AOF内容的增加为避免文件膨胀，会根据规则进行命令的合并(又称AOF重写)，从而起到AOF文件压缩的目的。
- 当Redis Server 服务器重启的时候会从AOF文件载入数据。
- 三种写回策略 appendfsync always/everysec/no
| 配置项 | 写回时机 | 优点 | 缺点 |
|---|---|---|---|
| always | 同步写回 | 可靠性高，数据基本不丢失 | 每个写命令都要落盘，性能影响较大 |
| everysec | 每秒写回,每个写命令执行完,只是先把日志写到AOF文件的内存缓冲区,每隔1秒把缓冲区中的内容写入磁盘 | 性能适中 | 宕机时丢失1秒内的数据 |
| no | 操作系统控制的写回,每个写命令执行完,只是先把日志写到AOF文件的内存缓冲区,由操作系统决定何时将缓冲区内容写回磁盘 | 性能好 | 宕机时丢失数据较多 |
- 优点： 更好的保护数据不丢失 、性能高、可做紧急恢复
- 缺点：
- 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
- aof运行效率要慢于rdb,每秒同步策略效率较好，不同步效率和rdb相同
- 修复文件 redis-check-aof --fix appendonly.aof.1.incr.aof
- Redis7保存生成的文件
- 基本文件 appendonly.aof.1.base.rdb
- 增量文件 appendonly.aof.1.incr.aof appendonly.aof.2.incr.aof
- 清单文件 appendonly.aof.mainfest
- AOF重写机制
由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。
为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的峰值时，Redis就会自动启动AOF文件的内容压缩，
只保留可以恢复数据的最小指令集或者可以手动使用命令 bgrewriteaof 来重新。
AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。
通过redis.conf 中的 auto-aof-rewrite-percentage ：默认值100， auto-aof-rewrite-min-size默认64mb;默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
重写原理
- 在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
- 与此同时，主进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
- 当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中
- 当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中
- 重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似
- 优化配置——>配置文件配置文件APPEND ONLY MODE模块
| 配置项 | 说明 |
|---|---|
| appendonly | 开始aof，默认不开启 |
| appenddirname “” | aof文件保存路径，最终路径是dir + appenddirname |
| appendfilename | aof文件名称 |
| appendfsync | 同步方式，默认everysec |
| no-appendfsync-on-write | aof重写期间是否同步no-appendfsync-on-write no |
| auto-aof-rewrite-percentage | 重写触发配置auto-aof-rewrite-percentage 100 |
| auto-aof-rewrite-min-size | 文件重写策略auto-aof-rewrite-min-size 64mb |
RDB和AOF
同时开启时，重启时只会加载aof文件，不会加载rdb文件
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。作者建议不要只是有AOF，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，留着rdb作为一个万一的手段。
- 开启混合方式设置
设置aof-use-rdb-preamble的值为 yes yes表示开启，设置为no表示禁用
开启aof - RDB+AOF的混合方式,结合了RDB和AOF的优点，既能快速加载又能避免丢失过多的数据。RDB镜像做全量持久化，AOF做增量持久化
先使用RDB进行快照存储，然后使用AOF持久化记录所有的写操作，当重写策略满足或手动触发重写的时候，将最新的数据存储为新的RDB记录。这样，重启服务的时候会从RDB和AOF两部分恢复数据，既保证了数据完整性，又提高了恢复数据的性能。简单来说：混合持久化方式产生的文件一部分是RDB格式，一部分是AOF格式(AOF包括了RDB头部+AOF混写)。
No persistence
- 禁用rdb
- 配置文件 save “”
- 禁用rdb后，仍可用命令save、bgsave生成rdb文件
- 禁用aof
- 配置文件 appendonly no
- 禁用aof后，仍可用命令bgrewriteaof生成aof文件
274
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
