重生陆如萍,肖克车,03式自动步枪
redis 如同其他的存储组件一样，提供了两类持久化方式：快照，和全量追加日志。
在默认情况下， redis 将数据库快照保存在名字为dump.rdb的二进制文件中。
你可以对 redis 进行设置， 让它在“ n 秒内数据集至少有 m 个改动”这一条件被满足时， 自动保存一次数据集。
你也可以通过调用 save或者 bgsave ， 手动让 redis 进行数据集保存操作。
这种持久化方式被称为快照 snapshotting.
我要评论save：暂停服务，写dump.rdb，比如停止时执行
bgsave ：通过fork系统调用创建子进程写 dump.rdb
# 配置写入策略（针对bgsave）： save 900 1 #（900秒内至少1个key被写） save 300 10 #（300秒内至少10个key被写） save 60 10000 #（60秒内至少1000个key被写） # 如果不需要rdb,可以设置： save "" # 设置 rdb 文件名称 和 存储目录 dbfilename dump.rdb dir /var/lib/redis/6379
快照功能并不是非常耐久（durable）： 如果 redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。
从 1.1 版本开始， redis 增加了一种完全耐久的持久化方式： aof 持久化。
appendonly yes #（开启aof） appendfilename "appendonly.aof"
每当 redis 执行一个改变数据集的命令时（比如 set）， 这个命令就会被追加到 aof 文件的末尾。
这样的话， 当 redis 重新启时， 程序就可以通过重新执行 aof 文件中的命令来达到重建数据集的目的。
你可以配置 redis 多久才将数据 fsync 到磁盘一次。有三种方式：
# fsync同步刷盘策略 # appendfsync always #（立刻同步刷盘，最慢，也最安全） appendfsync everysec #（每秒才触发一次同步刷盘，推荐） # appendfsync no # （不采用同步刷盘，最快，相对不安全）
因为 aof 的运作方式是不断地将命令追加到文件的末尾， 所以随着写入命令的不断增加， aof 文件的体积也会变得越来越大。
举个例子， 如果你对一个计数器调用了 100 次 incr ， 那么仅仅是为了保存这个计数器的当前值， aof 文件就需要使用 100 条记录（entry）。
然而在实际上， 只使用一条 set 命令已经足以保存计数器的当前值了， 其余 99 条记录实际上都是多余的。
为了处理这种情况， redis 支持一种有趣的特性： 可以在不打断服务客户端的情况下， 对 aof 文件进行重建（rebuild）。
执行 bgrewriteaof 命令， redis 将生成一个新的 aof 文件， 这个文件包含重建当前数据集所需的最少命令。
# 配置：aof文件每次增长指定大小的百分比后，就会触发bgrewriteaof auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb
从 redis 4.0 开始，aof重写逻辑变动了：
fork写入 aof文件的头部
如对本文有疑问，请在下面进行留言讨论，广大热心网友会与你互动！！ 点击进行留言回复
理解Redis持久化，RDB持久化和AOF持久化的不同处理方式
Redis 两类持久化方式，快照和全量追加日志的不同处理方式
网友评论