Redis学习之持久化_redis 持久化学习-CSDN博客

redis会单独创建(fork)一个子线程来进行持久化，会先将数据写入一个临时的文件中，持久化的过程结束后，再用这个临时文件替换上次持久化好的文件。整个过程，主线程是不进行如何io操作的。这就确保了极高的性能。如果需要进行大规模的恢复，且对于数据恢复的完整性不是特别敏感，那么RDB比ROF更加高效，RDB的缺点就是最后一次的数据可能丢失

RDB的配置

在配置文件的SNAPSHOTTING环节可以进行设置RDB持久化的具体规则

#  规则
save 3600 1        # 在3600秒内修改一次，就保存
save 300 100       # 在300秒内修改100次，就保存 
save 60 10000    # 在60秒内修改10000次，就保存 


# 文件生成
dbfilename dump.rdb    # RDB持久化生成的文件名

触发机制

- save 的规则满足的情况下，会自动触发rdb规则

- 执行 flushall 命令也会触发我们的rdb规则

- 退出redis，也会产生rdb文件

恢复

1、只需要将rdb文件放入我们redis启动的目录就可以，redis启动的时候会自动检查dump.rdb，并自动恢复其中的数据！

2、查看需要存储的位置

127.0.0.1:7369> config get dir
1) "dir"
2) "/usr/local/bin"

优缺点

- 优点：

1、适合大规模的数据恢复

2、对数据的完整性要求不高

- 缺点：

1、需要一定的时间间隔进程操作！如果redis意外宕机了，最后修改的数据就没有了

2、fork会占用一定的时间，会占用一定的内容空间！

——————————————————————————————————————————————————————————————

AOF

什么是AOF

将我们所有的命令记录下来，history，恢复的时候就把这个文件全部执行一遍！

作用

以日志的形式记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以修改文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作！

配置文件

具体配置

appendonly no    # 是否开启aof，默认不开启

appendfilename "appendonly.aof"    # aof 存储文件名称，不建议修改


# 保存方式
appendfsync always    # 每次都保存

appendfsync everysec    # 每一秒保存一次

appendfsync no          # 不保存

no-appendfsync-on-rewrite no    # 是否进行重写

# 自动重写的规则
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

测试

127.0.0.1:7369> ping
PONG
127.0.0.1:7369> set k1 v1
OK
127.0.0.1:7369> set k2 v2
OK
127.0.0.1:7369> set k3 v3
OK
127.0.0.1:7369> set k4 v4
OK

查看aof文件

如果说 appendonly.aof 有错误，那么可以在启动目录使用 redis-check-aof 进行修复

如果文件正常，重启后就可以直接恢复了

优缺点

- 优点：

1、每一次修改都同步，数据的完整性相对于rdb相对好一些

2、每秒同步一次，可能丢失一秒的数据

3、从不同步，效率最高

- 缺点：

1、相对于数据文件来说，aof远远大于rdb，修复速度也比rdb慢

2、aof运行效率也要比rdb慢，所以我们redis默认的配置就是rdb持久化！！

扩展

1、RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储

2、AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。

3、只做缓存，如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化

4、同时开启两种持久化方式
- 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
- RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢?作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。

5、性能建议

- 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save9001这条规则。
- 如果EnableAOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOFrewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOFrewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。
- 如果不Enable AOF，仅靠Master-SlaveRepllcation实现高可用性也可以，能省掉一大笔10，也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个，微博就是这种架构。