复述,持久化方案的示例分析

保存,在命令行执行保存命令,将以同步的方式创建RDB文件保存快照,会阻塞服务器的主进程,生产环境中不要用

bgsave,在命令行执行bgsave命令,将通过叉一个子进程以异步的方式创建RDB文件保存快照,除了叉时有阻塞,子进程在创建RDB文件时,主进程可继续处理请求

<>强自动触发

在复述。会议中配置保存mn定时触发,如节省900 1表示在900年代内至少存在一次更新就触发
主从复制时,如果从节点执行全量复制操作,主节点自动执行bgsave生成RDB文件并发送给从节点
执行调试重载命令重新加载复述时
执行关闭且没有开启AOF持久化
redis.conf中RDB持久化配置

, #只要满足下列条件之一,则会执行bgsave命令
节省900 1 #在900年代内存在至少一次写操作
保存300年10
保存60 10000
#禁用RBD持久化,可在最后加保存,“

#当备份进程出错时主进程是否停止写入操作
stop-writes-on-bgsave-error是的
#是否压缩RDB文件推荐不相对于硬盘成本cpu资源更贵
rdbcompression没有

<强> AOF持久化

AOF (Append-Only-File)持久化即记录所有变更数据库状态的指令,以附加的形式追加保存到AOF文件中。在服务器下次启动时,就可以通过载入和执行AOF文件中保存的命令,来还原服务器关闭前的数据库状态。

复述。conf中AOF持久化配置如下

# 默认关闭AOF，若要开启将no改为yes
appendonly no

# append文件的名字
appendfilename "appendonly.aof"

# 每隔一秒将缓存区内容写入文件 默认开启的写入方式
appendfsync everysec

# 当AOF文件大小的增长率大于该配置项时自动开启重写（这里指超过原大小的100%）。
auto-aof-rewrite-percentage 100

# 当AOF文件大小大于该配置项时自动开启重写
auto-aof-rewrite-min-size 64mb

AOF持久化的实现包括3个步骤:

• 命令追加：将命令追加到AOF缓冲区
  

• 文件写入：缓冲区内容写到AOF文件
  

• 文件保存：AOF文件保存到磁盘
  

其中后两步的频率通过appendfsync来配置，appendfsync的选项包括

• always， 每执行一个命令就保存一次，安全性最高，最多只丢失一个命令的数据，但是性能也最低（频繁的磁盘IO）
  

• everysec，每一秒保存一次，推荐使用，在安全性与性能之间折中，最多丢失一秒的数据
  

• no， 依赖操作系统来执行（一般大概30s一次的样子），安全性最低，性能最高，丢失操作系统最后一次对AOF文件触发SAVE操作之后的数据
  

AOF通过保存命令来持久化，随着时间的推移，AOF文件会越来越大，Redis通过AOF文件重写来解决AOF文件不断增大的问题（可以减少文件的磁盘占有量，加快数据恢复的速度），原理如下：

调用fork，创建一个子进程

子进程读取当前数据库的状态来“重写”一个新的AOF文件（这里虽然叫“重写”，但实际并没有对旧文件进行任何读取，而是根据数据库的当前状态来形成指令）

主进程持续将新的变动同时写到AOF重写缓冲区与原来的AOF缓冲区中

主进程获取到子进程重写AOF完成的信号，调用信号处理函数将AOF重写缓冲区内容写入新的AOF文件中，并对新文件进行重命名，原子地覆盖原有AOF文件，完成新旧文件的替换

AOF的重写也分为手动触发与自动触发

• 手动触发： 直接调用bgrewriteaof命令

• 自动触发： 根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。其中auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积，默认为64MB。auto-aof-rewrite-percentage表示当前AOF文件大小（aof_current_size）和上一次重写后AOF文件大小（aof_base_size）的比值。自动触发时机为 aof_current_size> auto-aof-rewrite-min-size,, (aof_current_size - aof_base_size)/aof_base_size>=auto-aof-rewrite-percentage

  复述,持久化方案的示例分析