Redis系列 - 持久化机制探究_1 changes in 3600 seconds. saving... [3976] 18 jul-CSDN博客

本文链接：https://blog.csdn.net/y510662669/article/details/106677717

背景

Redis的数据都在内存里面，如果服务突然宕机，数据岂不是全丢了，别慌，Redis通过了持久化机制来保证数据不丢失。Redis的持久化集中制包括：1）RDB 2）AOF 3）混合持久化。混合持久化是从Redis4.0开始支持。

RDB方式

什么是rdb持久化，rdb持久化可以理解为在某个时间点对所有数据做一次快照。

触发RDB的方式？

1）通过修改redis配置文件。

SAVE 900 1 代表900秒内有一条命令写入就执行快照。

SAVE 300 10 代表300秒内有十条命令写入就执行快照。

可以看到具体的执行日志：

5644:M 12 Jun 2020 11:44:15.970 * Ready to accept connections
5644:M 12 Jun 2020 15:56:48.582 * 1 changes in 3600 seconds. Saving...
5644:M 12 Jun 2020 15:56:48.613 * Background saving started by pid 5681
5681:C 12 Jun 2020 15:56:48.619 * DB saved on disk
5644:M 12 Jun 2020 15:56:48.715 * Background saving terminated with success
5644:M 12 Jun 2020 16:56:49.079 * 1 changes in 3600 seconds. Saving...
5644:M 12 Jun 2020 16:56:49.112 * Background saving started by pid 5682
5682:C 12 Jun 2020 16:56:49.119 * DB saved on disk
5644:M 12 Jun 2020 16:56:49.213 * Background saving terminated with success
5644:M 12 Jun 2020 18:27:05.821 * 1 changes in 3600 seconds. Saving...
5644:M 12 Jun 2020 18:27:05.851 * Background saving started by pid 5683
5683:C 12 Jun 2020 18:27:05.858 * DB saved on disk
5644:M 12 Jun 2020 18:27:05.953 * Background saving terminated with success

2）显示命令bgsave

127.0.0.1:6379> bgsave
Background saving started

执行日志：

5644:M 13 Jun 2020 13:09:49.883 * Background saving started by pid 5711
5711:C 13 Jun 2020 13:09:49.891 * DB saved on disk
5644:M 13 Jun 2020 13:09:49.984 * Background saving terminated with success

具体的执行流程：

RDB的触发在redis正常关机的情况下，如果没有开aof日志，shutdown之前也会执行一次保存快照的操作。

AOF方式

AOF是Redis的另外一种持久化方式。简单来说，AOF就是将Redis服务端执行过的每一条命令都保存到一个文件，这样当Redis重启时只要按顺序回放这些命令就会恢复到原始状。

如果开启了AOF，则每条命令执行完毕后都会同步写入aof_buf中，aof_buf是个全局的SDS类型的缓冲区。

AOF整体流程：

AOF持久化的流程：

AOF持久化最终需要将缓冲区中的内容写入一个文件，写文件通过操作系统提供的write函数执行。但是write之后数据只是保存在kernel的缓冲区中，真正写入磁盘还需要调用fsync函数。fsync是一个阻塞并且缓慢的操作，所以Redis通过appendfsync配置控制执行fsync的频次。具体有如下3种模式。

no：不执行fsync，由操作系统负责数据的刷盘。数据安全性最低但Redis性能最高。
always：每执行一次写入就会执行一次fsync。数据安全性最高但会导致Redis性能降低。
everysec：每1秒执行一次fsync操作。属于折中方案，在数据安全性和性能之间达到一个平衡。

生产环境一般配置为appendfsync everysec，即每秒执行一次fsync操作。

随着命令越来越多，aof文件会越来越大，redis会对aof文件进行瘦身优化，比如多条命令合并为一条，可以通过配置文件来配置。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

当AOF文件大于64MB时，并且AOF文件当前大小比基准大小增长了100%时会触发一次AOF重写。

混合持久化

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。

Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。

总结

redis持久化的方式，包括rdb镜像方式，aof日志，以及rdb+aof日志。但是，redis很难保证数据不丢失，毕竟aof日志也是一秒刷一次到磁盘，如果某单台redis服务的qps很高，物理机器在某秒宕机，机器恢复后，可能就会丢失一秒内的日志。对应的可能是N多指令。那么如何解决这个问题呢？通过搭建redis集群或者通过主从复制。毕竟redis是ap型的应用，如果真的想保证数据不丢失，那么就要像kafka那样设计，一个分区采用多副本机制，但是这样实现成本就更高了。性能肯定也会下降，违背redis高性能的初衷。所以在分布式领域，真的只能是根据具体业务取舍，只能选择BASE理论。