Redis持久化

redis持久化方式

(1) RDB：Redis DataBase(快照/内存快照)：把当前进程数据生成快照保存到磁盘的过程

(2) AOF

触动RDB的方式

(1) 手动触发

① Save命令：阻塞当前redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用

② bgsave命令：Redisk进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短

(2) 自动触发发生的情况

① Redis.conf中配置save m n，即在m秒内有n次修改，自动触发bgsave生成rdb文件

② 主从复制时，从节点要从主节点进行全量复制时会触发bgsave,生成当时的快照发给从节点

③ 执行debug reload命令重新加载redis时也会触发

④ 默认情况下执行shutdown命令时，如果没有开启aof持久化，也会触发

(3) Redis.conf中配置RDB

① Redis中默认的周期性配置：

1) 格式：save <seconds><changes>

2) 默认设置：

save 900 1 表示900秒内有一条KEY发生变化就生成一次快照
Save 300 10
Save 60 10000

② 关闭RDB快照功能

1) Save “”

③ 文件名称

1) Dbfilename XXX

④ 文件保存路径

1) Dir XX/XX/XX

⑤ 如果持久化出错，主进程是否停止写入

1) Stop-writes-on-bgsave-error yes

⑥ 是否压缩

1) Rdbcompression yes

⑦ 导入时是否检查

1) Rdbchecksum yes

实例场景

(1) 生产环境为redis开辟的内存区域比较大，那么数据从内存同步到硬盘的时间就比较长，而实际情况是这段时间redis服务一般都会收到数据写操作请求。如何保证数据的一致性？

① RDB的核心思路是Copy-on-Write,来保证进行快照操作的这段时间需要压缩写入到磁盘上的数据在内存中不会发生变化。在正常的快照操作中，一方面Redis主进程会fork一个新的快照进程来做这个事，保证了redis服务不会停止对客户端包括请求在内的任何响应。另一方面这段时间发生的数据变化会以副本的方式存放在另一个新的内存区域中，待快照结束后才会同步到原来的内存区域

(2) 在进行快照操作的这段时间，如果服务发生崩溃怎么办？

① 很简单在没有将数据写入磁盘前，这次快照操作都不算成功。如果出现的服务崩溃的现象将以上一次完成的Rdb快照文件作为恢复内存的参考。也就是说，在快照操作过程中不能影响上一次的备份数据。Redis服务会在磁盘上创建一个临时文件进行操作，待操作成功后才会用这个临时文件替换上一次的备份

RDB的优缺点

(1) 优点

① RDB文件是某个时间节点的快照，默认使用LZM算法进行压缩，压缩后的文件体积远远小于内存大小，适用于备份、全量复制等场景

② Redis加载RDB文件恢复数据要远远快于AOF方式.

(2) 缺点：

① RDB实时性不够，无法做到秒级的持久化

② 每次调用bgsave都需要fork子进程，fork子进程属于重量级操作，频繁执行成本高

③ RDB文件是二进制的，没有可读性，AOF文件在了解其结构的情况下可以手动修改或者补全

④ 版本兼容RDB的问题

AOF持久化

(1) 什么时写后日志？

① AOF采用写后日志，即先写内存，后写日志

(2) 为什么采用写后日志

① Redis要求高性能，采用写后日志有两个好处

1) 避免额外的检查开销

2) 不会阻塞当前的写操作

② 存在的风险

1) 如果命令执行完成，写日志之前宕机了，会丢失数据

2) 主线程写磁盘压力大，导致写盘满，阻塞后续操作

(3) 如何实现AOF

① AOF日志记录redis的写命令，步骤分为：

1) 命令追加(append):当AOF持久化功能打开时，服务器在执行完一个写命令，会以协议格式将被执行的写命令追加到服务器的aof_buf缓冲区中

2) 文件写入和同步：关于何时将aof_buf缓冲区中的内容，Redis提供了三种写回策略

配置项	写回时机	优点	缺点
Always	同步写回	可靠性高	每个命令都要落盘，性能影响较大
Everysec	每秒写回	性能适中	宕机时丢失一秒的数据
No	操作系统控制的写回	性能好	宕机时丢失数据较多

(4) Redis.conf中配置AOF:默认情况下Redis是没有开启AOF的

① 开启AOF持久化

1) Appendonly no

② AOF持久化的文件名，默认是appendonly.aof

1) Appendfilename “appendonly.aof”

③ AOF文件的保存位置和RDB的相同，都是通过dir参数设置的

1) Dir ./

④ 同步策略

1) Appendfsync always

2) Appendfsync everysec（默认）

3) Appendfsync no

⑤ aof重写期间是否同步

1) No-appendfsync-on-rewrite no

⑥ 重写触发配置

1) Auto-aof-rewrite-percentage 100

2) Auto-aof-rewrite-min-size 64mb

⑦ 加载aof出错如何处理

1) Aof-load-truncated yes

⑧ 文件重写策略

1) Aof-rewrite-incremental-fsync yes