redis如果将数据仅缓存在内存里面,一旦redis挂了重启,数据就全部丢失了,像RabbitMQ一类的针对这种情况都提供了持久化机制,当然redis肯定也是有自己的持久化机制。
redis提供了两种持久化方式
- RDB:对redis中的数据执行周期性的持久化(默认存储到dump.rdb文件)
//参考配置
save 900 1 #900秒内如果至少有1次key发生了变化,就执行持久化
save 300 10 #300秒内如果至少有10次key发生了变化,就执行持久化
save 60 10000 #含义同上
dbfilename dump.rdb #持久化的文件名
- AOF:对每条写入命令做日志,以 append-only 的模式写入一个日志文件中(默认写入到appendonly.aof文件),redis在重启的时候通过回放 AOF 日志中的写入指令来重新构建整个数据集
//参考配置:
appendonly yes #开启aof持久化
appendfilename "appendonly.aof" #aof持久化的日志文件名
appendfsync everysec #每秒flush一次系统内存将日志数据存储到磁盘
如果同时使用 RDB 和 AOF 两种持久化机制,那么在 redis 重启的时候,会使用 AOF 来重新构建数据,因为 AOF 中的数据更加完整 ,如下面在启动 redis 时输出的 DB loaded from append only file: 7.335 seconds 这一行。
D:\redis>redis-server.exe redis.windows.conf
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 3.2.100 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in standalone mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 6379
| `-._ `._ / _.-' | PID: 1336
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
[1336] 02 Nov 08:37:59.708 # Server started, Redis version 3.2.100
[1336] 02 Nov 08:38:07.046 * DB loaded from append only file: 7.335 seconds
[1336] 02 Nov 08:38:07.046 * The server is now ready to accept connections on port 6379
[1336] 02 Nov 08:39:00.004 * 10000 changes in 60 seconds. Saving...
[1336] 02 Nov 08:39:00.014 * Background saving started by pid 4536
[1336] 02 Nov 08:39:01.621 # fork operation complete
[1336] 02 Nov 08:39:01.621 * Background saving terminated with success
RDB的优缺点
优点
- RDB 会生成多个数据文件,每个数据文件都代表了某一个时刻中 redis 的数据,这种多个数据文件的方式,非常适合做冷备,可以将这种完整的数据文件发送到一些远程的安全存储上去,以预定好的备份策略来定期备份 redis 中的数据。
- RDB 对 redis 对外提供的读写服务,影响非常小,可以让 redis 保持高性能,因为 redis 主进程只需要 fork 一个子进程,让子进程执行磁盘 IO 操作来进行 RDB 持久化即可。
- 相对于 AOF 持久化机制来说,直接基于 RDB 数据文件来重启和恢复 redis 进程,更加快速。
缺点
- redis 故障时,由于周期性持久化的存在时间间隔的问题,可能会丢失间隔时间内产生的数据,这一点上 RDB 没有 AOF 好。
- RDB 每次在 fork 子进程来执行 RDB 快照数据文件生成的时候,如果数据文件特别大,可能会导致对客户端提供的服务暂停数毫秒,或者甚至数秒。
AOF的优缺点
优点
- AOF 可以更好的保护数据不丢失,一般从效率和安全方面综合考虑设置 AOF 每隔 1 秒通过一个后台线程执行一次fsync操作,最多丢失 1 秒钟的数据。
- AOF 日志文件以 append-only 模式写入,所以没有任何磁盘寻址的开销,写入性能非常高,而且文件不容易破损,即使文件尾部破损,也很容易修复。
- AOF 日志文件即使过大的时候,出现后台重写操作,也不会影响客户端的读写。因为在 rewrite log 的时候,会对其中的指令进行压缩,创建出一份需要恢复数据的最小日志出来。在创建新日志文件的时候,老的日志文件还是照常写入。当新的 merge 后的日志文件 ready 的时候,再交换新老日志文件即可。
- AOF 日志文件的命令可读性很强,非常适合做灾难性的误删除的紧急恢复。
缺点
- 对于同一份数据来说,AOF 日志文件通常比 RDB 数据快照文件更大。
- AOF 开启后,支持的写 QPS 会比 RDB 支持的写 QPS 低,因为 AOF 一般会配置成每秒 fsync 一次日志文件,当然,每秒一次 fsync,性能也还是很高的。(如果实时写入,那么 QPS 会大降,redis 性能会大大降低)
RDB 和 AOF的选择
- 不要仅仅使用 RDB,那样会导致丢失很多数据。
- 也不要仅仅使用 AOF,因为那样有两个问题:第一,你通过 AOF 做冷备,没有 RDB 做冷备来的恢复速度更快;第二,RDB 每次简单粗暴生成数据快照,更加健壮,可以避免 AOF 这种复杂的备份和恢复机制的 bug。
- redis 支持同时开启开启两种持久化方式,我们可以综合使用 AOF 和 RDB 两种持久化机制,用 AOF 来保证数据不丢失,作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备,在 AOF 文件都丢失或损坏不可用的时候,还可以使用 RDB 来进行快速的数据恢复。