众所周知,redis的强劲性很大程度是因为将数据存储在了内存中,这样的优点显而易见,读取速度快;但是缺点也比较明显,过分依赖、占用内存,当redis重启后,存储在内存中的数据就会丢失。这时候就需要掌握一门新的技巧--redis持久化。
redis持久化方式
- RDB方式
根据指定规则,定时将内存中的数据存储在硬盘上。
- AOF方式
每次执行命令后将命令本身记录在硬盘上。
下面我们来详细了解下这两种持久化方式。
RDB方式
保存方式:文件快照(dump.rdb 文件)。
什么情况下会保存快照呢?
1、根据配置规则进行自动快照。
- 保存快照的触发条件可以在配置文件中设置,两个重要的参数:M 时间,单位是 s,N 键的个数。例如:save 300 6 表示300秒内有6个键被修改则进行快照。
- 快照可以存在多个触发条件,多个条件之间的关系为 ‘或’。
2、用户执行 SAVE 或 BGSAVE 命令。
- 执行 SAVE 命令会同步保存快照,但是阻塞来自客户端的请求。
- 推荐使用 BGSAVE 命令,后台异步进行快照。
3、执行 FLUSHALL 命令。
- 执行 FLUSHALL 命令时,会清楚数据库中的所有数据,若存在快照触发保存条件,即使没达到条件的限制,也会保存快照。
4、执行复制时。
- 使用主从模式,复制初始化时会进行快照生成。
优缺点。
RDB文件是经过压缩的二进制格式,占用空间会小于内存中的数据大小;
redis 异常退出,会丢失最后一次快照以后更改的所有数据。
AOF方式
默认情况下 AOF 没有打开,可以通过 appendonly yes 命令来开启。AOF 会将 redis 执行的每一条命令都追加到硬盘中,显然会影响 redis 性能,综合考虑后使用。
保存方式:appendonly.aof 文件。
AOF 重写
- 可以通过配置文件的设置来达到重写 AOF 文件的目的。
- 手动执行 BGREWRITEAOF 命令来重写 AOF 文件。
注:由于操作系统的缓存机制问题,AOF 数据并没有真正的写入硬盘,而是记录在了系统的硬盘缓存中,然后系统默认每 30s 向硬盘同步一次。redis 中可以通过配置 appendfsync 参数来设置同步时机。
备注
- 不管是 RDB 快照重新生成,还是 AOF 文件的重写,只和内存中的数据有关,和之前生成的文件无关。
- redis 允许同时开启 RDB 和 AOF,同时启动后,redis重新启动会优先使用 AOF 文件来恢复数据。