Redis的数据持久化

共计 1519 个字符，预计需要花费 4 分钟才能阅读完成。

主从同步数据选择的方式 —– 数据持久化操作  Redis 在正常关闭时触发 rdb 操作

rdb 持久化是指在客户端输入 save 和 bgsave 或者达到配置文件自动保存快照条件时，将 redis 在内存的数

生成快照保存在 dump.rdb 文件中

save 会阻塞 redis 主进程，直到 rdb 文件创建完毕

bgsave 命令的原理

1.redis 主进程 fork 一个和组进程完全一样的子进程进行持久化, 验证方法，执行 bgsave 后另一个终端 ps -ef | grep redis

2. 子进程将内存中的数据写入到一个临时 RDB 文件中，主进程不进行 IO 操作，确保主进程极高的性能，这个就是解释为什么要 fork 子进程 (redis 单线程)

3. 当子进程完成 rdb 文件时，redis 会使用新的 rdb 文件替代旧的文件，之后删除旧的文件

在备份数据时，当进程的内存空间为 G 时，无法正常的分配内存，可以修改系统参数

/etc/sysctl.conf

vm.overcommit_memory=1

退出执行 sysctl -p

0: 请求分配的虚拟内存和系统当前空闲内存 +swap 内存进行比较

1: 直接放行

2: 比较进程已经占用的内存 + 请求分配的内存与系统的空闲内存 +swap 内存

flushall，清空 redis 内存中的数据，此时就会异常宕机，再次重启 redis 时，会再次读取 rdb 文件，相当于 flushall 的操作无意义，所以会触发 rdb 机制。

生产上一般的选择，redis4.0 以后才提供 rdb 和 aof 重新，当两个持久化方式都存在时优先使用 aof

append-only file(AOF)– 数据实时追加的方式把操作及记录保存在磁盘中，会影响 redis 使用的效率

为了压缩 AOF 的持久化文件，Redis 提供了 bgrewriteaof 命令。

收到此命令后 Redis 将使用与快照类似的方式将内存中的数据以二进制的数据方式保存到临时文件中，其他的 aof 日志还是以命令字符串的方式保存，

这样会较少 aof 文件的大小

最后替换原来的文件，以此来实现控制 AOF 文件的增长

appendonlya.aof 文件重写，就是把一些命令相互抵消，或者命令整合达到 aof 文件瘦身的效果。

重写会 fork 一个和主进程完全一样的子进程，基于内存中的数据，以 rdb 文件存储格式替换旧的 aof 文件

appendonly no（默认关闭状态）

开启的话在 /usr/local/redis/bin 目录下生成 appendonly.aof 文件

no-appendfsync-on-rewrite yes #在日志重写时，命令只是将其放在缓冲区里。

auto-aof-rewrite-percentage 100 #当前 AOF 文件大小是上次日志重写得到 AOF 文件大小的二倍时，自动启动新的日志重写过程。

auto-aof-rewrite-min-size 5GB, 最少 #当前 AOF 文件启动新的日志重写过程的最小值，避免刚刚启动 Reids 时由于文件尺寸较小导致频繁的重写

为什么出现 aof 持久化

rdb 触发机制：shutdown；save 时间可能较长；bgsave;  如果没有这些人工的操作，宕机时丢失数据较多

aof 触发机制: 指定更新日志条件

appendfsync  no：表示等操作系统进行数据缓存同步到磁盘 (效率快，持久化没保证)，不建议

always: 同步持久化，每次发生数据变化时，立即记录到磁盘 (效率慢，安全)

everysec：表示每秒同步一次 (m 默认值，很快，但可能会丢失一秒的数据)

没有子进程，开启 aof 会有一个缓冲区 1M，主进程把数据缓存在缓存区在存储在 aof 文件中

rdb 基于内存中的数据持久化的，二进制文件，较少

aof 基于命令字符串文件较大，把 set 命令保存，再次恢复时再次执行命令

：