标签：工作   sum   l命令   后台   db文件   行数据   ima   size   目的   

Redis持久化

目前，Redis支持两种持久化方式：AOF持久化和RDB持久化。AOF持久化方式会将每次执行的命令及时保存到硬盘中；而RDB持久化方式会根据指定的规则“定时”将内存中的数据保存到硬盘中。AOF持久化方式的实时性更好，也就是当进程意外退出时，丢失的数据更少。

持久化机制AOF

AOF持久化保存服务器执行的所有写操作命令到单独的日志文件中，在服务器重启时，通过加载日志文件中的这些命令并执行来恢复数据，这个日志文件就是AOF文件，Redis将会以Redis协议格式来保存AOF文件中的所有命令，新命令会被追加到文件的结尾。在服务器的后台，AOF文件还会被重写，使得AOF的文件体积不会大于保存数据集状态所需的实际大小。

AOF持久化配置

#通过修改配置文件redis.conf中的appendonly参数开启
appendonly yes
#AOF文件的位置设置
dir 目录
#修改AOF文件名称
appendfilename "appendonly.aof"

Redis为AOF缓冲区的同步提供了多种策略，策略涉及操作系统的write(文件写入)和fsync(文件同步)函数。为了提高文件的写入效率，当用户调用write函数将数据写入文件中时，操作系统会将这些数据暂存到一个内存缓存区中，当这个缓存区被填满或者超过了指定时限后，才会将缓存区的数据写入硬盘中，这样做既提高了效率，有吧奥正了安全性。

AOF触发方式

• 手动触发：执行BGREWRITEAOF命令触发AOF文件重写。
• 自动触发：自动触发AOF文件重写是通过设置Redis配置文件中的auto-aof-rewrite-percentage和auto-aof-rewrite-min-size参数的值，以及aof_current_size和aof_base_size状态来确定何时触发的。

AOF文件重写

随着服务器运行时间的增加，AOF文件的内容数据会越来越大，文件占据的内存也会变大。

定期重写AOF文件，以达到压缩的目的。

• AOF文件重写功能会丢弃过期的数据，也就是过期的数据不会写入AOF文件中。
• AOF文件重写功能会丢弃无效的命令，无效的命令不会写入AOF文件中。
• AOF文件重写功能可以将多条命令合并为一条命令，然后写入AOF文件中。

AOF文件处理

1. 创建一个不带网络连接的客户端，用于执行AOF文件中的写命令。
2. 读取AOF文件中的数据，分析并提取出AOF文件所保存的一条写命令。
3. 使用客户端知行杯读出来的写命令。
4. 重复执行步骤2，3直到AOF文件中的所有命令读取完毕，并成功执行为止。

如果在Redis服务器启动加载AOF文件时，发现AOF文件被损坏了，那么服务器会拒绝加载这个AOF文件，以此来确保数据的一致性不被损坏。而AOF损坏的原因可能是程序对AOF文件进行写入与同步时，服务器出现停机故障。

修复方法：

• 及时备份现有的AOF文件。

• #利用Redis自带的redis-check-aof程序，对原来的A文件进行修复
  $ redis-check-aof -fix
  

• 使用diff-u来对比原始AOF文件和修复后的AOF文件，找出两个文件的不同之处。

• 修复AOF文件之后，重启Redis服务器重新加载，进行数据恢复。

AOF持久化优劣之分

优点：

• 使用AOF持久化会让Redis持久化更长
• 兼容性比较好
• 支持后台重写
• AOF文件易于读取和加载

缺点：

• AOF文件的体积会随着时间逐渐变大，加载速度变慢
• 使用的fsync策略，会使AOF文件恢复数据的速度可能会慢于RDB
• 因为AOF的个别命令，可能会导致在加载时失败，从而无法进行数据恢复

持久化机制RDB

在指定的时间间隔内，RDB持久化可以生成数据集的时间点快照。就是可以通过快照来实现RDB持久化。在指定的时间间隔内，Redis会自动将内存中的所有数据生成一份副本并存储在硬盘上，这个过程就是"快照"。

快照发生条件

• 根据Redis配置文件redis.conf中的配置自动进行快照处理。

  ? Redis配置文件redis.conf中的默认设置

#表示在900秒内有1个或1个以上的键被修改就会进行快照处理
save 900 1
#表示在300秒内有10个或10个以上的键被修改就会进行快照处理
save 300 10
#表示在60秒内有1000个或1000个以上的键被修改就会进行快照处理
save 60 1000

• 用户在客户端执行SAVE或BGSAVE命令时会触发快照。
• 如果用户定义了自动快照条件，则执行FLUSHALL命令也会触发快照。
• 如果用户为Redis设置了主从复制模式，从节点执行全量复制操作，则主节点会执行BGSAVE命令，将生产的RDB文件发送给从节点完成快照操作。

快照的实现过程

1. Redis调用执行fork函数复制一份当前进程(父进程)的副本(子进程)，也就是同时拥有父进程和子进程。
2. 父进程与子进程各自分工，父进程继续处理来自客户端的命令请求，而子进程则将内存中的数据写到硬盘上的一个临时RDB文件中。
3. 当子进程把所有数据写完后，也就表示快照生成完毕，此时旧的RDB文件将会被这个临时RDB文件替换，这个旧的RDB文件也会被删除。这个过程就是快照的实现过程。

默认情况下，Redis将数据库快照保存在名为dump.rdb的文件中，这个文件被称为RDB文件，它是一个经过压缩的二进制文件。Redis服务器会自动对RDB文件进行压缩。在Redis配置文件redis.conf中，默认开启压缩。

#默认为开启压缩
rdbcompression yes
#通过命令修改
CONFIG SET rdbcompression no

加载

• 如果在Redis配置文件中开启了AOF持久化，那么启动服务器的时候会优先加载AOF来还原数据库的状态。
• 如果没有开启AOF持久化,则优先加载RDB。

加载RDB文件的工作有rdb.c/rdbLoad函数完成。

RDB持久化配置

save m n:表示在时间m内被修改的键的个数大于n时，会触发BGSAVE命令的执行。
stop-writes-on-bgsave-error yes：当执行BGSAVE命令出现错误时，Redis是否终止执行写命令。
rdbcompression yes：是否开启RDB压缩文件，默认为yes表示开启，不开启为no
rdbchecksum：是否开启RDB文件的校验，在服务器进行RDB文件的写入与读取时会用到
dbfilename dump.rdb：用于设置RDB文件名，可以通过命令来修改它
CONFIG SET dbfilename RDB 文件名

RDB持久化的优劣

优点：

• RDB文件是一个经过压缩的二进制文件，文件紧凑，体积较小，非常适用于数据库备份
• RDB持久化适用于灾难恢复，而且恢复数据时的速度要快于AOF持久化
• Redis采用RDB持久化可以很大程度的提升性能

缺点：

• 在服务器出现故障时，如果没有触发RDB快照执行，那么它可能会丢失大量数据。
• 当数据量非常庞大时，保存RDB文件的时候，服务器会启动一个子进程来完成相关的保存操作。
• RDB文件存在兼容性问题，老版本的Redis不支持新版本的RDB文件。

AOF持久化与RDB持久化抉择

建议同时使用AOF持久化和RDB持久化，以便最大限度的保证数据的持久化与安全性。

Redis持久化

标签：工作   sum   l命令   后台   db文件   行数据   ima   size   目的   

原文地址：https://www.cnblogs.com/striver20/p/13780488.html