redis的持久化策略

红太狼 2022-05-27 06:11 124阅读 0赞

redis的持久化方式有俩种，持久化策略有4种：

*  RDB（数据快照模式），定期存储，保存的是数据本身，存储文件是紧凑的
 *  AOF（追加模式），每次修改数据时，同步到硬盘(写操作日志)，保存的是数据的变更记录
 *  如果只希望数据保存在内存中的话，俩种策略都可以关闭
 *  也可以同时开启俩种策略，当Redis重启时，AOF文件会用于重建原始数据

# RDB #

RDB定时备份内存中的数据集。服务器启动的时候，可以从 RDB 文件中恢复数据集。

优点

*  存储的文件是紧凑的
 *  适合用于备份，方便恢复不同版本的数据
 *  适合于容灾恢复，备份文件可以在其他服务器恢复
 *  最大化了Redis的性能，备份的时候启动的是子线程，父进程不需要执行IO操作
 *  数据保存比AOF要快

缺点

*  如果Redis因为没有正确关闭而停止工作是，到上个保存点之间的数据将会丢失
 *  由于需要经常fork子线程来进行备份操作，如果数据量很大的话，fork比较耗时，如果cpu性能不够，服务器可能是卡顿。属于数据量大的时候，一个服务器不要部署多个Redis服务。

创建快照有以下5种形式：

1.  客户端发送`BGSAVE`指令，服务端会fork一条子线程将快照写入磁盘
2.  客户端发送`SAVE`指令，服务端在主线程进行写入动作。一般不常使用，一般在内存不够去执行`BGSVAE`的时候才用
3.  设置了`SAVE`配置项，如`SAVE 300 100`，那么当“300秒内有100次写入”时，Redus会自动触发`BGSAVE`命令。如果有多个配置项，任意一个满足，都会触发备份
4.  Redis通过`SHUTDOWN`命令接收到关闭服务器的请求、或者`TERM`信号时，会执行`SAVE`命令，这时候会阻塞所有客户端，不在执行客户端发送的任何命令
5.  当一个Redis服务器连接另外一个Redis服务器，并像对方发送`SYNC`命令开始一次复制操作时，如果主服务器目前没有在执行`BGSAVE`操作，或者主服务器刚刚执行完，那么主服务器就会执行`GBSAVE`

# AOF(append only file) #

AOF记录服务器的所有写操作。在服务器重新启动的时候，会把所有的写操作重新执行  
一遍，从而实现数据备份。当写操作集过大（比原有的数据集还大），Redis 会重写写操作集。

优点  
\- 使用AOF模式更加的灵活，因为可以有不同的`fsync`策略  
\- AOF是一个日志追加文件，所有不需要定位，就算断电也没有损坏问题，哪怕文件末尾是一个写到一半的命令，redus-check-aof工具也可以很轻易的修复  
\- 当AOF文件很大的，Redis会自动在后台进行重写。重写是决对安全的，因为Redis是继续往旧的文件里面追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦创建完成，Redis就会切换到新文件，开始往新文件进行追加操作  
\- AOF包含一个又一个的操作命令，易于理解和解析

缺点

*  对于同样的数据集，AOF文件通常要大于RDB文件
 *  AOF可能比RDB要慢，这取决于`fsync`策略。通常fsync设置为每秒一次的话性能仍然很高，如果关闭sfync，即使在很高的负载下也和RDB一样快。不过，即使在很大的写负载情况下，RDB还是能提供很好的最大延迟保证
 *  AOF1通过递增的方式更新数据，而RDB快照是从头开始创建，RDB会更健壮和稳定（所以适用于备份），