redis相关总结-持久化

redis持久化

redis中持久化分为RDB和AOF

1. RDB

当前进程数据生成快照保存到硬盘,
触发RDB持久化过程分为手动触发和自动触发

1.1 手动触发

  1. save命令

    阻塞当前Redis服务器,直到RDB过程完成为止,对于内存 比较大的实例会造成长时间阻塞,线上环境不建议使用
    
  2. bgsave命令

    Redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束。阻塞只发生在fork阶段,一般时间很短
    

1.2 自动触发

1.使用save相关配置,如“save m n”。表示m秒内数据集存在n次修改 时,自动触发bgsave
2.从节点执行全量复制操作,主节点自动执行bgsave生产RDB文件并发送给从节点
3.执行debug reload命令重新加载Redis时,也会自动触发save操作
4.默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则 自动执行bgsave

1.3 总结

优点:

1.紧凑的二进制文件,代表redis在某个时间点的数据快照,适用于备份,全量复制。比如每6小时执行bgsave备份,并把RDB文件拷贝到远程系统或者文件系统中,用于灾难恢复
2.Redis加载RDB的恢复数据远远快于AOF

缺点:

1.RDB方式无法做到实时持久化/秒级持久化
2.bgsave每次运行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本高
3.RDB使用特定二进制格式保存。Redis演进版本中, 存在老版本Redis服务无法兼容新版RDB格式的问题

2. AOF (append only file)

以独立日志的方式记录每次写命令, 重启时再重新执行AOF文件中的命令达到恢复数据的目的
AOF的主要作用 是解决了数据持久化的实时性,目前已经是Redis持久化的主流方式

2.1 配置

开启AOF

appendonly yes,默认不开启

AOF文件名

appendfilename 默认是appendonly.aof

保存路径

dir

流程

1)所有的写入命令会追加到aof_buf(缓存)中
2)AOF缓冲区根据对应的策略向硬盘做同步操作
3)随着AOF文件越来越大,需要定期对AOF文件进行重写,达到压缩的目的
4)当Redis服务器重启时,可以加载AOF文件进行数据恢复

AOF缓冲区同步文件策略

always 命令写入aof_buf后, 调用系统fsync操作同步aof文件, fsync完成后线程返回,相当于是强制硬盘同步
everysec 命令写入aof_buf后, 调用系统write操作, write完成后线程返回。fsync同步文件操作由专门线程每秒调用一次
no 命令写入aof_buf后, 调用系统write操作, 不对aof文件做fsync同步, 同步硬盘操作由操作系统负责, 通常同步时间最长30秒

always每次写入都要同步AOF文件,影响reis性能
no 操作系统每次同步AOF文件不可控, 加大每次同步硬盘的数据量,提升了性能,但是数据安全性不可控

redis默认appendfsync默认配置是everysec

2.2 总结

1.AOF命令写入的内容是文本协议 
            >> 文本具有很好的兼容性
            >> 开启AOF后, 所有的写命令都包含追加操作,直接使用协议格式,避免了二次处理开销
            >> 文本具有可读性, 方便直接修改和处理
2.AOF把命令追加到aof_buf中, redis使用单线程响应命令,如果每次都强制刷硬盘同步,那redis性能直接取决于硬盘的负载
        默认采用everysec策略,达到了性能和安全性的平衡

参考: 《redis开发与运维》

坚持原创技术分享,您的支持将鼓励我继续创作!