首页 / REDIS / Redis持久化机制与选择
Redis持久化机制与选择
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了Redis持久化机制与选择,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含3726字,纯文字阅读大概需要6分钟。
内容图文
![Redis持久化机制与选择](/upload/InfoBanner/zyjiaocheng/861/1e1ef6af9b4b4cc6998a80810cc2821c.jpg)
Redis提供了了不同级别的持久化方式RDB和AOF。
1 RDB方式–Redis DataBase
1.1 什么是RDB
RDB:每隔一段时间,把内存中的数据写入磁盘的临时文件,作为快照,恢复的时候把快照文件读进内存。如果宕机重启,内存数据丢失,再次启动redis后,则会恢复。
1.2 RDB优劣势
- 优势
- 每隔一段时间备份,全量备份
- 灾备简单,可以远程传输
- 保存RDB文件时,主线程唯一的工作是fork出一个子进程。子进程备份的时候,主进程不会有任何io操作(不会有写入修改或删除),保证备份数据的的完整性,最大化Redis性能。
- 相对AOF来说,当有更大文件的时候可以快速重启恢复。
- 劣势
- 发生故障时,有可能会丢失最后一次的备份数据
- 子进程所占用的内存比会和父进程一模一样,如会造成CPU负担
- 由于定时全量备份是重量级操作,所以对于实时备份,就无法处理了。
1.3 RDB的配置
RDB默认开启。
## SNAPSHOTTING
# 保存设置
save 900 1 # 至少1次操作,900s后触发DB操作
save 300 10 # 10次 300s后
save 60 10000 # 10000次 60s
# yes:如果save过程出错,则停止写操作
# no:可能造成数据不一致
stop-writes-on-bgsave-error yes
# yes:开启rdb压缩模式
# no:关闭,会节约cpu损耗,但是文件会大,道理同nginx
rdbcompression yes
# yes:使用CRC64算法校验对rdb进行数据校验,有10%性能损耗
# no:不校验
rdbchecksum yes
# db文件名
dbfilename "dump.rdb"
# 目录
dir "/usr/local/redis/working"
1.4 小结
RDB适合大量数据的恢复,但是数据的完整性和一致性可能会不足。
2 AOF方式–Append Only File
AOF以日志的形式记录用户请求的【写】操作,文件是以追加的形式,Redis的AOF恢复其实就是将AOF文件从开始到结尾读取执行写操作。有些类似MySQL的binlog。
2.1 AOF的优劣势
- 优势
- AOF更加健壮,可以秒级备份。增加了可靠性和数据完整性。
- 以日志形式追加,如果磁盘已满,存在未执行完整的写入命令,可以使用redis-check-aof工具修复。
- 当AOF文件过大时,后台可以自动对AOF进行重写。重写的新AOF文件包含恢复当前数据所需的最小命令集合。重写操作非常安全,因为Redis 在创建新 AOF 文件的过程中,会继续将命令追加到现有的 AOF 文件里面,即使重写过程中发生停机,现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕,Redis 就会从旧 AOF 文件切换到新 AOF 文件,并开始对新 AOF 文件进行追加操作。
- AOF日志包含了所有写操作,便于Redis解析恢复。例如执行了flushall/flushdb操作,删除了所有数据,只需要停止Redis服务器,删除AOF末尾的删除命令,再重启Redis即可恢复到flush操作之前的状态。
扩展:RDB模式下,如果误操作删除了所有数据,重启后也会恢复吗?
备份数据也会跟着同步,数据无法恢复。
- 劣势
- 相同的数据,AOF比RDB体积大
- 某些同步机制下,AOF比RDB慢。秒级备份略低于RDB,每次写入备份,影响性能。
- 以前AOF发生过bug,就是通过AOF记录的日志,进行数据恢复的时候,没有恢复一模一样的数据出来。不过AOF为了重写过程导致bug,每次重写不是基于旧的指令日志进行merge,而是当前缓存的指令重构,更加健壮。
2.2 AOF的配置
## APPEND ONLY MODE
# AOF默认关闭 yes开启
appendonly no
# 指令日志文件名
appendfilename "appendonly.aof"
# 同步策略
# appendfsync always 每次写入备份,安全数据完整,性能差
appendfsync everysec 每秒备份,推荐
# appendfsync no
# 重写的时候是否要同步 no可以保证数据安全
no-appendfsync-on-rewrite no
# 重写机制:避免文件越来越大,自动优化压缩指令,会fork一个新的进程去完成重写动作,新进程里的内存数据会被重写,此时旧的aof文件不会被读取使用,类似rdb
# Redis会记录上一次重写的大小(或者启动初始值)。当前AOF文件的大小是上次AOF大小的100% 并且文件体积达到64m,满足两者则触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# redis在恢复时,会忽略最后一条可能存在问题的指令。默认值yes
aof-load-truncated yes
# 重启redis恢复数据时,使用混合持久化。 redis5默认yes
aof-use-rdb-preamble yes
3 RDB和AOF的选择
RDB会有一段时间的缓存丢失,AOF实时性较好。
通常同时开启RDB和AOF持久化,RDB做冷备,可以在不同时期对不同版本做恢复;AOF做热备,保证数据只有1秒的损失。当AOF破损不可用时,再用RDB恢复。Redis恢复时,先加载AOF,如果AOF有问题再加载RDB,达到冷热互备。
为什么RDB恢复比AOF恢复快?
RDB,是数据文件,恢复时直接加载到内存既可以。而AOF是指令日志,做恢复时,其实是执行所有写操作恢复数据。
参考
http://www.redis.cn/topics/persistence.html
内容总结
以上是互联网集市为您收集整理的Redis持久化机制与选择全部内容,希望文章能够帮你解决Redis持久化机制与选择所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。