redis开发与运维笔记（4）

1、持久化

1、RDB。RDB持久化是把当前进程数据生成快照保存到硬盘的过程， 分为手动触发和自动触发

（1）触发机制

• 手动触发：save命令。阻塞当前Redis服务器，直到RDB过程完成。线上环境不建议使用
• 手动触发：bgsave命令。Redis进程执行fork操作创建子进程，RDB持久化由子进程负责。阻塞只发生在fork阶段，时间很短。
• 自动触发：使用save相关配置：“save m n”，表示m秒内发生了n次数据修改，自动触发bgsave。
• 自动触发：从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件，发给从节点
• 自动触发：执行debuge reload命令重新加载Redis时，会自动触发save操作
• 自动触发：执行shutdown命令时，如果没有开启AOF功能，会自动触发bgsave

（2）流程说明

• 监测是否存在正在执行的子进程，如RDB/AOF进程，如果存在直接返回
• 父进程创建子进程，fork过程中父进程会阻塞，通过info stats 命令查看latest_fork_usec选项查看最近一次fork的耗时，单位为微秒
• 父进程fork完成后，返回“Backgroung saving started”，不在阻塞父进程，开始响应其他命令
• 子进程创建RDB文件，根据父进程内存生成快照，完成后对原有文件进行原子替换
• 子进程发送信号给父进程表示完成，父进程更新统计信息

（3）RDB文件的处理

• RDB文件保存在dir配置的路径下，名字为dbfilename配置。可以通过命令动态修改 config set dir；config set dbfilename
• Redis采用默认的LZF算法对生成的RDB文件进行压缩，默认开启，虽然压缩过程会消耗cpu，但是可以大幅降低压缩后的文件体积，方便保存到磁盘和通过网络传输到从节点，线上建议开启
• 如果Redis加载损坏的RDB文件时拒绝启动，可以使用Redis提供的redis-check-dump工具检测RDB文件生成对应的错误报告

 （4）RDB的优缺点

• 优点：RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的快照。适用于备份、全量复制等场景。
• 优点：Redis加载RDB恢复数据的速度远远快于AOF的方式
• 缺点：RDB没有办法做到实时持久化
• 缺点：REB文件使用特定的二进制格式保存，存在老版本的服务器无法兼容新版RDB格式的问题。

2、AOF。以独立日志的形式记录每次写命令。重启时再重新执行AOF文件中的命令，达到恢复数据的目的

（1）配置

• 开启AOF功能需要设置配置： appendonly yes， 默认不开启。 AOF文件名通过appendfilename配置设置， 默认文件名是appendonly.aof。 保存路径同RDB持久化方式一致， 通过dir配置指定。
• 工作流程操作： 命令写入（append） 、 文件同步（sync） 、 文件重写（rewrite） 、 重启加载（load）

（2）命令写入缓存

• 写入的命令内容直接是文本协议格式，会把内容追加到缓冲区。文本协议具有很好的兼容性
• 先写入缓冲区，避免了每次的命令直接追加到硬盘，提高性能。

（3）文件同步到磁盘，由参数appendfsync控制。设置不同值含义不同

• always。命令写入缓冲区之后，调用系统fsync命令同步到磁盘，fsync完成后线程返回
• everysec。命令写入缓冲区之后，调用系统的write操作，write操作完成后线程返回。fsync同步操作由专门的线程每秒调用一次
• no。命令写入缓冲区之后，调用系统的write操作，不进行fsync操作。同步到硬盘由操作系统负责，通常同步周期最长30秒
• write操作会触发延迟写（delayed write）机制，Linux内核提供页缓冲区提高硬盘IO性能。write写入系统缓冲区之后直接返回。同步硬盘操作依赖于操作系统调度机制
• fsync操作，针对单个文件操作，强制磁盘同步。将阻塞直到写入硬盘完成后返回。
• always配置太耗费性能，只能支持大约几百tps并发写入；no配置，每次系统不同周期不可控；everysec，建议采用的同步策略，也是默认配置

 （4）AOF文件重写。把Redis进程内的数据转化成写命令同步更新到新的AOF文件，AOF重新降低了占用空间，更小的AOF文件可以更快的被Redis加载

• 重写之后的AOF文件变小的原因 ：
  进程内已经超时的数据不在写入文件
  旧的AOF文件中含有无效命令，新的AOF文件只保留最终数据的写入命令
  多条写命令可以合并成一个