Redis两种方式的持久化AoF与RDB解析

版权声明:本文为博主原创文章版权归作者和CSDN共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。 https://blog.csdn.net/javaee_gao/article/details/89439842

redis的持久化官网介绍

首先看一下Redis官网对持久化的介绍:redis持久化

Redis provides a different range of persistence options:

The RDB persistence performs point-in-time snapshots of your dataset at specified intervals.
the AOF persistence logs every write operation received by the server, that will be played again 
at server startup, reconstructing the original dataset. Commands are logged using the same format 
as the Redis protocol itself, in an append-only fashion. Redis is able to rewrite the log on background
when it gets too big.If you wish, you can disable persistence at all, if you want your data to just 
exist as long as the server is running.It is possible to combine both AOF and RDB in the same
instance. Notice that, in this case, when Redis restarts the AOF file will be used to reconstruct 
the original dataset since it is guaranteed to be the most complete.

以上简单明了讲了一个AOF和RDB两种持久化方式的特点,生产环境中可以根据实际情况选中其中一种方式,或者让两种方式都可以同时使用。下面将具体介绍AOF和RDB相关知识点:

RDB

介绍RDB之前,先简单介绍fork的含义:

fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)
数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程,在平时开发生活中,经常可以在Github上可以看到可以fork一份代码,可简单理解为copy。

RDB指的是在指定时间间隔内,将内存的数据集快照写入磁盘,也就是Redis称作为的Snapshot快照,默认保存为dump.rdb文件,当需要恢复redis的数据时候,直接将dump.rdb文件加载到内存以恢复redis的数据。如下图所示:redis.conf有详细介绍触发RDB将数据保存到磁盘的触发条件。

# 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 completely by commenting out all "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

save 900 1 这个意思是如果在900s内有1个key进行改变将会触发RDB的数据的保存工作。

如何触发快照?

RDB数据保存有两种方式:

  • save
    通过阻塞主线程,进行数据的保存,在保存期间,无法处理客户端请求。
  • bgsave
    redis会单独创建(fork)一个子进程来完成RDB数据持久化的工作,首先这个进程会将数据写入到临时文件,等持久化的工作完成后,会将这个临时的文件替换上一次持久化好的文件(即上一次持久化后的临时文件),而全程主进程不需参与任何io磁盘保存工作,这保证主进程可以高性能处理来自客户端的数据请求工作,所以basave适合线上数据维护的使用。

RDB优点和缺点

当需要进行redis数据恢复的时候,RDB速度是非常快速的,优于另一种AOF持久化方式,但是由于触发RDB保存数据的条件限制,可能会在最后一次持久化后的时候有存在数据丢失的情况,什么意思呢?比如:save 300 10 ,如果实际生产情况是300s内只有5次操作,而这个是无法触发RDB工作的,如果此时断电了,那么这些数据将会丢失。所以如果对数据的完整性和一致性要求不高的情况下,RDB非常适用于持久化工作。

AOF

像记录操作的数据库sql脚本一样,AOF会将redis之前执行过的所有写操作命令记录下来,只追加文件的方式,而不改写文件的方式保存到appendonly.aof文件,当redis需要进行数据恢复的时候,会将aof记录所有的写操作执行一遍,以完成数据的恢复工作,默认的aof是关闭的。

# 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 http://redis.io/topics/persistence for more information.
appendonly no
# The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"

以上说的是AOF提供了一个更好的持久化方式,假设使用默认的fsync策略,redis如果出现异常比如断电,最多也是丢失1s的数据,系统仍然可以正常运行,aof和rdb可以一块运行,如果aof默认打开(appendonly yes),redis启动的时候将会加载aof文件,两者可以保证redis数据有更好的稳定性.

  • AOF重写机制
    由于AOF采用的是文件追加方式,文件会越来越大。当文件大小超过设定的阈值,Redis就会使用重写机制,来完成文件内容压缩。其原理是当触发重写机制的时候,redis会fork一个子进程,类似与RDB方式,也是创建一个临时文件,当重写完成后使用临时文件替代现有的aof文件(重写过程中新的写变化也会写入新的临时文件中,原有的aof文件也会进行数据的写入,这是为了防止重写失败,数据会出现丢失的情况)。触发条件:默认是当AOF文件是上次重写aof文件大小的一倍且文件大小超过64M触发
  • AOF追加三种方式的比对
  1. appendfsync always:同步持久化,只要有数据的写操作就追加到AOF文件中,这样做的好处是保证了数据良好的完整性,但是性能会较差
  2. appendfsync everysec:异步持久化,每一秒会将当前redis的写数据命令追加到AOF文件中,这样做的好处是保证了高性能,但是如果在一秒内redis发送了宕机,那么这一秒内的数据会全部丢失。
  3. appenfsync no: 从不同步,这张生产环境不会用到。

总结

  1. 相同的数据集,AOF文件远远大与RDB文件,而且RDB方式恢复数据速度更快。
  2. 当redis进行恢复数据时,若同时开启AOF和RDB,redis会优先于加载AOF文件,因为AOF方式,更能保证数据的完整性。
  3. 官网建议同时开启AOF和RDB模式,因为RDB更适合做备份数据库,而且AOF方式会有潜在的BUG,为了保证数据安全和完整性,所以最好两种方式都启用。

猜你喜欢

转载自blog.csdn.net/javaee_gao/article/details/89439842