【Redis】内存数据库Redis进阶（Redis持久化）

分布式缓存 Redis 四大问题

基于 Redis 集群解决单机 Redis 存在的四大问题：

Redis 持久化

  防止数据的意外丢失，确保数据安全性，利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。

  持久化过程保存什么：

• 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据
• 将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程
  

RDB (Redis DataBase)

  RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。快照文件称为RDB文件，默认是保存在当前运行目录。
  在进行 RDB 的时候，Redis 的主线程是不会做 IO 操作的，主线程会 fork 一个子线程来完成该操作；Redis 调用 fork，同时拥有父进程和子进程。子进程将数据集写入到一个临时 RDB 文件中。当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。
  这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益，因为是使用子进程进行写操作，而父进程依然可以接收来自客户端的请求。fork 采用的是 copy-on-write 技术：

• 当主进程执行读操作时，访问共享内存；
• 当主进程执行写操作时，则会拷贝一份数据，执行写操作。
  
  

RDB执行时机

RDB持久化在四种情况下会执行：

• 执行save命令
• 执行bgsave命令
• Redis停机时
  Redis停机时会执行一次save命令，实现RDB持久化。
• 触发RDB条件时
  save second changes 其中 second：监控时间范围，changes：监控key的变化量。save “” 则表示禁用 RDB

RDB启动方式——save指令

# 手动执行一次保存操作，save命令会导致主进程执行RDB，这个过程中其它所有命令都会被阻塞。只有在数据迁移时可能用到。
save

redis-cli -p 6379
127.0.0.1:6379> 
127.0.0.1:6379> save
OK
# 在redis安装目录的data目录生成dump.rdb文件

save指令相关配置

• dbfilename dump.rdb
  说明：设置本地数据库文件名，默认值为 dump.rdb。
  经验：通常设置为dump-端口号.rdb。
• dir
  说明：设置存储.rdb文件的路径。
  经验：通常设置成存储空间较大的目录中，目录名称data。
• rdbcompression yes
  说明：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF 压缩。
  经验：通常默认为开启状态，如果设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）。
• rdbchecksum yes
  说明：设置是否进行 rdb 文件格式校验，该校验过程在写文件和读文件过程均进行。
  经验：通常默认为开启状态，如果设置为 no，可以节约读写性过程约 10% 时间消耗，但是存储一定的数据损坏风险。

数据恢复演示：

# 关闭redis进程
ps -ef | grep redis-
kill -9 端口号

# 启动redis，观察是否有数据
redis-server conf/redis-6379.conf 
redis-cli -p 6379
>keys *
>"输出" # 关闭前的数据存在，持久化生效

save指令工作原理

save配置自动执行

  反复执行保存指令，忘记了，不知道数据产生了多少变化，何时保存。由 Redis 服务器发起指令（基于条件）自动执行保存数据。

# 在conf文件中进行配置，重新以配置文件启动，满足限定时间范围内key的变化数量达到指定数量即进行持久化 
# second：监控时间范围，changes：监控key的变化量
save second changes

RDB启动方式——bgsave指令

  数据量过大，单线程执行方式造成效率过低，需要后台执行（ Redis 操作者（用户）发起指令；Redis 服务器控制指令执行）

# 手动启动后台保存操作，但不是立即执行，开启独立进程完成RDB，主进程可以持续处理用户请求，不受影响。
bgsave

127.0.0.1:6379> keys *
1) "name"
127.0.0.1:6379> set age 25
OK
127.0.0.1:6379> get age
"25"
127.0.0.1:6379> bgsave
Background saving started

# 保存在dump.rdb

bgsave指令相关配置

• dbfilename dump.rdb
  说明：设置本地数据库文件名，默认值为 dump.rdb。
  经验：通常设置为dump-端口号.rdb。
• dir
  说明：设置存储.rdb文件的路径。
  经验：通常设置成存储空间较大的目录中，目录名称data。
• rdbcompression yes
  说明：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF 压缩。
  经验：通常默认为开启状态，如果设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）。
• rdbchecksum yes
  说明：设置是否进行 rdb 文件格式校验，该校验过程在写文件和读文件过程均进行。
  经验：通常默认为开启状态，如果设置为 no，可以节约读写性过程约 10% 时间消耗，但是存储一定的数据损坏风险。
• stop-writes-on-bgsave-error yes
  说明：后台存储过程中如果出现错误现象，是否停止保存操作。
  经验：通常默认为开启状态。

bgsave指令工作原理

RDB三种启动方式对比

方式	save指令	bgsave指令
读写	同步	异步
阻塞客户端指令	是	否
额外内存消耗	否	是
启动新进程	否	是

RDB特殊启动形式

• 全量复制
  在主从复制中详细讲解

• 服务器运行过程中重启
  debug reload

• 关闭服务器时指定保存数据
  shutdown save
  默认情况下执行 shutdown 命令时，自动执行 bgsave( 如果没有开启AOF持久化功能 )

RDB优点与缺点

RDB优点：

• RDB 是一个紧凑压缩的二进制文件，存储效率较高。
• RDB 内部存储的是 Redis 在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景。
• RDB 恢复数据的速度要比 AOF 快很多。
• 应用：服务器中每x小时执行 bgsave 备份，并将 RDB 文件拷贝到远程机器中，用于灾难恢复。

RDB缺点：

• RDB 方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据。
• bgsave 指令每次运行要执行 fork 操作创建子进程，要牺牲掉一些性能。
• Redis 的众多版本中未进行 RDB 文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象。

RD B文件格式中的 check_sum字段数值用来在载入时判断文件是否损坏

RDB文件格式中的db_version字段记录了RDB文件的版本号

RDB文件格式中的 SELECTDB 常量 pairs 在任何情况下都会存在（错误）。
解释：只有当数据库中有键值对时，RDB 文件中才会有该数据库的信息。

AOF (Append Only File)

解决 RDB 存储的弊端：

• 存储数据量较大，效率较低 基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低。
• 大数据量下的 IO 性能较低。
• 基于 fork 创建子进程，内存产生额外消耗。
• 宕机带来的数据丢失风险。

解决思路：

• 不写全数据，仅记录部分数据。
• 降低区分数据是否改变的难度，改记录数据为记录操作过程。
• 对所有操作均进行记录，排除丢失数据的风险。

AOF概念：
  AOF (append only file) 持久化：以独立日志的方式记录每次写命令，重启时再重新执行 AOF 文件中命令达到恢复数据的目的。
  与 RDB 相比可以简单描述为改记录数据为记录数据产生的过程。AOF 的主要作用是解决了数据持久化的实时性，目前已经是 Redis 持久化的主流方式。

AOF写数据三种策略 (appendfsync)

• always（每次）
  每次写入操作均同步到 AOF 文件中，数据零误差，性能较低。

• everysec（每秒）
  每秒将缓冲区中的指令同步到 AOF 文件中，数据准确性较高，性能较高。
  在系统突然宕机的情况下丢失 1 秒内的数据。

• no（系统控制）
  由操作系统控制每次同步到 AOF 文件的周期，整体过程不可控。

AOF相关配置

# 是否开启AOF功能，默认是no
appendonly yes

# AOF持久化文件名，默认文件名未appendonly.aof，建议配置为appendonly-端口号.aof
appendfilename filename

# AOF持久化文件保存路径，与RDB持久化文件保持一致即可
dir

# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always 
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec 
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no

测试添加数据：

127.0.0.1:6379> set age 55
OK

cat appendonly-6379.aof
...
set
$3
age
$2
55

AOF工作流程

AOF重写

  随着命令不断写入 AOF，文件会越来越大，为了解决这个问题，Redis 引入了 AOF 重写机制压缩文件体积。AOF 文件重写是将 Redis 进程内的数据转化为写命令同步到新 AOF 文件的过程。
  简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。

AOF重写作用

• 降低磁盘占用量，提高磁盘利用率。
• 提高持久化效率，降低持久化写时间，提高IO性能。
• 降低数据恢复用时，提高数据恢复效。

AOF重写规则

• 进程内已超时的数据不再写入文件。
• 忽略无效指令，重写时使用进程内数据直接生成，这样新的 AOF 文件只保留最终数据的写入命令，如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
• 对同一数据的多条写命令合并为一条命令，如 lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。
• 为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入 64 个元素。

AOF重写方式

• 手动重写 （bgrewriteaof 指令）

127.0.0.1:6379> set name 111
OK
127.0.0.1:6379> set name 222
OK
[root@koma data]# cat appendonly-6379.aof

127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

[root@koma data]# cat appendonly-6379.aof

• 自动重写

# 自动重写触发条件设置
auto-aof-rewrite-min-size size  # AOF文件体积最小多大以上才触发重写 
auto-aof-rewrite-percentage percentage  # AOF文件比上次文件 增长超过多少百分比则触发重写

# 自动重写触发比对参数（运行指令info Persistence获取具体信息）
aof_current_size
aof_base_size

自动重写触发条件：

AOF重写流程

RDB (Redis DataBase) VS AOF (Append Only File)

持久化方式	RDB (Redis DataBase)	AOF (Append Only File)
占用存储空间	小（数据级：压缩）	大（指令级：重写）
存储速度	慢	快
恢复速度	快	慢
数据安全性	会丢失数据	依据策略决定
资源消耗	高 / 重量级	低 / 轻量级
启动优先级	低	高

• 对数据非常敏感，建议使用默认的 AOF 持久化方案
  ​AOF持久化策略使用 everysecond，每秒钟 fsync 一次。该策略 Redis 仍可以保持很好的处理性能，当出现问题时，最多丢失 0-1 秒内的数据。
  ​注意：由于 AOF 文件存储体积较大，且恢复速度较慢。
• 数据呈现阶段有效性，建议使用 RDB 持久化方案
  ​数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段点数据恢复通常采用 RDB 方案。
• 综合比对
  RDB 与AOF 的选择实际上是在做一种权衡，每种都有利有弊。
  如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF。
  ​如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB。
  ​灾难恢复选用RDB。
  ​双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量。