Redis持久化
- RDB （Redis DataBase）
- AOF（Append only file）
持久化的两种方式介绍
RDB
可以在指定的时间间隔内生成数据集的快照（point-in-time snapshot）
优点：速度快，适合于走备份，主从复制基于持久该种方式实现，生成的是一个紧凑压缩的二进制文件，代表的是某个时间点上的数据快照。并且在恢复数据的过程中远远快于AOF的方式
缺点：会有数据的丢失，没有办法做到实时的持久化（秒级持久化）因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，执行频繁成本过高
配置参数说明
### 以守护进行模式启动
daemonize yes
### 绑定主机ip地址
bind 192.168.8.105
### 监听端口
port 6379
### pid文件存放位置
pidfile /opt/redis_cluster/redis_6379/pid/redis_6379.pid
### log文件存放位置
logfile /opt/redis_cluster/redis_6379/logs/redis_6379.log
### 设置数据库的数量
databases 16
### 指定本地持久化文件的文件名,默认为dump.rdb
dbfilename redis_6379.rdb
## 满足以下条件则数据持久化
save 900 1 # 900秒内有一个更改
save 300 10 # 300秒内有十个更改
save 60 10000 # 60秒内有一万个更改
## shutdown 后数据会自动持久化
## kill pkill kill -15 优雅的关闭 如果使用 kill -9 有可能会导致数据的格式错乱
### 本地数据库的目录
dir /data/redis_cluster/redis_6379
触发机制
- 手动触发
- 自动触发
手动触发
- save
save 会阻塞当前Redis服务器知道RDB过程完成为止，对于内存比较大的实例会造成长时间的阻塞，很少用，已废弃
- bgsave
Redis进程执行fork操作创建子进程RDB持久化过程由子进程负责，完成后自动结束，阻塞只发生在fork阶段，在Redis内部所有涉及RDB的操作都采用bgsave的方式
AOF
1. 所有写入命令会追加到aof_buf(缓冲区)
2. AOF缓冲区根据对应的策略向硬盘中做同步操作
3. 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的
4. 当Redis服务重启时，可以加载AOF文件进行数据操作
配置
开启AOF功能需要
配置：
appendonly yes # 默认不开启
配置文件名：
appendonly.aof # 默认文件名
详细的配置文件
appendonly yes # 是否打开aof日志功能
appendfsync always # 每一个命令，都立即同步到aof中
appedfsync everysec # 美妙写一次
appendfync no # 写入工作交给操作系统，由操作系统判断缓冲区的大小，统一写到aof
两者的区别
- rdb:基于快照的持久化，速度更快，一般用作备份，主从复制也是依赖于rdb持久化功能
- aof:以追加的方式记录redis操作日志文件。可以最大程度的保证redis数据安全，类似于mysql的binlog
- 该两种方式可以同时并存，且会优先读取aof
网友评论