redis相关总结-持久化

redis持久化

redis中持久化分为RDB和AOF

1. RDB

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

1.1 手动触发

save命令

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

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开发与运维》

Contents