Redis：8.Redis持久化

2020-04-09 阅读量

Redis持久化

Redis是内存数据库，如果不将内存中的数据保存到磁盘，那么一旦服务器进程退出，Redis数据库中保存的数据也会消失。所以Redis提供了持久化功能。

1.RDB（Redis DataBase）

什么是RDB？
在指定的时间间隔内将内存中的数据集体快照写入磁盘中，行话叫Snapshot快照，它恢复时是将快照文件直接读到内存中。
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，等持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不会进行任何IO操作的，确保了极高的性能。
如果需要进行大规模的数据恢复，且对于数据恢复的完整性不是非常敏感，那RDB要比AOF更加高效。
默认使用的就是RDB，一般情况下不需要修改此配置。
在生产环境中，会将rdb文件备份，防止其丢失而造成不必要的损失。
RDB保存的文件：dump.rdb （在配置文件中可以进行修改）
加载图片！

测试：修改配置文件
加载图片！

# 1.先删除原来的 dump.rdb 文件

# 在Redis数据库界面执行以下代码。
# 在一分钟内设置5个key
set k1 aa
set k2 bb
set k3 cc
set k4 dd
set k5 ee
shutdown  # 关闭Redis数据库
exit      # 退出

# 这时候会发现生成的dump.rdb 文件

# 重新启动Redis 查看上面设置的key是否还在
redis-server myconfig/redis.config  # 启动时要跟上配置文件
redis-cli -p 6379     # 连接Redis 
get k1                # 返回"aa"

RDB文件什么时候生成

配置文件中的save条件满足的时候，会自动生成rdb文件。
执行flushall 命令，会生成rdb文件。
退出redis，也会生成rdb文件。

如何恢复RDB文件

只需要将rdb文件放在 Redis配置文件中配置的rdb目录下即可，Redis启动时会自动检查dump.rdb文件，恢复其中的数据。
查看配置文件中rdb的存放路径：

# 在Redis客户端输入
config get dir
1) "dir"
2) "/usr/local/bin"  # 即此目录下

RDB优缺点

优点：

适合大规模的数据恢复。
若对数据的完整性要求不高，可以使用RDB。

缺点：

需要一定的时间间隔进行操作。
如果Redis意外宕机，最后一次修改的数据可能会丢失。
fork进程的时候，会占用一定的内存空间。

2.AOF（Append Only File）

将所有的命令都记录下来，相当于history，恢复的时候就把这文件里面的命令全部执行一遍。
以日志的形式记录每个写的操作，将Redis执行过的所有命令记录下来（读操作不记录），只许追加文件但不可改写文件。
Redis启动之初会读取该文件重新构建数据，即Redis重启的话就根据日志文件的内容，将写命令从前到后执行一次，以完成数据的恢复工作。

AOF保存的文件：appendonly.aof （在配置文件中可以进行修改）

加载图片！
测试：
1.aof默认是不开启的，需要在配置文件中手动开启。配置完重启就会生效。

# 开启aof
appendonly yes

# 配置持久化策略 （默认即可） sync：同步
appendfsync everysec  # 每秒执行一次sync (可能会丢失这1S的数据)
# appendfsync always  # 每次修改都会sync (消耗性能)
# appendfsync no      # 不执行sync，这时操作系统同步数据，速度最快

# 重写时 是否用append （默认即可）
no-appendfsync-on-rewrite no

# 重写规则 （默认即可）
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

2.重写规则说明：

1 2	# 重写规则 auto-aof-rewrite-min-size 64mb

aof默认就是文件的无限追加，文件会越来越大。
如果aof文件大于配置的64M，会触发重写机制，fork一个新的进程，将aof文件进行重写。

3.测试

# 1.先删除原来的 appendonly.aof 文件

# 在Redis数据库界面执行以下代码。
set k1 aa
set k2 bb
set k3 cc
get k4
shutdown  # 关闭Redis数据库
exit      # 退出

# 这时候会发现生成的dump.rdb 文件

4.测试appendonly.aof文件的修复机制

vim打开刚才生成的文件，在任意位置随便打些字符，破坏掉此文件。保存退出。
启动Redis服务端。
Redis客户端连接Redis（会发现报错：连接失败的错误提示）
说明如果aof文件有问题，Redis是启动不起来的。

Redis提供了一个修复aof的工具：redis-check-aof (在Redis的安装目录下，是一个可执行文件)

在终端中输入以下命令进行修复（注意不是在Redis中）

redis-check-aof --fix

# 提示修复成功后，打开appendonly.aof文件，会发现随便添加的那些字符已经不在了。
# 修复成功后，Redis可正常运行了。

AOF优缺点

优点：

每一次修改都同步，文件的完整性会更好。
如果配置为从不同步appendfsync no：效率最高

缺点：

相对于数据文件来说，aof远远大于rdb，修复速度也比rdb慢。
默认每秒同步一次，可能会丢失最后一秒的数据。
aof运行效率也要比rdb慢，所以Redis默认的持久化配置就是rdb。

总结

在主从复制中，rdb是用来备用的（放在从机上面）。
通过aof-use-rdb-preamble配置参数控制，做rdb与aof混合持久化。
RDB 持久化方式能够在指定的时间间隔内对你的数据进行快照存储。
AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以Redis 协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大。
只做缓存，如果你只希望你的数据在服务器运行的时候存在，也可以不使用任何持久化。
同时开启两种持久化方式
- 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
- RDB 的数据不实时，同时使用两者时服务器重启也只会找AOF文件，那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启，而且不会有AOF可能潜在的Bug，留着作为一个万一的手段。

性能建议

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