Redis持久化原理

1
2
redis持久化分为两种 RDB,AOF，默认持久化为RDB。在官方推荐使用中推荐两种都使用，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
信息介绍
Redis持久化默认为RDB(Redis DataBase)
RDB是将数据写入一个临时文件，持久化结束后用这个临时文件替换上次持久化的文件，达到数据恢复
优点：使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能
缺点：RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候
配置（在redis.conf中进行查看）
设置持久化文件名称
，dbfilename dump.rdb(filename)
设置持久化文件路径
dir ./(文件路径)
设置同步时间段(或者关系)
save 900 1	--	15分钟之内至少有一个key进行修改进行快照
save 300 10 --	5分钟之内至少有10个key进行修改进行快照
持久化过程
1，当同步条件满足时，Reids用fork函数复制一份当前进程的副本.
2，父进程继续处理客户端传来的命令，而子进程开始将内存的中数据写入磁盘中的临时文件。
3，当子进程写入所有数据后用临时文件替换旧的RDB文件
注：
手动快照：
redis -h 127.0.0.1 -p port save | bgsave
save	--	占用主进程更新会阻塞其他请求
bgsave	--	使用fork函数复制进行子进程快照操作
注：
1，使用fork函数进行子进程快照时，复制的子进程与主进程占用资源一致内存()，如果资源不满足会启用虚拟内存，性能非常差。
2，RDB也可以进行压缩(默认开启)，配置项rdbcomproession
来进行控制
压缩
advantage(优点)：减少内存存储空间。
shortcoming(缺点)：消耗CPU资源。
不压缩
advantage：不消耗CPU资源。
shortcoming：占用存储空间多

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
信息介绍
AOF持久化默认是禁用的，需要手动配置
AOF持久化是将执行过的指令记录下来，数据恢复时按照从前到后的顺序进行执行来实现数据恢复
advantage(优点)：更高的保持的数据完整性，当日志有问题时可用redis-check-aof
来进行修复
修复日志命令：redis-check-aof --fix ./appendonly.aof
shortcoming(缺点)：AOF文件比RDB文件大，且恢复速度慢。
配置（在redis.conf中进行查看）
AOF配置开关
appendonly no --> yes
设置AOF日志文件
appendfilename "filename.aof"
同步方式配置
一旦输入命令，立即同步到磁盘，保证了完全的持久化，但是速度慢，不推荐
appendfsync always
每秒进行同步
appendfsync everysec
不自动同步(服务器资源有空闲的时候更新)，性能最好，持久化没有保障
appendfsync on
文件重写：
造成原因：随着客户端命令的增多，AOF日志文件也逐步增大，所以会进行rewrite
retrite 相关配置
当前AOF文件超过上次重写文件的百分之几进行重写，如果没有启动过则以启动时的文件大小为准
auto-aof-rewrite-percentage 100
允许重写的文件最小
auto-aof-rewrite-min-size 64mb
持久化过程
将快照内容以命令的形式追加到AOF文件中，所有随着追加AOF文件会越来越大，如果想修改可以修改文件内容（信息未同步之前可修改）

1
2
持久化过程中 同时有appendonly.aof 和dump.rab 优先使用appendonly.aof,rdb的数据不会恢复内存中