一. Redis持久化概述

Redis的高性能是由于其将所有数据都存储在了内存中,为了使Redis在重启之后仍能保证数据不丢失,需要将数据从内存中同步到硬盘中,这一过程就是持久化. Redis支持两种方式的持久化,一种是RDB(Redis Database)方式,一种是AOF(Append Only File)方式. 可以单独使用其中一种或将二者结合使用

• RDB持久化(默认)
  该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘
• AOF持久化
  该机制将以日志的形式记录服务器所处理的每一个写操作,在Redis服务器启动之初会读取该文件来重新构建数据库,以保证启动后数据库中的数据是完整的
• 无持久化
  可以通过配置的方式禁用Redis服务器的持久化功能,这样我们就可以将Redis视为一个功能加强版的memcached了
• redis可以同时使用RDB和AOF

二. RDB持久化机制

1. RDB持久化机制优点

• 一旦采用该方式,那么你的整个Redis数据库将只包含一个文件,这对于文件备份来说是很完美的. 比如,你可能打算每个小时归档一次最近24小时的数据,同时还要每天归档一次近30天的数据. 通过这样的备份策略,一旦系统出现故障,我们可以非常容易进行恢复
• 对于灾难恢复而言,RDB是非常不错的选择. 因为我们可以非常轻松的将一个单独的文件压缩后再转移到其他存储介质上
• 性能最大化. 对于Redis的服务进程而言,在开始持久化时,它唯一需要做的就是fork出子进程,之后再由子进程完成持久化操作,这样就能极大的避免服务进程进行IO操作了

相比于AOF,如果数据集很大,RDB的启动效率会更高

2. RDB持久化机制缺点

• 如果你想保证数据的高可用性,即最大限度的保证数据不丢失,那么RDB就不是一个很好的选择,因为系统在即将定时持久化之前宕机,此时没有来的及写入磁盘的数据将全部丢失
• 由于RDB是通过fork出子进程来协助完成数据持久化工作的,因此,当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至1sec

3. RDB持久化机制配置

在redis.windows.conf配置文件中有如下配置:

################################ SNAPSHOTTING #################################
# #
Save the DB on disk:
# #
save <seconds> <changes>
# #
Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
# #
In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
# #
Note: you can disable saving at all commenting all the "save" lines.
# #
It is also possible to remove all the previously configured save
# points by adding a save directive with a single empty string argument
# like in the following example:
# #
save ""
save 900 1
save 300 10
save 60 10000
123456789101112131415161718192021222324

其中,上面配置的是RDB方式数据持久化时机:

三. AOF持久化机制

1. AOF持久化机制优点

• 该机制可以带来更高的数据安全性,即数据持久性. Redis中提供了3中同步策略,即每秒同步、每修改同步和不同步. 事实上，每秒同步也是异步完成的,其效率也是非常高的,所差的是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失. 而每修改同步,我们可以将其视为同步持久化,即每次发生的数据变化都会被立即记录到磁盘中. 可以预见, 这种方式在效率上是最低的. 至于无同步,无需多言,大家都能够理解
• 由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容. 然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题,不用担心,在Redis下一次启动之前,我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题
• 如果日志过大,Redis可以自动启用rewrite机制. 即Redis以append模式不断的将修改数据写入到老的磁盘文件中,同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行. 因此在进行rewrite切换时可以更好的保证数据安全性
• AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作. 事实上,我们也可以通过该文件完成数据的重建

2. AOF持久化机制缺点

• 对于相同数量的数据集而言,AOF文件通常要大于RDB文件
• 根据同步策略的不同,AOF在运行效率上往往会慢于RDB. 总之,每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效

3. AOF持久化机制配置

• 开启AOF持久化

  ############################## APPEND ONLY MODE ###############################

  By default Redis asynchronously dumps the dataset on disk. This mode is

  good enough in many applications, but an issue with the Redis process or

  a power outage may result into a few minutes of writes lost (depending on

  the configured save points)

  The Append Only File is an alternative persistence mode that provides

  much better durability. For instance using the default data fsync policy

  (see later in the config file) Redis can lose just one second of writes in a

  dramatic event like a server power outage, or a single write if something

  wrong with the Redis process itself happens, but the operating system is

  still running correctly.

  AOF and RDB persistence can be enabled at the same time without problems.

  If the AOF is enabled on startup Redis will load the AOF, that is the file

  with the better durability guarantees.

  Please check redis.io/topics/pers… for more information. appendonly no 12345678910111213141516171819

将appendonly修改为yes,开启aof持久化机制,默认会在目录下产生一个appendonly.aof文件

• AOF持久化时机

  appendfsync always

  appendfsync everysec

  appendfsync no

  123

上述配置为aof持久化的时机,解释如下:

四. 两种持久化方式对比