redis持久化
持久化简介
redis是内存数据库,如果不将内存中的数据保存到磁盘,那么一旦服务器进程退出,服务器中的数据状态也会消失,所以redis提供了持久化的功能。
基本原理
原理是redis会单独创建(fork)一个与当前线程一模一样的子进程来进行持久化,这个子线程的所有数据(变量。环境变量,程序程序计数器等)都和原进程一模一样,会先将数据写入到一个临时文件中,待持久化结束了,再用这个临时文件替换上次持久化好的文件,整个过程中,主进程不进行任何的io操作,这就确保了极高的性能。
两种持久化方式
redis提供两种持久化方式:
- RDB(redis database)持久化:将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化。
- AOF(append only file)持久化:将Reids的操作日志以追加的方式写入文件。
RDB
redis默认的就是RDB,一般情况下不需要修改这个配置。 如果需要进行大规模数据恢复,且对于数据的完整性恢复不是非常的敏感,那么RDB方式比AOF的方式更加高效。RDB的缺点是最后一次持久化的数据可能会丢失。
RDB保存文件
RDB操作会保存在dump.rdb 中。 该文件在redis的src 目录下。
RDB配置文件
RDB的相关配置在redis.conf 中的SNAPSHOTTING (快照)部分中。
触发RDB操作的设置默认是这样的:
# 第一句的含义是3600秒内修改1次key,就会触发RDB操作
save 3600 1
save 300 100
save 60 10000
可以根据实际的需求自定义修改。
RDB触发机制
- 1.满足save规则。
- 2.执行flushdb命令。
- 3.退出redis,都会产生rdb文件。
恢复RDB文件
只需要将rdb文件放在redis启动目录就可以,redis启动时就会自动检测dum.rdb文件,恢复其中数据。
优缺点
优点:
- 适合大规模的数据恢复。
- 对数据的完整性要求不高。
缺点:
- 需要一定时间间隔进程操作,如果redis意外宕机,这个最后一次修改的数据就没了。
- fork进程的时候,会占用一定的内存空间。
功能展示
cd src
rm -f dump.rdb
redis-server ../tmpconfig/redis.conf
redis-cli -p 6379
设置5次key,然后执行save。
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379> set k5 v5
OK
切换到src目录下查看:
发现生成了dump.rdb 文件。
执行vim dump.rdb 查看:
AOF
AOF操作以日志的形式来记录每一个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件不许改写文件。 如果redis重启就会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
AOF保存文件
AOF保存的文件是appendonly.aof ,同样在src 目录下。
AOF配置文件
AOF的相关配置在redis.conf 中的APPEND ONLY MODE 部分中。
AOF操作默认为no ,需要手动开启:
将appendonly 属性设置为yes 即可。
aof文件错位
如果aof 文件有错位,这时候redis启动不起来,我们需要修复配置文件,redis给我们提供了一个工具:
redis-check-aof --fix appendonly.aof
优缺点
优点:
- 该机制可以带来更高的数据安全性,即数据持久性。
- 由于该机制对日志文件的写入操作采用的是append模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。
- OF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上,我们也可以通过该文件完成数据的重建。
缺点:
- 相对于rdb,aof远大于rdb,修复速度也比rdb慢。
- aof运行效率也比rdb慢,因此默认rdb操作。
功能展示
首先需要开启AOF操作。
然后开启redis服务,三次写操作,一次读操作:
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> get k3
"v3"
直接切换到src目录查看:
发现生成了appendonly.aof 文件。
打开查看:
只记录了写操作,没有记录读操作。
|