V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Zkiller
V2EX  ›  Redis

聊聊 Redis 数据持久化备份

  •  
  •   Zkiller · 2018-10-18 22:49:11 +08:00 · 2120 次点击
    这是一个创建于 2016 天前的主题,其中的信息可能已经有所发展或是发生改变。

    redis

    缓存应用在服务中我们经常都会使用的,其中尤其是 Redis,今天给大家聊聊 Redis 的数据持久化。

    Redis 持久化主要有两种方式,一种是 RDB,一种是 AOF。

    其中 RDB ( Redis DataBase )持久化是以快照( snapshotting )方式进行,把存在某一时刻的所有数据写入硬盘过程。

    AOF ( append-only file )是以追加文件方式持久化,它以日志文件的方式记录每次的写命令,在服务重启再重新执行 AOF 文件命令来恢复数据。

    这两种数据备份方式即可以同时使用,又可以单独使用。

    RDB 快照持久化

    首先我们看下 RDB 快照方式,这种持久化方式主要分为手动触发和被动触发。

    手动触发分为 SAVE 和 BGSAVE,由于 SAVE 会阻塞 Redis 服务,直到 RDB 过程完成,所以生产环境我们主要使用 BGSAVE 操作,执行 BGSAVE 之后,Redis 进程会执行 fork 子进程,让子进程负责,直到自动结束。

    被动触发是由于我们配置文件进行了 save 配置选项,如果用户设置了多个配置 save 配置选项那么任何一个条件满足就会触发 BGSAVE。

    我们可以看下下面的一段配置:

    1. save 60 10000 # 60s 有 10000 次写入(修改)被动触发 BGSAVE
    2. save 900 10  # 900s 有 10 次就触发 BGSAVE,保存到硬盘(两个满足一个就触发)
    3. stop-writes-on-bgsave-error no # 创建快照失败是否继续写命令
    4. rdbcompression yes # 是否进行压缩(默认压缩)
    5. dbfilename dump.rdb # 生成文件名
    

    其中 save 的配置需要我们进行合理评估,过频繁会浪费资源,过于稀少可能会有丢失大量数据隐患。

    在这里我们需要知道通过快照持久化的方式来保存数据,如果服务发生故障,用户将会丢失最近一次生成快照之后更改的所有数据。

    当然如果缓存数据小于或者只有几个 GB 时候,使用快照进行保存数据没有啥问题的。

    AOF 追加持久化

    由于 RDB 快照持久化适合小规模或丢失一部分数据也不会造成问题的应用,但是大多数场景里面,我们需要尽量保证数据完整性,所以这里我们有了 AOF 这种方式。

    AOF 持久化会将执行的命令写到 AOF 文件的末尾,来记录数据发生的变化,所以只需要将 AOF 的文件命令在 Redis 重新执行一遍就能恢复 AOF 文件的数据。

    但是 AOF 文件会随着命令的不断增加,文件会越来越大,所以 Redis 有了重写机制,通过重写机制来压缩控制文件大小。

    重写机制的原理就是合并多个命令,比如同样 inc 操作了 100 次,那么就可以合并为 1 次进行,或者之前添加了某个数据,后面又删除了就可以删除之前无效的命令等等。

    AOF 重写这种方式和 RDB 触发同样分为手动触发和被动触发。

    手动触发方式:bgrewriteaof 被动触发方式:auto-aof-rewrite-percentage, auto-aof-rewrite-min-sieze

    我们可以看下下面的配置:

    appendonly no  # 是否进行 aof 持久化
    appendfsync everysec # 每秒同步一次,有 always,no 选项
    no-appendfsync-on-rewrite no # aof 重写期间是否同步
    auto-aof-rewrite-percentage 100 # 当前文件是上一次大小的两倍的时候触发重写
    auto-aof-rewrie-min-size 64mb # 文件最小体积触发重写
    

    AOF 重写和 RDB 快照方式一样,都会创建子进程,然后 AOF 子进程进行文件重写,所以快照持久化因为创建子进程导致性能和内存问题在 AOF 一样存在。

    通过 AOF 的方式能相对更完善保留数据,让我们更为放心。

    在这儿我们需要知道服务重启之后 Redis 默认加载流程,优先加载 AOF 文件,如果没有再考虑加载 RDB 文件。

    最后

    我们来简单总结一下 RDB 和 AOF 优缺点:

    RDB 优点:压缩二进制适合备份,加载恢复数据比 AOF 快 RDB 缺点:没法做到实时持久化,频繁操作消耗资源

    AOF 优点:通过追加命令可以实时持久化 AOF 缺点:加载恢复数据慢

    有了这两种持久化方式,我们服务在重启或者宕机的时候就能更加完整保留数据,除了进行持久化操作外,我们也应该尽量把数据文件备份到不同服务器,避免在出现严重问题的时候不会丢失数据。

    原文: 聊聊 Redis 数据持久化备份 | sitin's blog

    1 条回复    2018-10-18 23:56:24 +08:00
    YzSama
        1
    YzSama  
       2018-10-18 23:56:24 +08:00 via iPad
    rdb 适合定时备份。aof 适合实时备份。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2931 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 15:19 · PVG 23:19 · LAX 08:19 · JFK 11:19
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.