江苏龙网

  1. 首页 > 人文 > >

5分钟理解Redis持久化

上一篇我们学习了Redis的核心数据结构以及应用场景 ， 本篇来学习一下Redis持久化 。
一、RDB快照（snapshot）RDB是一种快照存储持久化方式 ， 具体就是将Redis某一时刻的内存数据保存到硬盘的文件当中 ， 默认保存的文件名为dump.rdb ， 而在Redis服务器启动时 ， 会重新加载dump.rdb文件的数据到内存当中恢复数据 。
默认情况下 ，Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中 。 你可以对 Redis 进行设置 ，让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时 ，自动保存一次数据集 。
比如说 ，以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时 ，自动保存一次数据集：
# save 60 1000关闭RDB只需要将所有的save保存策略注释掉即可 。
还可以手动执行命令生成RDB快照 ， 进入redis客户端执行命令save或bgsave可以生成dump.rdb文件 ， 每次命令执行都会将所有redis内存快照到一个新的rdb文件里 ， 并覆盖原有rdb快照文件 。
【5分钟理解Redis持久化】save是同步命令 ， bgsave是异步命令 ， bgsave会从redis主进程fork（fork()是linux函数）出一个子进程专门用来生成rdb快照文件 。
save与bgsave对比：
5分钟理解Redis持久化文章插图
配置自动生成rdb文件后台使用的是bgsave方式 。
快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机 ，那么服务器将丢失最近写入、且仍未保存到快照中的那些数据 。
二、AOF（append-only file）从 1.1 版本开始 ，Redis 增加了一种完全耐久的持久化方式： AOF 持久化 ， 将修改的每一条指令记录进文件appendonly.aof中 。
你可以通过修改配置文件来打开 AOF 功能：
# appendonly yes从现在开始 ，每当 Redis 执行一个改变数据集的命令时（比如 SET） ，这个命令就会被追加到 AOF 文件的末尾 。
这样的话 ，当 Redis 重新启动时 ，程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的 。
你可以配置 Redis 多久才将数据 fsync 到磁盘一次 。 有三个选项：
# appendfsync always：每次有新命令追加到 AOF 文件时就执行一次 fsync， 非常慢 ， 也非常安全 。 appendfsync everysec：每秒 fsync 一次 ， 足够快（和使用 RDB 持久化差不多） ， 并且在故障时只会丢失 1 秒钟的数据 。 # appendfsync no：从不 fsync， 将数据交给操作系统来处理 。 更快 ， 也更不安全的选择 。 推荐（并且也是默认）的措施为每秒 fsync 一次 ，这种 fsync 策略可以兼顾速度和安全性 。
AOF重写AOF文件里可能有太多没用指令 ， 所以AOF会定期根据内存的最新数据生成aof文件例如 ， 执行了如下几条命令：
1 127.0.0.1:6379> incr readcount2 (integer) 13 127.0.0.1:6379> incr readcount4 (integer) 25 127.0.0.1:6379> incr readcount6 (integer) 37 127.0.0.1:6379> incr readcount8 (integer) 49 127.0.0.1:6379> incr readcount10 (integer) 5重写后AOF文件里变成
1 *32 $33 SET4 $25 readcount6 $17 5如下两个配置可以控制AOF自动重写频率
# auto-aof-rewrite-min-size 64mb //aof文件至少要达到64M才会自动重写 ， 文件太小恢复速度本来就很快 ， 重写的意义不大 。 # auto-aof-rewrite-percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写 。 当然AOF还可以手动重写 ， 进入redis客户端执行命令bgrewriteaof重写AOF 。
注意 ， AOF重写redis会fork出一个子进程去做 ， 不会对redis正常命令处理有太多影响 。


推荐阅读


上一篇：大揭秘！联想手机从昔日巅峰走到如今只剩品牌躯壳

下一篇：企业|如何利用数据大屏分析来推动智能化管理？