共计 2154 个字符，预计需要花费 6 分钟才能阅读完成。
redis 提供了两种长久化的机制 RDB 和 AOF 机制
RDB(redis Database):RDB 保留某一个工夫点之前的快照数据。
AOF(Append-Only File): 指所有的命令行记录以 redis 命令申请协定的格局齐全长久化存储保留为 AOF 文件
混合长久化(4.0 版本当前)：指进行 AOF 重写时子过程将以后工夫点的数据快照保留为 RDB 文件格式，而后将父过程累计命令保留为 AOF 格局。
RDB 快照有两种触发形式
1: 为通过配置参数，如下：
通过肯定的工夫周日内看，命令执行的个数，超过阈值立刻执行快照生成
save 900 1 //900 秒内有 1 次更新
save 300 10 //30 秒内有 10 次更新
save 60 10000 //60 秒内有 10000 次更新2: 手动执行 bgsave/save, 手动触发生成快照
间接执行 save 会阻塞主过程，bgsave 的话会 fork 一个子过程实现快照
然而 redis 在产生 RDB 长久化的过程中有几个问题须要思考
1.RDB 快照过程中 Redis 是否会进行对外服务
2. 如果不回进行服务，那如何解决新的申请
接下来咱们看 redis 的
RDB 长久化的具体过程
1: 主过程会 fork 一个子过程
2: 子过程会共享一部分主过程的数据空间，并且把共享的数据置为 read-only 的状态，在这个过程中，子过程以 rdb 的协定来履行长久化
3: 在长久化的过程中是防止不了有新的数据写入的，因为咱们有一部分的数据是共享的，两个过程同时领有一块数据，必定会导致数据不统一的问题，
然而依赖于操作系统的 fork 机制，在批改的时候肯定是批改局部内存页的数据，这个时候会触发对应内存页的 copyonwrite 的操作，不会影响子过程完
成长久化，长久化完结后，主过程会对子过程进行回收
RDB 的文件格式
redis 的 rdb 文件是一个十分紧凑的格局
结尾的 REDIS 是固定的一个格局，redis 在读取长久化文件的时候发现不是以 REDIS 结尾的会报错
0006 是 RDB_VERSION 以后 RDB 协定的版本
AUX_FIELD_KEY_VALUE_PAIRS 是一些辅助的字段
data 则为保留的数据，数据首先会抉择 redis_db，db 抉择之后就是键值对的数据，对应的键值对又会分为设置过过期工夫和未设置过期工夫的数据
RDB 长久化的长处
1: 二进制的数据十分紧凑，数据的复原速度十分快
2: 在长久化的过程中，性能最大化，fork 子过程来实现写操作，让主过程持续解决命令，应用独自子过程来进行长久化，保障了 redis 的高性能
RDB 长久化的毛病
1: 数据安全性低，RDB 是距离一段时间进行长久化，如果长久化之间 redis 产生了故障，会产生数据失落
2:linux fork 之后，kernel 把父过程中所有的内存页权限都设置 readonly，而后子过程的地址空间指向父过程。当父子过程都只读内存时，相安无事。当其中某个过程写内存时，CPU 硬件检测到内存页是 read-only 的，于是触发页异样终端(page-fault), 陷入 kernal 的一个中断例程。中断例程中，kernel 的 copyonwrite 机制就会把触发的异样页复制一份，于是父子过程各自持有独立的一份。如果这个时候有大量的写入操作，会产生大量的分页谬误(页异常中断 page-fault
), 这样就得消耗不少性能在复制上。
AOF 长久化执行流程
通过 appendonly yes 开启
Redis 应用单线程响应命令，如果每次 AOF 文件命令都追加到磁盘，会极大的影响解决性能，所以 Redis 先写入 aof 缓冲区，依据用户配置的同步磁盘策略写入 aof 文件中，能够通过 appendfsync 参数配置同步策略：含意如下
appendfsync always #示意每次更新操作后手动调用 fsync()将数据写入到磁盘
appendfsync everysec #示意每秒同步一次(折中计划，默认值)
appendfsync no #表述等操作系统进行数据缓存同步到磁盘(疾速响应客户端，不对 AOF 做数据同步，同步文件由操作系统负责，通常同步周期最长 30S)AOF 重写机制
随着命令得一直写入 AOF，文件会越来越大，为了解决这个问题 Redis 引入了 AOF 重写机制压缩文件体积。AOF 文件重写是把 Redis 过程内的数据转化为写命令同步到新 AOF 文件的过程，AOF 重写机制能够通过手动触发了主动触发
手动触发：bgreweuteaof 命令
主动触发：
auto-aof-rewrite-percentage 100 #示意以后 AOF 文件空间和上一次重写后 AOF 文件空间的比值(100%)
auto-aof-rewrite-min-size 64mb #代表 AOF 重写时文件最小体积AOF 的长处：数据安全，AOF 长久化能够配置 appendfsync 属性，有 always，每进行一次命令操作就记录到 aof 文件中一次。
AOF 的毛病：数据集比拟大的时候，比 RDB 启动效率低
混合长久化
能够通过 aof-use-rdb-preamble yes 开启
加载时，首先会辨认 AOF 文件是否以 REDIS 字符串结尾，如果是，就依照 RDB 格局加载，加载完 RDB 后持续按 AOF 格局加载残余局部。
混合式长久化计划兼顾了 RDB 的速度，和 AOF 的安全性
关注我的技术公众号，每周都有优质技术文章推送。
微信扫一扫下方二维码即可关注：
