数据持久化 快照 缺省情况情况下，redis把数据快照存放在磁盘上的二进制文件中，文件名为dump.rdb。你可以配置redis的持久化策略，例如数据集中每n秒钟有超过m次更新，就将数据写入磁盘；或者你可以手工调用命令save或bgsave。 例子：要求如果每60秒有超过10
数据持久化 快照缺省情况情况下，redis把数据快照存放在磁盘上的二进制文件中，文件名为dump.rdb。你可以配置redis的持久化策略，例如数据集中每n秒钟有超过m次更新，就将数据写入磁盘；或者你可以手工调用命令save或bgsave。
例子：要求如果每60秒有超过1000条记录被更新，就自动将数据写到磁盘上，可以用下面的命令
save 60 1000
这种策略称为快照。
工作原理
- redis forks.
- 子进程开始将数据写到临时rdb文件中。
- 当子进程完成写rdb文件，用新文件替换老文件。
这种方式可以使redis使用copy-on-write技术。
append-only文件
快照模式并不十分健壮，当系统停止，或者无意中redis被kill掉，最后写入redis的数据就会丢失。这对某些应用也许不是大问题，但对于要求高可靠性的应用来说，redis就不是一个合适的选择。
append-only文件模式是另一种选择。
你可以在配置文件中打开aof模式：
appendonly yes
每次redis接收到修改请求(set)，就会将数据写入aof尾部。当重启redis时，redis会回放aof中的内容。
log重写
aof文件会随着写操作而变得越来越大。所以redis支持一个有趣的特性：redis可以在后台重建aof，同时不会中断对前端的服务。当执行命令bgrewriteaof，redis会在内存中写出拥有重建数据的最少的命令序列。如果你使用aof，你应该经常地运行bgrewriteaof。
aof能做到多大程度的持久化？
你可以配置redis多长时间将数据fsync到磁盘上，有3种选择：
- 每次有更新命令就执行fsync，这种方式非常慢，但非常安全。
- 每秒钟执行一次fsync，这种方式足够快，但是有可能丢失一秒钟的数据。
- 永远不执行fsync，有操作系统控制，这种方式更快，也更不安全。
建议的策略（缺省）是每秒钟执行一次fsync.
当aof文件被破坏时该怎么办？
有可能在写aof时redis崩溃，已破坏的文件不能被reids使用。要解决这个问题参考下面的步骤：
- 备份你的aof文件
- 用redis-check-aof修复你的原始文件
$ redis-check-aof --fix
- 使用diff -u 检查两个文件的差异（可选）
- 使用修复后的文件重启redis
日志重写和快照模式使用了相同的copy-on-write机制。
- redis forks
- 子进程开始写新的aof文件到一个临时文件中
- 父进程将新的更新命令保存在内存中（同时将这些更新写到老的aof文件）
- 当子进程完成写文件，父进程得到信号，将更新写到子进程创建的aof文件
- redis自动将aof文件改名，使用新的aof文件
【说明】：本文章由站长整理发布，文章内容不代表本站观点，如文中有侵权行为，请与本站客服联系(QQ:)！