Skip to content

Latest commit

 

History

History
145 lines (80 loc) · 5.69 KB

2_Redis持久化.md

File metadata and controls

145 lines (80 loc) · 5.69 KB
Raw

Redis 持久化

Redis 是内存型数据库，为了保证数据断电后不丢失，需要将内存中的数据持久化到磁盘上；另一方面，保存中间结果，不必重新计算。

持久化有 2 种：

  • 快照持久化：将存在某一时刻的所有数据都写入磁盘中
  • AOF 持久化：在执行写命令时，将被执行的写命令复制到文件中

Redis 提供的持久化配置选项：

# 快照持久化
save 60 1000
stop-writes-on-bgsave-error yes
rdbcompression no

# AOF 持久化
appendonly yes
appendfsync always # 同步选项
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 共享选项，决定了快照文件和 AOF 文件的保存位置
dir ./

快照持久化

快照持久化是通过创建快照来获得 Redis 存储在内存中数据在某个时间点上的副本。在创建快照后，用户可对快照备份，可将快照留在原地以便重启 Redis 时使用。

快照持久化配置

save 60 10000        
# 在60秒(1分钟)之后，如果至少有10000个键发生变化，Redis 就会自动触发 BGSAVE 命令创建快照。

stop-writes-on-bgsave-error yes 
# 表示备份进程出错的时候，主进程就停止接收新的写入操作，是为了保护持久化数据的一致性。

rdbcompression no
# RDB 的压缩设置为 no，因为压缩会占用更多的 CPU 资源。

创建快照的方法

  • BGAVSE 命令

    客户端向 Redis 发送 BGSAVE 命令来创建一个快照。对于支持 BGSAVE 命令的平台来说（基本上所有平台支持，除了Windows平台），Redis 会调用 fork 来创建一个子进程，然后子进程负责将快照写入硬盘，而主进程则继续处理命令请求。

  • 用户设置 save 配置选项

    save 60 10000
# 从 redis 最近一次创建快照之后算起，满足 “60 s 内 10000 次写入”，Redis 会自动触发 BGSAVE 命令

存在的问题

  • 如果系统发生故障，将会丢失最近一次创建快照之后的数据
  • 如果数据量很大，保存快照的时间会很长

AOF 持久化

AOF 持久化将被执行的写命令写到 AOF 文件末尾，记录数据发生的变化。Redis 值要从头到尾重新执行一次 AOF

文件包含的所有写命令，就可恢复 AOF 文件所记录的数据。

默认情况下，Redis 没有开启 AOF（append only file）方式的持久化，可以通过 appendonly 参数开启：

appendonly yes

快照持久化配置

appendonly yes

appendfsync always # 同步选项

auto-aof-rewrite-percentage 100
    
auto-aof-rewrite-min-size 64mb

同步选项

使用 AOF 持久化需要设置同步选项，从而确保写命令什么时候会同步到磁盘文件上。

同步选项 同步频率 说明
always 每个 Redis 写命令都要同步写入磁盘 当系统发生崩溃时，丢失的数据减到最少;
需要对磁盘大量写入，速度会受到磁盘限制
everysec 每秒执行一次同步，显示地将多个写命令同步到磁盘 性能上和不使用任何持久化特性时相差无几，
可保证数据即使出现系统崩溃，用户也最多只会丢失 1 秒内产生的数据
no 由操作系统来决定何时进行同步 不会对 Redis 性能产生影响，但系统崩溃将导致 Redis 丢失不定量的数据，
若用户写入磁盘处理写入速度不够快，当缓冲区被等待写入磁盘的数据填满时，Redis 写入操作会被阻塞，并导致 Redis 处理命令请求变慢

重写 / 压缩 AOF 文件

AOF 持久化存在的问题：

  • 随着 Redis 不断运行，AOF 文件的体积会不断增长，占用更多的磁盘空间
  • 若 AOF 文件体积非常大，则恢复的时间可能会比较长

为了解决 AOF 文件不断增大的问题，我们采用重写 / 压缩 AOF 文件的方式：

用户 Redis 发送 BGREWRITEAOF 命令，通过移除 AOF 文件中冗余命令来重写 AOF 文件来减小 AOF 文件的体积。

（新的 AOF 文件和原有的 AOF 文件所保存的数据状态是一致的，但是体积更小）。

BGREWRITEAOF 原理：

Redis 维护 AOF 重写缓冲区和 AOF 缓冲区。子进程创建新的 AOF 文件期间，记录服务器执行的所有写命令会同时写入 2 个缓冲区中，使得新旧两个 AOF 文件中所保存的数据状态一致。

对比

持久化方式 优点 缺点
快照持久化 文件小，恢复快 会丢失最近一次生成快照后写入的数据；
是压缩文件，可读性较差
AOF 持久化 可读性好；
数据不易丢失（丢失 1 秒内产生的数据）		 文件体积大，占用磁盘空间；
恢复时间长

优化

Redis 4.0 以后将快照和 AOF 混合持久化（默认关闭，使用 aof-user-rdb-preamble开启），AOF 重写时将快照写入 AOF 文件开头。

这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据，当然缺点也是有的， AOF 里面的 RDB 部分是压缩格式不再是 AOF 格式，可读性较差。