前言
1 | 缓存:数据可以丢,追求的是急速 |
1 | 存储层: |
1 | 管道: |
- redis的写时复制
redis RDB
简介
1
RDB是redis进行持久化的一种方式,是把当前内存中的数据集快照写入磁盘,也就是snapshot快照(数据库中所有键值对数据),恢复时是将快照文件直接读到内存里。
持久化触发方式
自动触发
1
2# redis.conf 配置文件中的SNAPSHOTTING下
save m n :表示m秒内数据集存在n次修改时,自动触发bgsave。手动触发
1
21、save:该命令会阻塞当前Redis服务器,执行save命令期间,Redis不能处理其他命令,直到RDB过程完成为止。所以出现了bgsave。
2、bgsave:该命令执行后Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。具体操作是Redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束。阻塞只发生在fork阶段,一般时间很短。
恢复数据
1
2
3将备份文件(dump.rdb)移动到redis安装目录并启动服务即可,redis会自动加载文件数据至内存。
注意:Redis 服务器在载入RDB文件期间,会一直处于阻塞状态,直到载入工作完成为止。
获取redis的安装目录可以使用 config get dir 命令优缺点
1
2
3
41、不支持拉链,只有一个dump.rdb。且备份时占用内存(因为Redis 在备份时会独立创建一个子进程,将数据写入到一个临时文件(此时内存中的数据是原来的两倍哦),最后再将临时文件替换之前的备份文件。)。
2、想对容易丢失数据,时间点直接的窗口数据容易丢失。
3、优点类似java中的序列化,恢复的速度相对快。
4、适合大规模数据恢复
redis AOF
简介
1
2Redis 默认不开启。它的出现是为了弥补RDB的不足(数据的不一致性),所以它采用日志的形式来记录每个写操作,并追加到文件中。
Redis重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。配置
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
161、修改redis.conf,将appendonly 的no改为yes
appendonly yes
2、指定本地数据库文件名,默认值为 appendonly.aof
appendfilename "appendonly.aof"
3、指定更新日志条件
# appendfsync always
appendfsync everysec
# appendfsync no
# 解说:
always:同步持久化,每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好(慢,安全)
everysec:出厂默认推荐,每秒异步记录一次(默认值)
no:不同步
4、配置重写触发机制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 解说:当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为2-3G,64M太小了。数据恢复
1
2
3
4
5正常情况下,将appendonly.aof文件拷贝到redis的安装目录的bin目录下,重启redis服务即可。
但在实际开发中,可能因为某些原因导致appendonly.aof文件格式异常,从而导致数据还原失败,可以通过命令redis-check-aof --fix appendonly.aof 进行修复。
# 注意:
redis中,RDB和AOF可同时开启,但是如果开启了AOF后只会用AOF恢复。
4.0版本后,AOF包含RDB全量,增加记录新的写操作。优缺点
1
2优点:数据的完整性和一致性更高
缺点:因为AOF记录的内容多,文件会越来越大,数据恢复也会越来越慢。