如何在复述中实现持久化?针对这个问题,这篇文章详细介绍了相对应的分析和解答,希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
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也需要叉,但是你可以调节重写日志文件的频率来提高数据集的耐久度。