Redis持久化
camhan 2019-12-06
redis提供了两种持久化的方法来将数据以二进制的方式存储到硬盘，一种为在某一时刻生成快照的RDB持久化，另一种为将写入命令追加到aof的持久化文件的持久化
RDB
在 Redis 运行时，RDB 程序将当前内存中的数据库快照保存到磁盘文件中，在 Redis 重启动
时，RDB 程序可以通过载入 RDB 文件来还原数据库的状态。RDB文件非常适合备份以及用于灾难恢复
rdb持久化的过程
- Redis 会fork 一个子进程。这样就有了一个子进程和一个父过程。
- 子进程开始将数据集写入临时RDB文件。
- 当子进程完成新的RDB文件的写入后，它将替换旧的RDB文件。
rdb分为手动触发和自动触发，自动触发需要在配置文件中定义
自动触发
rdb持久化默认在配置文件中开启的
vim /etc/redis/6379.conf
此配置表示在15分钟内至少修改一次，或者在5分钟内至少修改十次，或者在1分钟内修改10000次会触发rdb操作
是否对快照数据进行压缩存储
rdbcompression yes
是否使用CRC64算法进行数据校验，如果开启那么将增加10的性能消耗
rdbchecksum yes
指定生成的文件名
dbfilename dump.rdb
指定文件存放的目录
dir /var/lib/redis/6379
手动触发
rdb的手动触发需要手动调用SAVE或BGSAVE命令
- SAVE命令：在当前进程执行，阻塞当前Redis服务器，直到RDB过程完成为止，在主进程阻塞期间，服务器不能处理客户端的任何请求。
- BGSAVE命令： 当前进程会 fork 出一个子进程，父进程继续处理请求，子进程开始将数据写入临时RDB文件 ，并在保存完成之后向主进程发送信号，通知保存已完成。因为在子进程被调用，所以 Redis 服务器在BGSAVE 执行期间仍然可以继续处理客户端的请求
AOF
AOF持久性会记录服务器接收的每个写入操作，这些操作将在服务器启动时再次运行，以重建原始数据集。使用与Redis协议本身相同的格式记录命令，并且采用仅追加方式。当日志太大时，Redis可以在后台重写日志。AOF的主要作用是解决了数据持久化的实时性
AOF持久化流程
- 所有的写入命令会追加到aof_buf（缓冲区）中。
- AOF缓冲区根据对应的策略向硬盘做同步操作。
- 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
- 当Redis服务器重启时，可以加载AOF文件进行数据恢复
AOF持久化策略
- appendfsync always：每次将新命令附加到AOF时。虽然很慢，但是数据不会丢失
- appendfsync everysec：每秒钟保存一次。如果发生灾难，可能会丢失1秒的数据。
- appendfsync no：不主动进行同步操作，由操作系统来完成。更快，更不安全的方法。通常，Linux使用此配置每30秒刷新一次数据，但这取决于内核的精确调整。
默认采用everysec模式
AOF重写
当AOF太大时，Redis会简单地从头开始将其重写到临时文件中。重写不是通过读取旧的文件，而是由Redis fork一个子进程直接访问内存中的数据，将其转换为写命令同步到新的aof文件，因此Redis可以创建更小的AOF文件，并且在写入新的AOF时不需要读取磁盘。
重写终止后，临时文件将被fsync同步在磁盘上，并覆盖旧的AOF文件。
当aof被重写的过程中又有新数据写入怎么办？这可能会导致数据不一致
新写入的数据会放到旧的aof文件里，同时也会追加到aof的重写缓冲区中，最后替换掉旧的aof文件
AOF配置持久化
vim /etc/redis/6379.conf 
是否在后台aof文件重写期间调用fsync，默认为no，表示调用
no-appendfsync-on-rewrite no
当前aof文件增长量超过上次afo文件大小的100%时，则触发rewrite，如果为0，则禁用自动触发重写
auto-aof-rewrite-percentage 100
aof文件重写最小的文件大小，低于这个值将不会触发重写操作
auto-aof-rewrite-min-size 64mb
当子进程重写AOF文件时，每生成32 MB的数据，文件就会把数据落盘，防止单次文件数据过大造成阻塞
aof-rewrite-incremental-fsync yes
使用rdb和aof混合持久化方式，会将aof重写操作时的数据状态保存为rdb格式，而重写之后的redis命令会继续追加到rdb数据之后
aof-use-rdb-preamble yes
rdb与aof同时存在时，优先使用aof进行数据恢复
欢迎关注个人公号“没有故事的陈师傅”
