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

我们在使用电脑的时候，难免会遇到计算机宕机的情况服务器宕机是计算机术语，口语叫“down机”是指操作系统无法从一个严重系统错误中恢复过来，或系统硬件层面出问题，导致电脑或者服务器不能正常工作，而不得不重新启动计算机的现象这个时候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

AOF是追加更改命令文件，那么大家想下一直追加追加，就是会导致文件过大，那么Redis是怎么解决这个问题的呢？ Redis解决这个问题的方法是AOF下面有个机制叫做bgrewriteaof重写机制，我们来看下它是个啥

注：AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的AOF文件。

我们知道了AOF的实现原理，我们来分析下它的优缺点。

优点：能最大限度的保证数据安全，就算用默认的配置everysec，也最多只会造成1s的数据丢失。

缺点：数据量比RDB要大很多，所以性能没有RDB好！

以上就是宜享花对于Redis持久化机制的介绍，想要了解更多，欢迎关注宜享花，我们将为你答疑解惑！

,