Redis使用总结

数据持久化 快照 缺省情况情况下，Redis把数据快照存放在磁盘上的二进制文件中，文件名为dump.rdb。你可以配置Redis的持久化策略，例如数据集中每N秒钟有超过M次更新，就将数据写入磁盘；或者你可以手工调用命令SAVE或BGSAVE。 例子：要求如果每60秒有超过10

数据持久化

快照

缺省情况情况下，Redis把数据快照存放在磁盘上的二进制文件中，文件名为dump.rdb。你可以配置Redis的持久化策略，例如数据集中每N秒钟有超过M次更新，就将数据写入磁盘；或者你可以手工调用命令SAVE或BGSAVE。
例子：要求如果每60秒有超过1000条记录被更新，就自动将数据写到磁盘上，可以用下面的命令

SAVE 60 1000

这种策略称为快照。

工作原理

这种方式可以使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.

当AOF文件被破坏时该怎么办？

有可能在写AOF时Redis崩溃，已破坏的文件不能被Reids使用。要解决这个问题参考下面的步骤：

$ redis-check-aof --fix 

工作机制

日志重写和快照模式使用了相同的copy-on-write机制。