Redis 长久化
前言
Rdis 的读写都是在内存中进行，所以 redis 的性能很高。
长久化能够无效地防止因过程退出而造成数据失落问题，下次重启的时候利用之前长久化文件能够实现数据恢复。
长久化的几种形式
Redis 长久化领有以下三种形式：
- 快照形式（RDB, Redis DataBase）
RDB 长久化是把以后过程数据生成快照保留到硬盘的过程，触发 RDB 长久化过程分为手动触发和主动触发
- 文件追加形式（AOF, Append Only File）
记录所有的操作命令，并以文本的模式追加到文件中；
- 混合长久化形式，
Redis 4.0 之后新增的形式，混合长久化是联合了 RDB 和 AOF 的长处，在写入的时候，先把以后的数据以 RDB 的模式写入文件的结尾，再将后续的操作命令以 AOF 的格局存入文件，这样既能保障 Redis 重启时的速度，又能减低数据失落的危险。
以上三种长久化计划，每一种都有特定的应用场景, 具体的咱们能够依据本人的需要自行抉择。
RDB 长久化
RDB（Redis DataBase）是 将某一个时刻的内存快照（Snapshot），以二进制的形式写入磁盘的过程。
RDB 的长久化形式有两种：
一种是手动触发，一种是主动触发
手动触发
手动触发 Redis 提供了两个命令：save 和 bgsave。
- save 命令
save 手动触发会阻塞主线程
在客户端执行 save 命令时候，就会触发长久化，但也会使得 Redis 主线程阻塞，必须等到 RDB 长久化实现之后，才会相应客户端的命令，线上环境不倡议应用。
下图演示应用 save 命令
启动 Redis（默认配置是 rdb 长久化形式），rdb 文件工夫。
而后应用 save 长久化数据
而后查看长久化后 rdb 文件的工夫
阐明手动长久化文件胜利
- bgsave 命令
bgsave不会阻塞主线程
应用 bgsave 命令时候，Redis 过程执行 fork 操作创立子过程，RDB 长久化过程由子 过程负责，实现后主动完结。阻塞只产生在 fork 阶段，个别工夫很短，根本不会产生阻塞，与 save 命令相比显然 bgsave 更适宜咱们长久化数据。
下图示意开始主动长久化数据
主动触发
如何主动触发 RDB 长久化？
在 redis.conf 文件中有这么一个配置
什么意思呢？
- save m n
save m n 示意 m 秒内数据集存在 n 次批改 时，主动触发 bgsave 命令。
save 900 1 则表明在 900 秒内，至多有一个键产生扭转，就会触发 RDB 长久化。
save 300 10 则表明在 300 秒内，至多有 10 个键产生扭转，就会触发 RDB 长久化。
save 60 10000 则表明在 60 秒内，至多有 10000 个键产生扭转，就会触发 RDB 长久化。
满足以上任意一个条件，Redis 就会主动触发 bgsvae 命令进行长久化工作。
- flushall
留神：flushall 是把内存中的数据清空，长久化会把原先曾经长久化的 .rdb 文件清空。
- 主从同步触发
Redis 主从复制时，当从节点执行全量复制操作时，主节点会执行 bgsave 命令，并将 RDB 文件发送给从节点，该过程会主动触发 Redis 长久化。
RDB 配置阐明
# RDB 保留的条件
save 900 1
save 300 10
save 60 10000
# bgsave 失败之后，是否进行长久化数据到磁盘，yes 示意进行长久化，no 示意疏忽谬误持续写文件。stop-writes-on-bgsave-error yes
# RDB 文件压缩
# Redis 会采纳 LZF 算法进行压缩。如果不想耗费 CPU 性能来进行文件压缩的话，能够设置为敞开此性能，# 这样的毛病是须要更多的磁盘空间来保留文件。rdbcompression yes
# 写入文件和读取文件时是否开启 RDB 文件查看，查看是否有无损坏，如果在启动是查看发现损坏，则进行启动。rdbchecksum yes
# RDB 文件名
dbfilename dump.rdb
# RDB 文件目录
dir ./
RDB 优缺点
长处
- RDB 是一个紧凑压缩的二进制文件，代表 Redis 在某个工夫点上的数据 快照。十分实用于备份，全量复制等场景。
- 与 AOF 格局的文件相比，RDB 文件能够更快的重启。
- RDB 对劫难复原十分有用，它是一个紧凑的文件，能够更快的传输到近程服务器进行 Redis 服务复原
毛病
- RDB 形式数据没方法做到实时长久化 / 秒级长久化，RDB 只能保留某个工夫距离的数据，如果在这个期间 Redis 故障了，就会失落一段时间的数据。
- RDB 形式数据没方法做到实时长久化 / 秒级长久化。因为 bgsave 每次运 行都要执行 fork 操作创立子过程，属于重量级操作，频繁执行老本过高。
禁用长久化
save ""AOF 长久化
AOF（append only file）长久化：以独立日志的形式记录每次写命令，重启时再从新执行 AOF 文件中的命令达到复原数据的目标。AOF 的次要作用 是解决了数据长久化的实时性，目前曾经是 Redis 长久化的支流形式
AOF 的工作流程操作
命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）。
配置 AOF
默认是 no示意敞开，yes示意开启。
- 主动触发
长久化配置
- always：每条 Redis 操作命令都会写入磁盘，最多失落一条数据，但会使得 Redis 的性能升高，但数据简直是全的，根本不会存在失落数据问题。
- everysec：每秒钟写入一次磁盘，最多失落一秒的数据，对存取数据和性能折中，能够满足大部分应用场景。
- no：不设置写入磁盘的规定，依据以后操作系统来决定何时写入磁盘，个别不采纳这种设置。
- 手动触发
应用 bgrewriteaof 命令能够手动触发 aof 长久化
随着工夫的推移和数据质变大，aof 始终在进行长久化，磁盘日志越来越大，redis 重启速度越来越慢，针对这个问题，Redis 提供了 AOF 重写性能。
Redis 中的数据是有肯定限量的，最多不超过物理内存大小，不可能说 Redis 中的数据有限增长，导致 aof 也有限增长，到肯定的时候 Redis 就会采纳缓存淘汰算法 LRU 主动将以局部数据从内存中给革除。
AOF 重写配置
- auto-aof-rewrite-min-size：容许 AOF 重写的最小文件容量，默认是 64m。
- auto-aof-rewrite-percentage：AOF 文件重写的大小比例，默认值是 100，示意 100%，也就是只有以后 AOF 文件，比最初一次（上次）的 AOF 文件大一倍时，才会启动 AOF 文件重写。
AOF 重写流程
AOF 是寄存每条写命令的，所以会一直变大，达到肯定的时候，AOF 做 rewrite 操作，会从新生成一个新的 AOF 文件。
优缺点
AOF 长处
AOF 长久化保留的数据更加残缺，AOF 提供了三种保留策略：每次操作保留、每秒钟保留一次、追随零碎的长久化策略保留，其中每秒保留一次，从数据的安全性和性能两方面思考是一个折中的抉择，也是 AOF 默认的策略，即便产生了意外状况，最多只会失落 1s 钟的数据；
AOF 采纳的是命令追加的写入形式，所以不会呈现文件损坏的问题，即便因为某些意外起因，导致了最初操作的长久化数据写入了一半，也能够通过 redis-check-aof 工具轻松的修复；
AOF 长久化文件，非常容易了解和解析，它是把所有 Redis 键值操作命令，以文件的形式存入了磁盘。即便不小心应用 flushall 命令删除了所有键值信息，只有应用 AOF 文件，删除最初的 flushall 命令，重启 Redis 即可复原之前误删的数据。
AOF 毛病
对于雷同的数据集来说，AOF 文件要大于 RDB 文件；
在 Redis 负载比拟高的状况下，RDB 比 AOF 性能更好；
RDB 应用快照的模式来长久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因而从实践上说，RDB 比 AOF 更强壮。
混合长久化
RDB 和 AOF 长久化各有优缺点，RDB 会导致一段时间内的数据失落，AOF 文件会越来越大，会影响 Redis 的启动速度，为了同时兼顾 RDB，AOF 的长处，Redis 在 4.0 版本之后提供了混合长久化形式。
混合长久化
AOF 重写时会把 Redis 的长久化数据，以 RDB 的格局写入到 AOF 文件的结尾，之后的数据再以 AOF 的格式化追加的文件的开端，如下图所示。
开启混合
将 no 改为 yes 即可
混合长久化优缺点
长处
混合长久化联合了 RDB 和 AOF 长久化的长处，结尾为 RDB 的格局，使得 Redis 能够更快的启动，同时联合 AOF 的长处，有减低了大量数据失落的危险。
毛病：
AOF 文件中增加了 RDB 格局的内容，会使得 AOF 文件的可读性会很差，不容易浏览；
如果开启混合长久化，就必须应用 Redis 4.0 以及之后版本。
应用混合长久化的时候能够依据本身业务抉择敞开 RDB 或者 AOF，或者敞开长久化。
关注我
长按二维码
如果你喜爱这篇文章，喜爱，在看，转发。