redis宕机和过期 Redis策略如何保障服务器宕机或重启

redis宕机和过期 Redis策略如何保障服务器宕机或重启?我们在使用电脑的时候,难免会遇到计算机宕机的情况服务器宕机是计算机术语,口语叫“down机”是指操作系统无法从一个严重系统错误中恢复过来,或系统硬件层面出问题,导致电脑或者服务器不能正常工作,而不得不重新启动计算机的现象这个时候redis持久化机制就起到了作用,我来为大家科普一下关于redis宕机和过期 Redis策略如何保障服务器宕机或重启?下面希望有你要的答案,我们一起来看看吧!

redis宕机和过期 Redis策略如何保障服务器宕机或重启


redis宕机和过期 Redis策略如何保障服务器宕机或重启我们在使用电脑的时候,难免会遇到计算机宕机的情况 。服务器宕机是计算机术语,口语叫“down机”是指操作系统无法从一个严重系统错误中恢复过来,或系统硬件层面出问题,导致电脑或者服务器不能正常工作,而不得不重新启动计算机的现象 。这个时候redis持久化机制就起到了作用 。
那么Redis是如何保障服务器宕机或重启呢?我们一起来看一看吧!
Redis 的持久化策略有两种:RDB(快照全量持久化)和AOF(增量日志持久化)
1、 RDB
RDB 是 Redis 默认的持久化方案 。RDB快照(Redis DataBase),当触发一定条件的时候,会把当前内存中的数据写入磁盘,生成一个快照文件dump.rdb 。Redis重启会通过dump.rdb文件恢复数据 。那那个一定的条件是啥呢?到底什么时候写入rdb 文件?
触发Redis执行rdb的方式有两类:自动触发和手动触发 “自动触发”的情况有三种:达到配置文件触发规则时触发、执行shutdown命令时触发、执行flushall命令时触发 。
注:在redis.conf中有个 SNAPSHOTTING配置,其中定义了触发把数据保存到磁盘触发频率 。
“手动触发”的方式有两种:执行save 或 bgsave命令 。执行save命令在生成快照的时候会阻塞当前Redis服务器,Redis不能处理其他命令 。如果内存中的数据比较多,会造成Redis长时间的阻塞 。生产环境不建议使用这个命令 。
为了解决这个问题,Redis 提供了第二种方式bgsave命令进行数据备份,执行bgsave时,Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求 。
具体操作是Redis进程执行fork(创建进程函数)操作创建子进程(copy-on-write),RDB持久化过程由子进程负责,完成后自动结束 。它不会记录 fork 之后后续的命令 。阻塞只发生在fork阶段,一般时间很短 。手动触发的场景一般仅用在迁移数据时才会用到 。
我们知道了RDB的实现的原理逻辑,那么我们就来分析下RDB到底有什么优劣势 。
优势:
(1)RDB是一个非常紧凑(compact类型)的文件,它保存了redis在某个时间点上的数据集 。这种文件非常适合用于进行备份和灾难恢复 。
(2)生成RDB文件的时候,redis主进程会fork()一个子进程来处理所有保存工作,主进程不需要进行任何磁盘IO操作 。
(3)RDB在恢复大数据集时的速度比AOF的恢复速度要快 。
劣势:RDB方式数据没办法做到实时持久化/秒级持久化 。在一定间隔时间做一次备份,所以如果Redis意外down掉的话,就会丢失最后一次快照之后的所有修改
2、 AOF(Append Only File)
AOF采用日志的形式来记录每个写操作的命令,并追加到文件中 。开启后,执行更改 Redis数据的命令时,就会把命令写入到AOF文件中 。Redis重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作 。
其实AOF也不一定是完全实时的备份操作命令,在redis.conf 我们可以配置选择 AOF的执行方式,主要有三种:always、everysec和no

推荐阅读