“Redis 持久化”的版本间的差异
跳到导航
跳到搜索
Jihongchang(讨论 | 贡献) |
Jihongchang(讨论 | 贡献) |
||
第18行: | 第18行: | ||
执行快照保存的时间点尽量在访问量少的时间 | 执行快照保存的时间点尽量在访问量少的时间 | ||
+ | |||
+ | 配置<syntaxhighlight lang="console"> | ||
+ | save 900 1 | ||
+ | save 300 10 | ||
+ | save 60 10000 | ||
+ | </syntaxhighlight> | ||
+ | after 900 sec (15 min) if at least 1 key changed | ||
+ | |||
+ | after 300 sec (5 min) if at least 10 keys changed | ||
+ | |||
+ | after 60 sec if at least 10000 keys changed | ||
+ | |||
+ | |||
2023年2月19日 (日) 04:13的版本
Redis 虽然是内存数据库,但为了在重启之后仍然可以提供数据也提供了4种持久化方案:
- RDB
- AOF
- 不持久化
- RDB+AOF
值得一提的是这些方案也各有优缺点,需要在使用的时候根据需要选择方案
RDB
RDB(Redis Database),以指定的时间间隔执行保存数据集的时间点快照。
优点:服务重启时加载速度快
缺点:因为是周期间隔进行快照保存,所以如果在两次快照之间出现的增量数据可能会丢失
执行快照保存的时间点尽量在访问量少的时间
配置
save 900 1
save 300 10
save 60 10000
after 900 sec (15 min) if at least 1 key changed
after 300 sec (5 min) if at least 10 keys changed
after 60 sec if at least 10000 keys changed
AOF
AOF(Append Only File),不停记录服务器收到的每个写操作,然后在服务器启动时重新执行这些写操作以重建原始数据,使用与 Redis 协议本身相同的格式记录命令。
优点:每一个发送到服务器的写操作都会被记录,几乎不丢数据或者丢的很少
缺点:服务重启时加载的是所有写操作的 history,这个量可能会很大,执行时间会比较久