精华内容
下载资源
问答
  • 快照存储(rdb)与AOF存储的优缺点 1、快照存储 优点 1)RDB文件是一个很简洁的单文件,它保存了某个时间点的Redis数据,很适合用于做备份。你可以设定一个时间点对RDB文件进行归档,这样就能在需要的时候很轻易的把...

    快照存储(rdb)与AOF存储的优缺点

    1、快照存储

    优点

    1)RDB文件是一个很简洁的单文件,它保存了某个时间点的Redis数据,很适合用于做备份。你可以设定一个时间点对RDB文件进行归档,这样就能在需要的时候很轻易的把数据恢复到不同的版本。

    2)RDB很适合用于灾备。单文件很方便就能传输到远程的服务器上。

    3)RDB的性能很好,需要进行持久化时,主进程会fork一个子进程出来,然后把持久化的工作交给子进程,自己不会有相关的I/O操作。

    备注:比起AOF,在数据量比较大的情况下,RDB的启动速度更快。

    缺点

    1)RDB容易造成数据的丢失。假设每5分钟保存一次快照,如果Redis因为某些原因不能正常工作,那么从上次产生快照到Redis出现问题这段时间的数据就会丢失了。

    2)RDB使用fork()产生子进程进行数据的持久化,如果数据比较大的话可能就会花费点时间,造成Redis停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候,停止服务的时间甚至会到1秒。

    2、AOF存储

    优点

    1)AOF 持久化的方法提供了多种的同步频率,即使使用默认的同步频率每秒同步一次,Redis 最多也就丢失 1 秒的数据而已。

    2)AOF 文件使用 Redis 命令追加的形式来构造,因此,即使 Redis 只能向 AOF 文件写入命令的片断,使用 redis-check-aof 工具也很容易修正 AOF 文件。

    3)AOF 文件的格式可读性较强,这也为使用者提供了更灵活的处理方式。例如,如果我们不小心错用了 FLUSHALL 命令,在重写还没进行时,我们可以手工将最后的 FLUSHALL 命令去掉,然后再使用 AOF 来恢复数据。

    缺点

    1)对于具有相同数据的的 Redis,AOF 文件通常会比 RDB 文件体积更大。

    2)虽然 AOF 提供了多种同步的频率,默认情况下,每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时,RDB 比 AOF 具好更好的性能保证。

    3)RDB 使用快照的形式来持久化整个 Redis 数据,而 AOF 只是将每次执行的命令追加到 AOF 文件中,因此从理论上说,RDB 比 AOF 方式更健壮。官方文档也指出,AOF 的确也存在一些 BUG,这些 BUG 在 RDB 没有存在。

    持久化的一些使用建议

    1.如果redis仅仅是用来做为缓存服务器的话,我们可以不使用任何的持久化。

    2.一般情况下我们会将两种持久化的方式都开启。redis优先加载AOF文件来回复数据。RDB的好处是快速。

    3.在主从节点中,RDB作为我们的备份数据,只在salve(从节点)上启动,同步时间可以设置的长一点,只留(save 900 1)这条规则就可以了。

    4.开启AOF的情况下,主从同步是时候必然会带来IO的性能影响,此时我们可以调大auto-aof-rewrite-min-size的值,比如5GB。来减少IO的频率

    5.不开启AOF的情况下,可以节省IO的性能影响,这是主从建通过RDB持久化同步,但如果主从都挂掉,影响较大

    展开全文
  • 文章目录持久化 、 RDB 快照存储、 AOF 只追加文件RDB 快照存储AOF 只追加文件如何选择持久化 持久化 、 RDB 快照存储、 AOF 只追加文件 redis可以将数据写入到磁盘中,在停机或宕机后,再次启动redis时,将磁盘中...

    持久化 、 RDB 快照存储、 AOF 只追加文件

    • redis可以将数据写入到磁盘中,在停机或宕机后,再次启动redis时,将磁盘中的备份数据加载到内存中恢复使用。这是redis的持久化。持久化有如下两种机制。

    RDB 快照存储

    • redis可以将内存中的数据写入磁盘进行持久化。在进行持久化时,redis会创建子进程来执行。

    • redis默认开启了快照持久化机制。

    • 机制:

      1. fork出一个子进程,专门进行数据持久化, 将内存中所有数据保存到单个rdb文件中(默认为dump.rdb)
      2. redis重启后, 会加载rdb文件中的数据到内存中
    • 触发方式

      • 配置中设置自动持久化策略
      • SAVE | BGSAVE | SHUTDOWN (前提是设置了自动持久化策略)
      • BGSAVE:执行BGSAVE命令,手动触发RDB持久化
      • SHUTDOWN:关闭redis时触发
    • 相关配置

        save 60 1000  # 多久执行一次自动快照操作 60秒内如果更新了1000次, 则持久化一次
        stop-writes-on-bgsave-error no  # 创建快照失败后,是否继续执行写命令
        rdbcompression yes  # 是否对快照文件进行压缩
        dbfilename dump.rdb  # 如何命名快照文件
        dir ./ # 快照文件保存的位置
      
        save   # 关闭RDB机制
      
    • 优点:

      1. 方便数据备份: 由于保存到单独的文件`中, 易于数据备份 (可以使用定时任务, 定时将文件发送给数据备份中心)
      2. 写时复制`: 子进程单独完成持久化操作, 父进程不参与IO操作, 最大化redis性能
      3. 恢复大量数据时, 速度优于 AOF
    • 缺点:

      1. 不是实时保存数据`, 如果redis意外停止工作(如电源断电等), 则可能会丢失一段时间的数据
      2. 数据量大时, fork进程会比较慢, 持久化时使redis响应速度变慢

    AOF 只追加文件

    • redis可以将执行的所有指令追加记录到文件中持久化存储,这是redis的另一种持久化机制。

    • redis默认未开启AOF机制。

    • Append-only file 只追加文件

      1. 只追加而 不是全部重新写入
      2. 追加命令, 而不是数据
    • 机制

      1. 主线程将 写命令 追加到aof_buf(缓冲区)中, 根据使用的策略不同, 子线程 将缓存区的命令写入到aof文件中 (不使用子进程)
      2. 当redis重启时, 会重新执行aof文件中的命令来恢复数据
      3. 如果同时开启了 RDB, 则优先使用 AOF
    • 文件修复

      1. 如果AOF出错 (磁盘满了/写入中途宕机等), 则redis重启时会拒绝使用该AOF文件

      2. 修复步骤

        1. 首先备份AOF文件
        2. 使用redis-check-aof工具进行修复 (一般会删除末尾无法恢复的命令)
        3. 重启redis服务器, 自动载入修复后的AOF文件, 进行数据恢复
    • 文件重写/压缩

      • AOF 提供了重写/压缩机制(优化命令), 以避免AOF文件过大
      • fork子进程来完成 AOF 重写
    • 相关配置

      appendonly no  # 是否开启AOF机制
      appendfsync everysec  # 多久将写入的内容同步到硬盘 每秒一次
      no-appendfsync-on-rewirete no  # 重写aof文件时是否执行同步操作
      auto-aof-rewrite-percentage 100  # 多久执行一次aof重写, 当aof文件的体积比上一次重写后的aof文件大了一倍时
      auto-aof-rewrite-min-size 64mb  # 多久执行一次aof重写,当aof文件体积大于64mb时
      
      appendfilename appendonly.aof  # aof文件名
      dir ./  # aof文件保存的位置(和rdb文件共享该配置)
      
      
      AOF机制记录操作的时机
      # appendfsync always  # 每个操作都写到磁盘中
      appendfsync everysec  # 每秒写一次磁盘,默认
      # appendfsync no  # 由操作系统决定写入磁盘的时机
      
    • 优点

      1. 更可靠` 默认每秒同步一次操作, 最多丢失一秒数据
        • 提供了三种策略, 还可以不同步/每次写同步
      2. 可以进行文件重写, 以避免AOF文件过大
    • 缺点:

      1. 相同数据集, AOF文件比RDB体积大, 恢复速度慢
      2. 除非是不同步情况, 否则普遍要比RDB `速度慢

    如何选择持久化

    • 对于更新频繁, 一致性要求不是非常高的数据 可以选择使用redis进行持久化存储

    • RDB or AOF

      • 数据安全性要求高, 都打开
      • 可以接受短时间的数据丢失, 只使用 RDB
      • 即使使用 AOF, 最好也开启 RDB, 因为便于备份并且回复速度快, bug更少
    • 项目中的应用

      • 使用redis进行一部分数据的持久化存储

        • 用户的阅读历史/搜索历史
    展开全文
  • akka-persistence-sql-async, 一个用于akka持久性的日志和快照存储 akka-persistence-sql-async 的日志和快照存储插件( akka持久化插件。 Akka-persistence-sql-async执行由 scalikejdbc异步查询,它提供非阻塞api来...
  • akka-persistence-gcp-datastore:akka-persistence-gcp-datastore是日记和快照存储插件,用于在数据存储模式下使用google cloud firestore进行akka-persistence
  • redis持久化方式之一是采用快照方式 。 在配置文件中比如save 900 2 表示的是,900s内有2次写入操作,就会触发快照行为。 小弟有几个问题: 1 比如在第40s有两次写入,那么是在40s进行快照还是在900s时进行快照? 2 ...
  • 它配置有RabbitMQ,MongoDB(快照存储),PostgreSQL(读存储),EventStore(GES)。 它针对.Net Core 2.2,并包含。 事件源/ CQRS架构 最常见的CQRS / ES架构如下图所示 该示例包含以下概念,每个概念如下所示 ...
  • redis快照存储模式报错

    千次阅读 2018-01-23 17:09:56
    当子进程将快照写入临时文件完毕后,用临时文件替换原有的快照文件,然后子进程退出。 Redis的client也可以使用"save"或者"bgsave"命令通知redis做一次快照持久化。save操作是在 主线程中保存快照的...
    • redis报错问题

    MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk. Commands that may modify the data set are disabled. Please check Redis logs for details about the error.

    redis被配置成保存数据库快照模式,但它现在不能持久化到磁盘,用来修改集合数据的命令不能用。请查看Redis日志的详细错误信息。

    1.Redis说明

    • 1.redis数据是如何持久化存储的?

    Redis中是把数据保存到内存中的,但是它也会定期的把数据写会到硬盘中。

    Redis保存数据有两种方式:

    1.快照模式(Snapshot)RDB

     它支持两种快照模式:

     a)定时快照,既按一定时间将内存中的数据保存到磁盘上。

     b)定量快照,既按数据变化一定次数后将数据保存到磁盘上。、

    2.写模式(Append Only File)AOF

     这种模式下Redis会把所有次改数据的命令,保存到一个只能追加的ASAP文件中,

    当Redis重启时,会把这个文件中的命令全部执行一遍。

    • 2.Redis数据保存到哪?

     是保存到一个文件中,在redis.conf可行配置

    dbfilename dump.rdb
    
    • 3.Redis快照保存的过程

    1)当有相关操作时,redis父进程调用fork(),创建子进程。

    2)父进程继续处理client请求,子进程负责将内存内容写入到临时文件。由于os的写时复制机制

    (copy on write)父子进程会共享相同的物理页面,当父进程处理写请求时os会为父进程要修改

    的页面创建副本,而不是写共享的页面。所以子进程的地址空间中的数据是fork()时刻整个数据库

    的一个快照。

    3)当子进程将快照写入临时文件完毕后,用临时文件替换原有的快照文件,然后子进程退出。

    Redis的client也可以使用"save"或者"bgsave"命令通知redis做一次快照持久化。save操作是在

    主线程中保存快照的,

    由于redis是用一个主线程(即单进程)来处理所有client的请求,这种方式将会阻塞所有client请求,

    不推荐使用。

     值得注意:每次保存 RDB 的时候,Redis都要fork()出一个子进程,并由子进程来进行实际的持久化工作。

    2.可能问题分析

    • 上面错误的原因

     Redis在持久化数据时,不能够保存到磁盘。导致redis抛出异常

    解决方案:

     1)config set stop-writes-on-bgsave-error no,这种方法不建议,只是让程序忽略这个异常,

    能够继续执行下去,数据不能持久化

    redis 127.0.0.1:6376> config set stop-writes-on-bgsave-error no
     2)加大存储空间

    3.linux overcommit 问题

     Linux对大部分申请内存的请求都回复"yes",以便能跑更多更大的程序。因为申请内存后,并不会马上使用内存。这种技术 叫做Overcommit。

     当内存不足时,会发生OOM killer(OOM=out-of-memory)。它会选择杀死一些进程(用户态进程,不是内核线程),以便 释放内存。

    vm.overcommit_memory:

    0 — 默认设置。个人理解:当应用进程尝试申请内存时,内核会做一个检测。内核将检查是否有足够的可用内存供应用进程使用;如果有足够的可用内存,内存申请允许;否则,内存申请失败,并把错误返回给应用进程。举个例子,比如1G的机器,A进程已经使用了500M,当有另外进程尝试malloc 500M的内存时,内核就会进行check,发现超出剩余可用内存,就会提示失败。
    1 — 对于内存的申请请求,内核不会做任何check,直到物理内存用完,触发OOM杀用户态进程。同样是上面的例子,1G的机器,A进程500M,B进程尝试malloc 500M,会成功,但是一旦kernel发现内存使用率接近1个G(内核有策略),就触发OOM,杀掉一些用户态的进程(有策略的杀)。
    2 — 当 请求申请的内存 >= SWAP内存大小 + 物理内存 * N,则拒绝此次内存申请。解释下这个N:N是一个百分比,根据overcommit_ratio/100来确定,比如overcommit_ratio=50,那么N就是50%。
    

    vm.overcommit_ratio

    只有当vm.overcommit_memory = 2的时候才会生效,内存可申请内存为

    SWAP内存大小 + 物理内存 * overcommit_ratio/100

          所以修vm.overcommit_memory参数也可以避免一些错误,修改vm.overcommit_memory=1

    在/etc/sysctl.conf 添加一项 'vm.overcommit_memory = 1' ,然后重启

    (或者运行命令'sysctl vm.overcommit_memory=1' )使其生效。

    展开全文
  • 直播快照相关接口 6. 直播快照接口 01 新建/编辑快照配置 02 获取快照配置列表 03 获取单条快照配置信息 04 快照开关 05 删除快照配置 07 快照查询接口 08 获取最新快照

    LiveQing云端直播点播流媒体软件: 提供设备接入; RTMP推流服务、RTMP分发、HLS分发、HTTP-FLV分发; 云端录像、云端录像检索、云端录像点播、云端录像下载; RTMP转推、推流鉴权验证、推流信息统计、播放信息统计; 直播分享、开放直播、拉转直播; 视频上传、视频转码、视频分享、视频下载; 后台管理、二次开发接口、防盗链、播放地址加密、播放器集成等。

    直播快照配置

    可配置项如下

    • 关联直播
    • 快照开关
    • 截取快照时间段
    • 快照保存(天)
    • 快照间隔(秒)
    • 分辨率(宽x高)

    在这里插入图片描述
    在这里插入图片描述

    直播快照相关接口

    6. 直播快照接口

    • 01 新建/编辑快照配置
    • 02 获取快照配置列表
    • 03 获取单条快照配置信息
    • 04 快照开关
    • 05 删除快照配置
    • 07 快照查询接口
    • 08 获取最新快照

    直播快照效果

    在这里插入图片描述

    获取更多信息

    安防流媒体互联直播-QQ交流群:615081503

    国标GB28181无插件LiveGBS-QQ交流群:947137753

    邮件:support@liveqing.com

    官网:www.liveqing.com

    Tel:189-5515-0114 (同微信)

    Copyright © LiveQing.com 2016-2019

    展开全文
  • 数据存储快照

    千次阅读 2014-10-10 16:54:20
    存储快照 存储快照技术SNIA(StorageNetworking Industry Association)对快照(Snapshot)的定义是:关于指定数据集合的一个完全可用拷贝,该拷贝包括相应数据在某个时间点(拷贝开始的时间点)的映像。快照可以...
  • 存储快照

    2019-10-01 12:40:52
    说起快照,我已经使用很久了,一直使用vmware workstation的快照,之前没有认真了解一下快照,现在接触到了存储快照,不得以要认真对待了。 快照有什么作用? 对于我来说,快照的作用就是当我所系统搞坏了之后能...
  • 2.概述 ​ 分布式快照是整个 Flink 计算框架中非常核心的模块,Flink 的 ...Flink 的分布式快照存储部分设计抽象出了大致 5 个层次: 最底层是快照的物理存储,包括内存和文件系统两种形式 再上层是 CheckpointStre.
  • SNIA(存储网络行业协会)对于快照的定义是:关于指定数据集合的一个完全可用拷贝,该拷贝包括相应数据在某个时间点(拷贝开始的时间点)的映像。快照可以是其所表示的数据的一个副本,也可以是数据的一个复制品。 快照...
  • 存储快照技术及各种存储快照技术的比较 转载自:http://www.cnw.com.cn/storage-case/htm2012/20120316_243409.shtml 什么是存储快照技术? 存储快照技术主要是在操作系统以及存储技术上实现...
  • 存储快照的实现

    2019-01-26 10:56:48
    存储网络行业协会SNIA(StorageNetworking Industry Association)快照的定义:关于指定数据集合的一个完全可用拷贝,该拷贝包括相应数据在某个时间点(拷贝开始的时间点)的映像。快照可以是其所表示的数据的一个...
  • 存储网络行业协会SNIA(StorageNetworking Industry Association)快照的定义:关于指定数据集合的一个完全可用拷贝,该拷贝包括相应数据在某个时间点(拷贝开始的时间点)的映像。快照可以是其所表示的数据的一个...
  • ceph存储 ceph集群存储快照概念

    千次阅读 2014-12-13 15:14:25
    存储网络行业协会SNIA(StorageNetworking Industry Association)对快照(Snapshot)的定义是:关于指定数据集合的一个完全可用拷贝,该拷贝包括相应数据在某个时间点(拷贝开始的时间点)的映像。快照可以是其所...
  • 存储快照实现原理

    2019-06-03 15:32:08
    存储快照有两种实现方式:COW(写时复制Copy-On-Write)、ROW(写重定向Redirect-On-Write),两种实现方法有区别,造成读写性能、应用场景有比较大的区别。 1 COW 原理见下图(从网上找的,没自己画)。 1)原卷数据是A~G...
  • 存储快照的原理

    千次阅读 2019-04-23 17:07:53
    存储快照有两种实现方式:COW(写时复制Copy-On-Write)、ROW(写重定向Redirect-On-Write),两种实现方法有区别,造成读写性能、应用场景有比较大的区别。COW: 原理见下图(从网上找的,没自己画)。 1)原卷数据是A~G...
  • masayuri:快照网站的存储

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 5,632
精华内容 2,252
关键字:

快照存储