redis持久化_redis持久化文件存在哪里

1、概述

redis是内存数据库，它把数据存储在内存中，这样在加快读取速度的同时也对数据完整性产生了新的问题，即当redis所在服务器发生宕机后，内存中的所有数据将会全部丢失。为了解决这个问题，redis提供了持久化功能——RDB和AOF（Append Only File）。

数据的持久化存储是 Redis 的重要特性之一，它能够将内存中的数据保存到本地磁盘中，实现对数据的持久存储。这样即使在服务器发生故障之后，也能通过本地磁盘对数据进行恢复。

2、redis配置文件

在 redis 的安装目录中有一个名为redis.conf的配置文件，redis在启动时会加载这个配置文件，在运行时按照配置进行工作。下面对常见的redis配置文件进行说明

（1）redis网络相关的配置

（2）redis的常规配置

（3）redis的安全配置

redis提供了config命令来查看或者更改redis配置信息。主要有config set、config get、config rewrite

• config set

  该命令可以动态地调整 Redis 服务器的配置而无须重启，其语法格式：

  config set 配置项名称 配置项参数
  1

  # 更改运行save命令后Redis将产生的数据库转储文件的名称
  config set "dbfilename" "new_file.rdb"
  1
  2

• config get

  该命令用于取得运行中的 Redis 服务器的配置参数，语法格式：

  config get 配置项名称
  1

  "配置项名称"可以使用通配符，例如congif get *可以得到所有支持的配置参数信息。

  # 获取日志等级配置项
  config get loglevel 
  1
  2

• config rewrite

  config set不会永久更改Redis实例的配置文件；它仅在运行时更改Redis的配置文件，是临时的。要redis.conf在运行config set命令后进行编辑并使当前会话的配置永久化，需要使用config rewrite命令

  config rewrite
  1

3、RDB

RDB（Redis DataBase）即快照模式，是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，将内存中的数据写入到磁盘中。它会将数据库的快照保存在 dump.rdb 这个二进制文件中，Redis重启会通过加载dump.rdb文件来恢复数据。

• RDB原理

  Redis 使用操作系统的多进程 COW(Copy On Write) 机制来实现快照持久化操作。RDB 实际上是 Redis 内部的一个定时器事件，它每隔一段固定时间就去检查当前数据发生改变的次数和改变的时间频率，看它们是否满足配置文件中规定的持久化触发条件。当满足条件时，Redis 就会通过操作系统调用 fork() 来创建一个子进程，通过子进程遍历整个内存空间来获取存储的数据，从而完成数据持久化操作。

• redis的RDB配置说明

  配置项	说明
  save	配置符合的快照触发条件，即Redis 在seconds秒内key改变changes次，Redis把快照内的数据保存到磁盘中一次。
  stop-writes-on-bgsave-error	当bgsave快照操作出错时停止写数据到磁盘，为了保证内存数据和磁盘数据的一致性，但如果不在乎这种一致性，要在bgsave快照操作出错时继续写操作，可以配置为no。
  rdbcompression	设置对于存储到磁盘中的快照是否进行压缩，设置为yes时，Redis会采用LZF算法进行压缩；如果不想消耗CPU进行压缩的话，可以设置为no，关闭此功能。
  rdbchecksum	在存储快照以后，还可以让Redis使用CRC64算法来进行数据校验，但这样会消耗一定的性能，如果系统比较在意性能的提升，可以设置为no，关闭此功能。
  dbfilename	Redis持久化数据生成的文件名，默认是dump.rdb，也可以自己配置。
  dir	Redis持久化数据生成文件保存的目录，默认是./即redis的启动目录，也可以自己配置

• RDB持久化触发策略
  RDB 持久化提供了两种触发策略：一种是手动触发，另一种是自动触发。

  • 手动触发

    手动触发是通过SAVAE命令或者BGSAVE命令将内存数据保存到磁盘文件中，

    save 命令会阻塞 Redis 服务器进程，直到 dump.rdb 文件创建完毕为止，在这个过程中，服务器不能处理任何的命令请求。
    BGSAVE命令是非阻塞式的，该命令执行的过程中，并不影响 Redis 服务器处理客户端的其他请求

  • 自动触发

    自动触发策略，是指 Redis 在指定的时间内，数据发生了多少次变化时，会自动执行BGSAVE命令。自动触发的条件包含在了 Redis 的配置文件中redis.conf
    

• RDB持久化的缺点

  RDB 持久化的缺点在于，最后一次持久化的数据可能会出现丢失的情况。Redis默认开启RDB持久化方式，如果对数据的完整性不是特别敏感（可能存在最后一次丢失的情况），那么 RDB 持久化方式非常合适大规模的数据恢复。

4、AOF

AOF（Append Only File）称为追加模式，或日志模式，是 Redis 提供的另一种持久化策略，Redis 默认处于未开启状态。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录对内存有过修改的命令，并追加到文件中。Redis 重启会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF默认的日志保存文件是appendonly.aof文件 ,位置保存在Redis的启动目录。如果开启了AOF，Redis每次记录写操作都会往appendonly.aof文件追加新的日志内容。

• redis的AOF配置说明

  配置项	说明
  appendonly	配置是否开启AOF，yes表示开启，no表示关闭。默认是no。
  appendfilename	AOF保存文件名
  appendfsync	AOF持久化策略： always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差但数据完整性比较好 everysec：默认推荐，每秒异步记录一次（默认值） no：不即时同步，由操作系统决定何时同步。
  no-appendfsync-on-rewrite	重写时是否可以运用appendsync，默认no，可以保证数据的安全性。
  auto-aof-rewrite-percentage	设置重写的基准百分比
  auto-aof-rewrite-min-size	设置重写的基准值

• 写入机制
  每当有一个修改数据库的命令被执行时，服务器就将命令写入到 appendonly.aof 文件中，该文件存储了服务器执行过的所有修改命令，因此，只要服务器重新执行一次 .aof 文件，就可以实现还原数据的目的。

• 重写机制

  AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。