Redis data persistent

概念

利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。

两种方法： RDB和AOF：

• RDB-将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据
• AOF将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程

RDB

启动方式

save

• 执行一次即保存一次
• 保存文件：dump.rdb，可在redis.conf中通过dbfilename dump-6379.rdb修改
• 单线程插入save，执行完以后再执行后续redis命令；有可能阻塞当前Redis服务
• 其他参数

• rdbcompression yes/no：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF 压缩
• rdbchecksum yes/no：设置是否进行RDB文件格式校验，默认为yes

bgsave

• 启动后台保存操作，但不是立即执行
• 推荐方式
• stop-writes-on-bgsave-error yes/no：：后台存储过程中如果出现错误现象，是否停止保存操作，默认开启 新进程：10352 会提示完成

save文件配置

• save second changes：限定时间范围内key的变化数量达到指定数量即进行持久化
• 对数据产生影响的才有可能执行
• 执行的是bgsave操作
• 根据业务情况设置，设置不当有可能灾难后果

配置10秒之内发生两个数据更改操作便RDB

[root@worker-02 conf]# vim redis-6379.conf
port 6379
daemonize yes
dir /root/redis-6.0.6/data
logfile "6379.log"
protected-mode no
dbfilename dump-6379.rdb
rdbcompression yes
rdbchecksum yes
save 10 2

其他

• RDB是全量复制
• debug reload：重启并RDB
• shutdown save：关闭前bgsave

RDB优缺点

• 优点  RDB是一个紧凑压缩的二进制文件，存储效率较高  RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景  RDB恢复数据的速度要比AOF快很多  应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复。
• 缺点  无法做到实时持久化，具有较大的可能性丢失数据  bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能并多使用内存  Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现早期各版本服务之间数据格式无法兼容现象，现在的文件格式版本9，兼容低版本https://github.com/sripathikrishnan/redis-rdb-tools/blob/master/docs/RDB_Version_History.textile

AOF

• AOF：(append only file)持久化，可实时持久化
• 以独立日志的方式记录每次写命令，恢复时再重新执行AOF文件中命令
• 解决了数据持久化的实时性
• 目前是Redis持久化的主流方式
• AOF写命令刷新缓存区

策略

• always ：每次数据改变即记录到aof文件，性能低，零误差
• everysec：每秒一次，宕机丢失最多1s内容
• no：交给操作系统控制，对Redis来说整体不可控

配置方法

conf文件配置

1. appendonly yes|no 是否开启
2. appendfsync always|everysec|no 配置策略
3. 文件默认：appendonly.aof，文件名修改appendfilename filename

[root@worker-02 conf]# vim redis-6379.conf

port 6379 daemonize yes dir /root/redis-6.0.6/data logfile “6379.log” protected-mode no dbfilename dump-6379.rdb rdbcompression yes rdbchecksum yes save 10 2 databases 24 appendonly yes appendfsync always

重启后Redis增加文件appendonly.aof，初始化大小为0

[root@worker-02 data]# ll total 12 -rw-r–r–. 1 root root 4867 Nov 10 22:54 6379.log -rw-r–r–. 1 root root 0 Nov 10 22:54 appendonly.aof -rw-r–r–. 1 root root 111 Nov 10 00:56 dump-6379.rdb

增加key

192.168.21.12:6379> ping PONG 192.168.21.12:6379> SELECT 1 OK 192.168.21.12:6379[1]> set ccie 8466 OK 192.168.21.12:6379[1]> set name dewals

文件大小改变

[root@worker-02 data]# ll total 16 -rw-r–r–. 1 root root 5217 Nov 10 22:56 6379.log -rw-r–r–. 1 root root 91 Nov 10 22:56 appendonly.aof -rw-r–r–. 1 root root 119 Nov 10 22:56 dump-6379.rdb

查看文件内容

[root@worker-02 data]# cat appendonly.aof *2 $6 SELECT $1 1 *3 $3 set $4 ccie $4 8466 *3 $3 set $4 name $6 dewals

AOF缓冲区同步文件策略

由参数appendfsync控制，系统调用write和fsync 说明：

• write操作-会触发延迟写（delayed write）机制，Linux在内核提供页缓冲区用来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调度机制，列如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
• fsync-针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞直到 写入硬盘完成后返回，保证了数据持久化。

除了write、fsync、Linx还提供了sync、fdatasync操作

AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

AOF重写规则

• 进程内已超时的数据不再写入文件
• 忽略无效指令，重写时使用进程内数据直接生成，AOF文件只保留最终数据的写入命令
• 对同一数据的多条写命令合并为一条命令

AOF重写方式

• 手动重写

• bgrewriteaof

测试：

1. 配置conf文件
2. 重启Redis Server，可以看到data目录下的新appendonly.aof文件，初始化大小为0

[root@worker-02 data]# kill -s 9 23662 [root@worker-02 data]# ../src/redis-server ../conf/redis-6379.conf [root@worker-02 data]# ll total 20 -rw-r–r–. 1 root root 9235 Nov 11 17:27 6379.log -rw-r--r--. 1 root root 0 Nov 11 17:27 appendonly-6379.aof -rw-r–r–. 1 root root 132 Nov 11 17:18 appendonly.aof -rw-r–r–. 1 root root 92 Nov 11 17:18 dump-6379.rdb

3. 在Client写数据

192.168.21.12:6379> ping PONG 192.168.21.12:6379> lpush list01 apple (integer) 1 192.168.21.12:6379> rpush list01 boy (integer) 2 192.168.21.12:6379> rpush list01 cisco (integer) 3 192.168.21.12:6379> rpush list01 dango (integer) 4 192.168.21.12:6379> set name anne OK 192.168.21.12:6379> set name binny OK 192.168.21.12:6379> set name candy OK 192.168.21.12:6379> set name binary OK

4. 观察.aof文件变化

[root@worker-02 data]# ll total 24 -rw-r–r–. 1 root root 9235 Nov 11 17:27 6379.log -rw-r–r–. 1 root root 274 Nov 11 17:33 appendonly-6379.aof -rw-r–r–. 1 root root 132 Nov 11 17:18 appendonly.aof -rw-r–r–. 1 root root 92 Nov 11 17:18 dump-6379.rdb

5. 运行手动重写

192.168.21.12:6379> BGREWRITEAOF Background append only file rewriting started

6. 再次查看.aof文件变化

[root@worker-02 data]# ll total 24 -rw-r–r–. 1 root root 10807 Nov 12 01:02 6379.log -rw-r–r–. 1 root root 158 Nov 12 01:02 appendonly-6379.aof -rw-r–r–. 1 root root 132 Nov 11 17:18 appendonly.aof -rw-r–r–. 1 root root 92 Nov 11 17:18 dump-6379.rdb

7. .aof

REDIS0009ú redis-ver^E6.0.6ú redis-bitsÀ@ú^EctimeÂ&Å<8d>aú^Hused-mem¸F^M^@ú^Laof-preambleÀ^Aþ^@û^B^@^@^Dname^Ecandy^N^Flist01^A%%^@^@^@^]^@^@^@^D^@^@^Eapple^G^Cboy^E^Ecisco^G^Edangoÿÿ:<87>Ò¡ÿ«<9c>¥*2^M $6^M SELECT^M $1^M 0^M *3^M $3^M set^M $4^M name^M $7^M binnary^M

• 自动重写

• 方法1：auto-aof-rewrite-min-size size 上面的size相对比的是info persistence中的aof_current_size参数，当aof_current_size到达auto-aof-rewrite-min-size 时，进行自动重写

• 方法2：auto-aof-rewrite-percentage percentage 其中的percentage对比为info persistence中的aof_base_size参数，触发条件

AOF工作流程

最终生成新的.aof文件，删除临时aof文件。

RDB vs AOF

RDB与AOF的选择

• 数据非常敏感，AOF，即便是everysec，数据丢失0-1s
• 现阶段数据有效，RDB
• 追求快速恢复，如灾难恢复，RDB
• 可以同时使用