Redis-持久化（RDB、AOF）

Redis 持久化-RDB

• Redis的读写都是在内存中的，所以它的性能较高，但在内存中的数据会随着服务器的重启而丢失，为了保存数据不丢失，我们需要将内存中的数据存储到磁盘，以便Redis重启时能够从磁盘中恢复原有的数据，而整个过程就叫做Redis持久化

持久化的几种方式

Redis 持久化拥有以下三种方式

• 快照方式（RDB， Redis DataBase），将某一个时刻的内存数据，以二进制的方式写入磁盘
• 文件追加方式（AOF， Append Only File），记录所有的操作命令，并以文本的形式追加到文件中
• 混合持久化方式，Redis4.0之后新增的方式，混合持久化是结合了RDB和AOF的优点，在写入的时候，先把当前的数据以RDB的形式写入文件的开头，在将后续的操作命令以AOF的格式存入文件，这样既能保证Redis重启时的速度，又能减低数据丢失的风险

RDB简介

• RDB（Redis DataBase）是将某一时刻的内存快照，以二进制的方式写入到磁盘的过程

持久化的触发

• RDB的持久触发方案有两类：一类是手动触发，另一类是自动触发

手动触发

• 手动触发持久化的操作有两个：save和bgsve，它们主要区别体现在：是否阻塞Redis主线程的执行

1. save命令，在客户端中执行save命令，就会触发Redis的持久化，但同时也是使Redis处于阻塞状态，直到RDB持久化完成，才会响应其他客户端发来的命令，所以在生产环境中一定要慎用
2. bgsave 命令 bgsave（background save）既后台保存的意思， 它和 save 命令最大的区别就是 bgsave 会 fork() 一个子进程来执行持久化，整个过程中只有在 fork() 子进程时有短暂的阻塞，当子进程被创建之后，Redis 的主进程就可以响应其他客户端的请求了，相对于整个流程都阻塞的 save 命令来说，显然 bgsave 命令更适合我们使用。

配置说明

• sudo cat redis.conf

# RDB 保存的条件
save 900 1
save 300 10
save 60 10000

# bgsave 失败之后，是否停止持久化数据到磁盘，yes 表示停止持久化，no 表示忽略错误继续写文件。
stop-writes-on-bgsave-error yes

# RDB 文件压缩
rdbcompression yes

# 写入文件和读取文件时是否开启 RDB 文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。
rdbchecksum yes

# RDB 文件名
dbfilename dump.rdb

# RDB 文件目录（不唯一）
dir /var/lib/redis

配置查询

• Redis中可以使用命令查询当前配置参数，查询命令的格式为：config get,例如，想要获取RDB文件的存储名称设置，可以使用config get dbfilename

127.0.0.1:6379> config get dbfilename
1) "dbfilename"
2) "dump.rdb"
127.0.0.1:6379> 

RDB优缺点

RDB优点

• RDB 的内容为二进制的数据，占用内存更小，更紧凑，更适合做为备份文件；
• RDB 对灾难恢复非常有用，它是一个紧凑的文件，可以更快的传输到远程服务器进行 Redis 服务恢复；
• RDB 可以更大程度的提高 Redis 的运行速度，因为每次持久化时 Redis 主进程都会 fork() 一个子进程，进行数据持久化到磁盘，Redis 主进程并不会执行磁盘 I/O 等操作；

RDB缺点

• 因为 RDB 只能保存某个时间间隔的数据，如果中途 Redis 服务被意外终止了，则会丢失一段时间内的 Redis 数据；
• RDB 需要经常 fork() 才能使用子进程将其持久化在磁盘上。如果数据集很大，fork() 可能很耗时，并且如果数据集很大且 CPU 性能不佳，则可能导致 Redis 停止为客户端服务几毫秒甚至一秒钟。

模拟当数据丢失之后，使用从机的dump.rdb来进行数据恢复

• RDB文件在生产环境中都是自动触发机制，所以会造成一定时间上的数据丢失，当然你也可以通过修改redis.conf文件中rdb模式的保存机制时间
• 脑海战术（当在生产环境时，如果你的主服务器宕机了，那么就是导致文件丢失，当文件丢失我们可以怎么解决呢，可以通过从机找到rbd相对应的存储文件，复制一份让他恢复到主机当中）
  
  
  

Redis持久化-AOF

• 使用RDB持久化有一个风险，它可能会造成最新的数据丢失的风险。应为RDB的持久化有一定的时间间隔，在这个时间段如果Redis服务意外终止的话，就会造成最新的数据全部丢失

可能会操作Redis服务意外终止的条件

• 安装Redis的机器停止运行，蓝屏或者系统崩溃
• 安装Redis的机器出现电源故障，例如突然断电等情况
• 使用kill -9 redis_pid等

当出现以上等情况，我们将采用redis为我们提供的另一种持久化的方案-AOF

简介

• AOF（Append Only File）中文是附加到文件，顾名思义AOF可以把Redis每个键值对操作都记录到文件（appendonly.aof）中

持久化查询和设置

1. 查询AOF的启动状态

config get appendonly

• 其中第一行为AOF的文件名称，而第二行就是AOF的启动状态，yes表示启动，no表示未启动

2.开启AOF持久化

• Redis默认是关闭AOF持久化的，想要开启AOF持久化，有以下两种方式
  • 通过命令行的方式
  • 通过修改配置文件的方式（redis,conf）

1. 命令行启动AOF

config set appendonly yes

• 命令行启动AOF的缺点：命令行启动优点是无需重启Redis服务，缺点是如果重启了Redis服务的话，则之前使用的命令行设置的配置就会失效

2. 配置文件启动AOF

• Redis的配置文件在它的根路径下的redis.conf文件中，获取redis的根目录可以使用命令:

config get dir

• 只需要在配置文件中设置appendonly yes即可，默认appendonly no表示关闭AOF持久化。配置文件启动AOF的优缺点：修改配置文件的缺点是每次修改配置文件都要重启redis服务才能生效，优点是无论重启多少次redis服务，配置文件中设置的配置信息都不会失效

持久化触发

• AOF持久化开启之后，只要满足一定条件，就会触发AOF持久化操作。AOF的触发条件分为两种：自动触发和手动触发

自动触发

有两种情况可以自动触发AOF持久化，分别是：满足AOF设置的策略触发和满足AOF重写触发。AOF持久化策略主要分为三种：

• always : 每条redis操作命令都会写入磁盘，最多丢失一秒的数据
• everysec ： 每秒钟写入一次磁盘，最多丢失一条数据
• no ： 不设置写入磁盘的规则，根据当前操作系统来决定何时写入磁盘，Linux默认30秒写入一次数据至磁盘

# 开启每秒写入一次的持久化策略
appendfsync everysec

手动触发

在客户端执行bgrewriteaof命令就可以手动触发AOF持久化

AOF文件重写

AOF是通过记录Redis的执行命令来持久化（保存）数据的，所以随着时间的流逝AOF文件会越来越多，这样不仅增加了服务器的存储压力，也会造成Redis重启速度变慢，为了解决这个问题，Redis提供了AOF重写操作

什么是AOF重写？

• AOF重写指的是它直接读取Redis服务器当前的状态，并压缩保存为AOF文件。例如，我们增加一个计数器，并对它做99次修改，如果不做AOF重写的话，那么持久化文件中就会有100条记录执行命令的信息 ，而AOF重写之后，之后记录一条此计数器最终的结果信息，这样就去除了所有的无效信息

AOF重写实现

触发AOF文件重写，要满足两个条件，这两个条件也是配置在Redis配置文件中，它们分别是

• auto-aof-rewrite-min-size: 允许AOF重写的最小文件容器，默认是64mb
• auto-aof-rewrite-percentage : AOF文件重写的大小比例，默认值是100

config get auto-aof-rewrite-min-size

config get auto-aof-rewrite-percentage

⚠️： 使用bgrewriteaof命令，可以自动触发AOF文件重写

AOF重写流程

• AOF文件重写是生成一个全新的文件，并把当前数据最少操作命令保存到新文件上，当把所有的数据都保存至新的文件之后，Redis会交换两个文件，并把最新的持久化操作命令追加到新的文件上

配置说明

• 合理的设置AOF，可以保障Redis高效且稳定的运行，以下是AOF的全部配置和信息。

# 是否开启 AOF，yes 为开启，默认是关闭
appendonly no

# AOF 默认文件名
appendfilename "appendonly.aof"

# AOF 持久化策略配置
# appendfsync always
appendfsync everysec
# appendfsync no

# AOF 文件重写的大小比例，默认值是 100，表示 100%，也就是只有当前 AOF 文件，比最后一次的 AOF 文件大一倍时，才会启动 AOF 文件重写。
auto-aof-rewrite-percentage 100

# 允许 AOF 重写的最小文件容量
auto-aof-rewrite-min-size 64mb

# 是否开启启动时加载 AOF 文件效验，默认值是 yes，表示尽可能的加载 AOF 文件，忽略错误部分信息，并启动 Redis 服务。
# 如果值为 no，则表示，停止启动 Redis，用户必须手动修复 AOF 文件才能正常启动 Redis 服务。
aof-load-truncated yes

优缺点

AOF优点

• AOF持久话保存的数据更加完整，AOF提供了三种保存策略，每次操作保存，每秒钟保存一次、跟随系统的持久化策略保存，其中每秒保存一次，从数据的安全性和性能两方面考虑是一个不错的选择，也是AOF持久化的策略，即使发生意外的话，最多也就是这一秒钟的数据丢失
• AOF采用的是命令追加的写入方式，所以不会出现文件损坏的问题,即使由于某些意外原因，导致了最后操作的持久化数据写入了一半，也可以通过redis-check-aof工具轻松修复
• AOF持久化文件，非常容易理解和解析，它是所有Redis键值操作命令，以文件的方式存入到磁盘。即使不小心使用了flushall等操作时，只要使用AOF文件，删除最后的flushall命令，重启Redis即可恢复之前误伤的数据

AOF缺点

• 对于相同的数据集来说，AOF文件要大雨RDB文件；
• 在Redis负载比较高的情况下，RDB比AOF性能更好
• RDB使用快照的形式来持久话整个Redis数据，而AOF只是将每次执行的命令追加到AOF文件中，因此从理论上讲。ROB比AOF更健壮