RDB技术
概述: 在指定的时间间隔内将内存中的数据集快照写入磁盘, 也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里
执行过程:
- Redis会单独创建
(fork)一个子进程来进行持久化; - 会先将数据写入到 一个
临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。 - 整个过程中,主进程是不进行任何IO操作的,这就
确保了极高的性能如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。 - RDB的缺点是
最后一次持久化后的数据可能丢失。 - fork这个进程的使用就是引进的
"写时复制技术"
丢失的原因: 将数据写入到临时文件时,这个时候进程挂掉,剩下的数据就会丢失
配置文件参数解释:
//文件存储的位置
dir
//当Redis无法写入磁盘的话,直接关掉Redis的写操作。推荐yes.
stop-writes-on-bgsave-error yes
//如果你不想消耗CPU来进行压缩的话,可以设置为关闭此功能。推荐yes.
rdbcompression yes
//检查完整性 但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能,推荐yes.
rdbchecksum yes
// saveVS bgsave
save:save时只管保存,其它不管,全部阻塞。手动保存。不建议。
bgsave:Redis会在后台异步进行快照操作, 快照同时还可以响应客户端请求。(推荐)
save 秒数 次数
AOF技术
概述:
以日志的形式来记录每个写操作(增量保存),将Redis执行过的所有写指令记录下来(读操作不记录), 只许追加文件但不可以改写文件 ,将策略修改为always,不会造成数据丢失
执行过程:
- 客户端的请求写命令会被
append追加到AOF缓冲区内; - AOF缓冲区根据AOF持久化策略
[always,everysec,no]将操作sync同步到磁盘的AOF文件中; - AOF文件大小超过重写策略或手动重写时,
会对AOF文件rewrite重写,只记录最后的操作 ,达到压缩AOF文件容量的要求; - Redis服务重启时,会
重新load加载AOF文件中的写操作达到数据恢复的目的
配置参数介绍:
//开启AOF : 默认是不开启的,RDB和AOF都开启默认读取AOF文件
appendonly yes
//AOF同步频率设置 三种模式 : 同步追加/每秒进行同步/交给系统进行同步
appendfsync always/everysec/no
本文探讨了Redis两种数据持久化技术RDB(快照持久化)和AOF(日志持久化),包括它们的工作原理、执行流程、优缺点以及关键配置参数。了解如何在高可用性和性能间权衡,以及如何根据业务需求选择合适的持久化策略。
2072

被折叠的 条评论
为什么被折叠?



