Redis两种持久化方案的优劣

旅晋

已于 2022-06-12 21:59:45 修改

阅读量594

点赞数

文章标签： redis 数据库 java

于 2022-06-12 21:49:43 首次发布

本文链接：https://blog.csdn.net/weixin_58768551/article/details/125250513

版权

redis的持久化

RDB持久化机制.

语法说明
save <时间间隔> <修改键数> 过多久(单位是秒)，修改了多少个键(增删改)
Redis DataBase 默认的持久化方式，以二进制的方式将数据写入文件中。每隔一段时间写入一次。

优点 :
1. 方便备份和恢复. 因为整个Redis数据库只包含一个文件,默认是dump.rdb.
2. 性能最大化. rdb持久化由子分支进行,不影响主进程服务.
3. 启动效率更高.
缺点:
1. 不能完全避免数据丢失. 因为RDB是每隔一段时间写入数据，所以系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2. 会导致服务器暂停的现象. 由于RDB是通过子进程来协助完成数据持久化工作的，因此当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

语法	说明
save <时间间隔> <修改键数>	过多久(单位是秒)，修改了多少个键(增删改)

AOF持久化机制

Redis中提供了3种AOF同步策略	说明
每秒同步	每过一秒中记录一次
每修改同步	每次修改(增删改)都会记录一次
不同步	不记录任何操作

默认关闭. 开启需要配置参数 appendonly no/yes. 修改为yes开启. 与rdb存储方式不共存.

优点 :
* AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。也可以通过该文件完成数据的重建。该机制可以带来更高的数据安全性，所有的操作都是异步完成的。
缺点 :

文件比RDB更大：对于相同数量的数据集而言，AOF文件通常要大于RDB文件。

运行效率比RDB更慢：根据同步策略的不同，AOF在运行效率上往往会慢于RDB。

相关资料：

1）RDB 持久化

RDB持久化可以使用save或bgsave，为了不阻塞主进程业务，一般都使用bgsave，流程：

Redis 进程会 fork 出一个子进程（与父进程内存数据一致）。
父进程继续处理客户端请求命令
由子进程将内存中的所有数据写入到一个临时的 RDB 文件中。
完成写入操作之后，旧的 RDB 文件会被新的 RDB 文件替换掉。

下面是一些和 RDB 持久化相关的配置：

save 60 10000：如果在 60 秒内有 10000 个 key 发生改变，那就执行 RDB 持久化。
stop-writes-on-bgsave-error yes：如果 Redis 执行 RDB 持久化失败（常见于操作系统内存不足），那么 Redis 将不再接受 client 写入数据的请求。
rdbcompression yes：当生成 RDB 文件时，同时进行压缩。
dbfilename dump.rdb：将 RDB 文件命名为 dump.rdb。
dir /var/lib/redis：将 RDB 文件保存在/var/lib/redis目录下。

　　当然在实践中，我们通常会将stop-writes-on-bgsave-error设置为false，同时让监控系统在 Redis 执行 RDB 持久化失败时发送告警，以便人工介入解决，而不是粗暴地拒绝 client 的写入请求。

RDB持久化的优点：

RDB持久化文件小，Redis数据恢复时速度快
子进程不影响父进程，父进程可以持续处理客户端命令
子进程fork时采用copy-on-write方式，大多数情况下，没有太多的内存消耗，效率比较好。

RDB 持久化的缺点：

子进程fork时采用copy-on-write方式，如果Redis此时写操作较多，可能导致额外的内存占用，甚至内存溢出
RDB文件压缩会减小文件体积，但通过时会对CPU有额外的消耗
如果业务场景很看重数据的持久性 (durability)，那么不应该采用 RDB 持久化。譬如说，如果 Redis 每 5 分钟执行一次 RDB 持久化，要是 Redis 意外奔溃了，那么最多会丢失 5 分钟的数据。

2）AOF 持久化

　　可以使用appendonly yes配置项来开启 AOF 持久化。Redis 执行 AOF 持久化时，会将接收到的写命令追加到 AOF 文件的末尾，因此 Redis 只要对 AOF 文件中的命令进行回放，就可以将数据库还原到原先的状态。　　与 RDB 持久化相比，AOF 持久化的一个明显优势就是，它可以提高数据的持久性 (durability)。因为在 AOF 模式下，Redis 每次接收到 client 的写命令，就会将命令write()到 AOF 文件末尾。　　然而，在 Linux 中，将数据write()到文件后，数据并不会立即刷新到磁盘，而会先暂存在 OS 的文件系统缓冲区。在合适的时机，OS 才会将缓冲区的数据刷新到磁盘（如果需要将文件内容刷新到磁盘，可以调用fsync()或fdatasync()）。　　通过appendfsync配置项，可以控制 Redis 将命令同步到磁盘的频率：

always：每次 Redis 将命令write()到 AOF 文件时，都会调用fsync()，将命令刷新到磁盘。这可以保证最好的数据持久性，但却会给系统带来极大的开销。
no：Redis 只将命令write()到 AOF 文件。这会让 OS 决定何时将命令刷新到磁盘。
everysec：除了将命令write()到 AOF 文件，Redis 还会每秒执行一次fsync()。在实践中，推荐使用这种设置，一定程度上可以保证数据持久性，又不会明显降低 Redis 性能。

　　然而，AOF 持久化并不是没有缺点的：Redis 会不断将接收到的写命令追加到 AOF 文件中，导致 AOF 文件越来越大。过大的 AOF 文件会消耗磁盘空间，并且导致 Redis 重启时更加缓慢。为了解决这个问题，在适当情况下，Redis 会对 AOF 文件进行重写，去除文件中冗余的命令，以减小 AOF 文件的体积。在重写 AOF 文件期间， Redis 会启动一个子进程，由子进程负责对 AOF 文件进行重写。　　可以通过下面两个配置项，控制 Redis 重写 AOF 文件的频率：