searchusermenu
  • 发布文章
  • 消息中心
点赞
收藏
评论
分享
原创

Redis持久化方案对比

2023-10-30 01:54:32
5
0

1 概述

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

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

2 RDB持久化机制

一旦采用该方式,那么你的整个Redis数据库将只包含一个文件,这对于文件备份而言是非常完美的。比如,你可能打算每个小时归档一次最近24小时的数据,同时还要每天归档一次最近30天的数据。通过这样的备份策略,一旦系统出现灾难性故障,我们可以非常容易的进行恢复。dump内存快照

优点: 

  • 故障恢复效率高:对于灾难恢复而言,RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它的存储介质上。
  • 性能最大化:对于Redis的服务进程而言,在开始持久化时,它唯一需要做的只是fork(分叉)出子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执行IO操作了。
  • 启动快:相比于AOF机制,如果数据集很大,RDB的启动效率会更高

缺点: 

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

配置: 

1、编辑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
# like in the following example:
# #
save ""
save 900 1
save 300 10
save 60 10000

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

2、重启redis

redis-server.exe redis.windows.conf

3 AOF持久化机制

AOF机制可以带来更高的数据安全性,即数据持久性。Redis中提供了3中同步策略,即每秒同步、每修改同步和不同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,所差的是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每修改同步,我们可以将其视为同步持久化,即每次发生的数据变化都会 被立即记录到磁盘中。可以预见,这种方式在效率上是最低的。至于无同步,无需多言,我想你能正确的理解它。

优点: 

  • 数据安全性高: 由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题,不用担心,在Redis下一次启动之前,我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
  • 如果日志过大: Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中,同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
  • AOF包含一个格式清晰 、易于理解的日志文件用于记录所有的修改操作。事实上,我们也可以通过该文件完成数据的重建

缺点: 

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

配置: 

编辑redis.windwos.conf文件,配置持久化策略

1、将appendonly修改为yes

############################## 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.
appendonly no

2、开启aof持久化机制

# appendfsync always
appendfsync everysec
# appendfsync no

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

0条评论
0 / 1000
1****m
13文章数
0粉丝数
1****m
13 文章 | 0 粉丝
原创

Redis持久化方案对比

2023-10-30 01:54:32
5
0

1 概述

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

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

2 RDB持久化机制

一旦采用该方式,那么你的整个Redis数据库将只包含一个文件,这对于文件备份而言是非常完美的。比如,你可能打算每个小时归档一次最近24小时的数据,同时还要每天归档一次最近30天的数据。通过这样的备份策略,一旦系统出现灾难性故障,我们可以非常容易的进行恢复。dump内存快照

优点: 

  • 故障恢复效率高:对于灾难恢复而言,RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它的存储介质上。
  • 性能最大化:对于Redis的服务进程而言,在开始持久化时,它唯一需要做的只是fork(分叉)出子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执行IO操作了。
  • 启动快:相比于AOF机制,如果数据集很大,RDB的启动效率会更高

缺点: 

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

配置: 

1、编辑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
# like in the following example:
# #
save ""
save 900 1
save 300 10
save 60 10000

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

2、重启redis

redis-server.exe redis.windows.conf

3 AOF持久化机制

AOF机制可以带来更高的数据安全性,即数据持久性。Redis中提供了3中同步策略,即每秒同步、每修改同步和不同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,所差的是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每修改同步,我们可以将其视为同步持久化,即每次发生的数据变化都会 被立即记录到磁盘中。可以预见,这种方式在效率上是最低的。至于无同步,无需多言,我想你能正确的理解它。

优点: 

  • 数据安全性高: 由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题,不用担心,在Redis下一次启动之前,我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。
  • 如果日志过大: Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中,同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
  • AOF包含一个格式清晰 、易于理解的日志文件用于记录所有的修改操作。事实上,我们也可以通过该文件完成数据的重建

缺点: 

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

配置: 

编辑redis.windwos.conf文件,配置持久化策略

1、将appendonly修改为yes

############################## 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.
appendonly no

2、开启aof持久化机制

# appendfsync always
appendfsync everysec
# appendfsync no

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

文章来自个人专栏
后端研发
13 文章 | 1 订阅
0条评论
0 / 1000
请输入你的评论
0
0