持久化机制
尽管 Redis 是基于内存的 key-value 服务，但也可以进行数据的持久化，以便服务重启，数据能重新加载进来。
为了尽可能的保证数据不丢失，Redis 为我们提供了好几种持久化机制：
- RDB：即 Redis Database，在指定的时间间隔里将 Redis 内存数据镜像下来，保存到文件里。
- AOF：将服务器对数据的写操作追加到文件里，相当于将所有的逻辑操作都记录了下来。
- 无持久性：不进行持久化，性能最好。
- RDB + AOF：将 RDB 和 AOF 结合起来，组合它们各自的优点。
下面，我们来看看这些机制吧。
RDB 配置
在 redis.conf 文件里我们可以针对 RDB 持久化方式进行设置：
### 快照设置 ###
# save "" 空表示不进行持久化
save 900 1 # 900 秒内如果有1个 key 值改变，则进行持久化动作
save 300 10 # 300 秒内如果有10个 key 值改变，则进行持久化动作
save 60 10000 # 60 秒内如果有10000个 key 值改变，则进行持久化动作
# 如果持久化失败，则 Redis 不会再进行数据更新操作，直到恢复正常
stop-writes-on-bgsave-error yes
# 是否对持久化的 rdb 文件进行压缩保存
rdbcompression yes
# 是否对持久化的 rdb 文件进行校验
rdbchecksum yes
# 要持久化的 rdb 文件名
dbfilename example.rdb
# 导出目录
dir /opt/redisdata
RDB 优势
-
当 Redis 进行持久化动作时，它会先 fork 一个子进程，将数据的写入交给子进程，而父进程不会涉及到磁盘的 IO 操作，所以 RDB 的性能非常好。
-
如果是在 Unix 系统上，还能充分利用写时复制机制。也就是子进程和父进程共用相同的内存页面，只有当子进程或父进程进行修改才会进行复制。这样节省了对物理内存的使用。
-
由于 RDB 文件只存储了某个时刻的内存数据，并没有什么逻辑命令，所以在进行重启恢复时，能很快的加载进来。
RDB 缺点
-
虽然 RDB 的 fork 能使得 Redis 的持久化独立进行，但是一旦数据量比较大的，就会一直占用 CPU，可能会影响到父进程的进行。
-
前面的 RDB 配置里我们提到是按一定的时间间隔内去触发持久化的，但也正是因为这个时间间隔原因，导致我们将会有一定概率在这段时间内丢失数据。
AOF 配置
同样的，我们可以在 redis.conf 文件里对 AOF 持久化进行配置：
appendonly no # 是否开启 aof
appendfilename "appendonly.aof" # aof 文件名
# 同步到磁盘的策略 默认每秒一次
# appendfsync always # 每次
appendfsync everysec # 每秒一次
# appendfsync no # 由操作系统执行，默认Linux配置最多丢失30秒
auto-aof-rewrite-percentage 100 # aof 文件超过比例则进行重写
auto-aof-rewrite-min-size 64mb # aof 文件超过多少则进行重写
aof-load-truncated yes # 如果 aof 最后的指令有误，则在重新恢复时忽略。
在上面的配置中，我们看到有关 aof 文件重写的配置。之所以需要对 aof 进行重写，是因为 aof 文件记录的是逻辑操作。随着系统运行越久，操作命令将越来越多，日志文件也就越来越大了，所以需要对其进行重写，以减少磁盘空间。
当 AOF 进行文件重写时，会将内存数据重新整理一遍，然后保存到新文件里，接着再将新文件替换原来的 AOF 文件。
AOF 优势
- AOF 让我们可以以每秒的速度进行持久化，这样的话可以很大程度的减少数据的丢失。
- AOF 采用追加的方式进行写文件，这样即使持久化失败，影响较少，而且能够使用 redis-check-aof 进行修复。
AOF 缺点
- 前面提到过日志会越来越大，需要靠重写来减少对磁盘的占用。
混合持久化
为了能将 AOF 和 RDB 的优势结合起来， Redis 在 4.0 之后启用了混合持久化，它的配置如下：
aof-use-rdb-preamble yes
当开启了混合持久化后，Redis 会 fork 子进程将内存数据以 RDB 格式写入 AOF 文件，后面会将重写缓冲区的增量命令以 AOF 方式写入到文件。这样的话，新的 AOF 文件就同时拥有了 2 种格式的数据。
当需要使用混合文件进行恢复时，会先判断 AOF 文件的头部是否为 RDB 格式，是的话，先使用 RDB 的方式加载数据，接着再处理后面的 AOF 数据。
这样的话就能加快数据的恢复速度，又降低了数据丢失的风险。
当然， 这种混合方式会使得 AOF 文件变得复杂，可读性差，而且得是 4.0 版本以上才能使用。
总结
Redis 的持久化都有它的特点，那我们应该选择哪种机制呢？
- 如果我们的数据允许丢失，那应该关闭持久化方式，这样性能会很好。
- 如果我们希望能尽量的保证数据的安全性，那我们应该选择混合持久化方式。
- 如果我们希望保证数据不丢失，那应该选择 appendfsync 为 always，只是这种对性能影响很大，所以一般都会直接考虑 mysql 了。
感兴趣的朋友可以搜一搜公众号「 阅新技术 」，关注更多的推送文章。
可以的话，就顺便点个赞、留个言、分享下，感谢各位支持！
阅新技术，阅读更多的新知识。
网友评论