如何在复述中实现持久化

  介绍

如何在复述中实现持久化?针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。

1,概述

复述是内存数据库,如果不能将内存中的数据保存到磁盘中,那么一旦服务器进程退出,服务器的数据库数据也会消失,所以复述,提供了持久化的功能,复述,分为两种持久化方式:RDB和AOF。有以下几个特点:

1. RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。

2. AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以复述,协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件后台重写,使得AOF文件的体积不至于过大。

3。如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化的方式。

4。你也可以同时开启两种持久化方式,在这种情况下,当复述,重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。

2, RDB

1,概念

在指定的时间间隔内将内存中的数据集快照写入磁盘中,它恢复的时候是将快照中的文件直接读取到内存中。

2,持久化机制-BGSAVE

如何在复述中实现持久化

通常,会立即返回好的,复述,进程会执行叉操作创建子进程,复述,在叉时,父进程会继续为客户端提供服务,子进程会将数据持久化到硬盘上,然后退出。如果已经在后台执行保存或者正在运行另一个非后台保存的进程,特别是正在进行AOF写入时,则会返回错误。如果使用了bgsave任务,而正在进行AOF写入时,该命令将立即返回好,并计划在下一次机会运行后台保存。阻塞只会在叉阶段。
客户端可以使用lastsave命令检查操作是否成功。

3,持久化机制-保存

不会接受客户端执行的操作命令,等持久化工作完成之后,会将新的文件替换旧的文件。

4,持久化机制,自动触发

在<代码>复述。设计> 属保存性,让服务器每一段时间内执行一次<代码> bgsave 操作。

#,服务器在900秒内,对数据库进行了至少1次修改   节省;900,1   ,   #,服务器在300秒内,对数据库进行了至少10次修改   节省;300,10   ,   #,服务器在60秒内,对数据库进行了至少10000次修改   节省;60,10000   ,   #,bgsave发生错误时是否停止写入,一般为是的   stop-writes-on-bgsave-error 是的   ,   #,持久化时是否使用LZF压缩字符串对象吗?   rdbcompression 是的   ,   #,是否对rdb文件进行校验和检验,通常为是的   rdbchecksum 是的   ,   #,RDB持久化文件名   dbfilename  dump.rdb   ,   #,持久化文件存储目录   dir 。/

5,恢复数据机制

只需要将rdb文件放在我们复述,启动目录就可以了,复述,启动的时候会自动检查文件并恢复其中的数据。

6,优点

<李>

rdb是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集。

<李>

rdb是一个紧凑的单一文件,很方便传送到另一个远端数据中心或者亚马逊的S3(可能加密),非常适用于灾难恢复。

<李>

rdb在保存rdb文件时父进程唯一需要做的就是叉出一个子进程,接下来的工作全部由子进程来做,父进程不需要再做其他IO操作,所以rdb持久化方式可以最大化复述的性能。

<李>

与AOF相比,在恢复大的数据集的时候,rdb方式会更快一些。

7,缺点

<李>

如果你希望在复述,意外停止工作(例如电源中断)的情况下丢失的数据最少的话,那么rdb不适合你。虽然你可以配置不同的保存时间点(例如每隔5分钟并且对数据集有100个写的操作),是复述要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在复述,意外宕机,你可能会丢失几分钟的数据。

<李>

rdb需要经常叉子进程来保存数据集到硬盘上,当数据集比较大的时候,叉的过程是非常耗时的,可能会导致复述,在一些毫秒级内不能响应客户端的请求。如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要叉,但是你可以调节重写日志文件的频率来提高数据集的耐久度。

如何在复述中实现持久化