持久化的作用
Redis所以数据保存在内存中,对数据的更新将异步保存到磁盘中。
持久化方式
主流数据库的持久化方式
快照比如MySQL的Dump,Redis的RDB
写日志比如 MySQL的binlog,Hbase的HLog,Redis的AOF
RDB
RDB是Redis内存到硬盘的快照,用于持久化,文件采用二进制文件保存在硬盘中。
触发机制
save(同步) client端发送save命令,则生成一个RDB文件,因为是同步命令,在数据量比较大的时候可能会造成阻塞。如果存在老的RDB文件,新替换老文件。复杂度为O(n)
bgsave(异步) bgsave的过程中,redis可以正常响应客户端,文件的保存策略和save一样。一般fork的时间很短,在fork的时候也会阻塞。
save vs bgsave
自动配置,满足条件就会被执行
dbfilename经常使用dump-${port}.rdb
dir选择一个合适的路径
bgsave-error遇到错误停止 rdbcompression rdb压缩,rdbchecksum 校验和 这三个选yes
rdb的触发机制
- 全量复制,主从复制
- debug reload, debug级别的重启
- shutdown
缺点
- 耗时,耗性能
- 不可控,容易丢失数据
AOF
根据日志原理,日志宕机后可以通过aof恢复。
三种策略
always 写命令刷新到缓冲区,缓冲区always fsync到磁盘中
everysec everysec
no 操作系统决定什么时候刷
如set 多次,他会合并成一条,set 最终值,这样可以减少磁盘占用和加快恢复速度。
AOF使用命令(bgrewriteaof命令)或者满足配置条件都会重写文件
bgrewriteaof命令 , 类似于bgsave,也是fork一个子进程
auto-aof-rewrite-min-size aof文件重写需要的尺寸
auto-aof-rewrite-percentage aof文件增长率
aof_current_size aof当前尺寸
aof_base_siez aof上次启动和重写的尺寸
取舍和选择
RDB适合备份数据,AOF设置everysec 每秒刷盘,只丢失一秒数据。
常见问题
Fork操作如果卡主,会阻塞redis,与内存量息息相关,内存越大耗时越长。
CPU开销,RDB和AOF文件生成属于CPU密集型,部署应注意不和CPU密集型部署在一起。
内存开销,fork的时候linux copy-on-write机制,如果没有什么写入,消耗并不大。
硬盘开销,aof和rdb文件写入,可以结合iostat,iotop分析,不用和硬盘高负载服务部署在一起(存储服务、消息队列等)no-appendfsync-on-rewrite = yes (重写期间不追加,减少内存开销)。