Redis持久化
* Redis主要是工作在内存中。
* 内存本身就不是一个持久化设备,断电后数据会清空。
* 所以Redis在工作过程中,如果发生了意外停电事故,如何尽可能减少数据丢失。
持久化方式
* RDB (Relational Database)
* AOF (Append Of File)
一. RDB
1. RDB简介
RDB:在指定的时间间隔内将内存中的数据集快照写入磁盘,
也就是行话讲的 Snapshot 快照,它恢复时是将快照文件直接读到内存里。
2. 工作机制:
每隔一段时间,就把内存中的数据保存到硬盘上的指定文件中。
3. RDB 是默认开启的!
4. 操作过程
Redis 会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,
待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何 IO 操作的,
这就确保了极高的性能如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那 RDB 方式要比 AOF 方式更加的高效。
5. RDB 的缺点是最后一次持久化后的数据可能丢失。
6. RDB 数据丢失的情况:
两次保存的时间间隔内,服务器宕机,或者发生断电问题。
二. AOF
1. AOF简介
AOF是以日志的形式来记录每个写操作,将每一次对数据进行修改,
都把新建、修改数据的命令保存到指定文件中。
Redis 重新启动时读取这个文件,重新执行新建、修改数据的命令恢复数据。
2. 默认不开启,需要手动开启
3. AOF文件的保存路径,同RDB的路径一致。
4. AOF在保存命令的时候,只会保存对数据有修改的命令,也就是写操作!
5. 当RDB和AOF存的不一致的情况下,按照AOF来恢复。因为AOF是对RDB的补充。
备份周期更短,也就更可靠。
备份建议
1. 如何看待数据“绝对”安全
Redis 作为内存数据库从本质上来说,如果不想牺牲性能,就不可能做到数据的“绝对”安全。
RDB 和 AOF 都只是尽可能在兼顾性能的前提下降低数据丢失的风险,如果真的发生数据丢失问题,尽可能减少损失。
2. 在整个项目的架构体系中,Redis大部分情况是扮演“二级缓存”角色。
3. 二级缓存适合保存的数据:
经常要查询,很少被修改的数据。
不是非常重要,允许出现偶尔的并发问题。
不会被其他应用程序修改。
4. 如果 Redis 是作为缓存服务器,那么说明数据在 MySQL 这样的传统关系型数据库中是有正式版本的。数据最终以 MySQL 中的为准。
官方建议
官方推荐两个都用;
如果对数据不敏感,可以选单独用RDB;
不建议单独用AOF,因为可能出现Bug;
如果只是做纯内存缓存,可以都不用;