数据持久化

redis的 rdb 和 aof 持久化的区别,性能对比

拜拜、爱过 提交于 2019-11-30 08:14:40
Redis是一种高级key-value数据库 。它跟memcached类似,不过数据可以持久化,而且支持的数据类型很丰富。有字符串,链表,集 合和有序集合。 支持在服务器端计算集合的并,交和补集(difference)等,还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务 器。 由于Redis的数据都存放在内存中,如果没有配置持久化,redis重启后数据就全丢失了,于是需要开启redis的持久化功能,将数据保存到磁 盘上,当redis重启后,可以从磁盘中恢复数据。 redis提供两种方式进行持久化 RDB持久化 (原理是将Reids在内存中的数据库记录定时 dump到磁盘上的RDB持久化), AOF(append only file)持久化 (原理是将Reids的操作日志以追加的方式写入文件)。 2、二者的区别 RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘,实际操作过程是fork一个子进程,先将数据集写入临时文件,写入成功后,再替换之前的文件,用二进制压缩存储。 AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作,查询操作不会记录,以文本的方式记录,可以打开文件看到详细的操作记录。 3、二者优缺点 RDB存在哪些优势呢? 1). 一旦采用该方式,那么你的整个Redis数据库将只包含一个文件,这对于文件备份而言是非常完美的。比如

简单理解Hibernate三种状态的概念及互相转化

[亡魂溺海] 提交于 2019-11-30 07:24:27
本文描述了Hibernate三种状态的概念及互相转化。Java对象的生命周期中有三种状态,而且互相转化。它们分别是临时状态,持久化状态,以及游离状态。 AD:51CTO学院:IT精品课程在线看! 在Hibernate中有三种状态,对它的深入理解,才能更好的理解hibernate的运行机理,刚开始不太注意这些概念,后来发现它是重要的。对于理解hibernate,JVM和sql的关系有更好的理解。对于需要持久化的JAVA对象,在它的生命周期中有三种状态,而且互相转化。 Hibernate三种状态之一:临时状态(Transient):用new创建的对象,它没有持久化,没有处于Session中,处于此状态的对象叫临时对象; Hibernate三种状态之二:持久化状态(Persistent):已经持久化,加入到了Session缓存中。如通过hibernate语句保存的对象。处于此状态的对象叫持久对象; Hibernate三种状态之三:游离状态(Detached):持久化对象脱离了Session的对象。如Session缓存被清空的对象。特点:已经持久化,但不在Session缓存中。处于此状态的对象叫游离对象; Hibernate三种状态 Hibernate三种状态中游离对象和临时对象异同: 两者都不会被Session关联,对象属性和数据库可能不一致;

redis的持久化方案

放肆的年华 提交于 2019-11-30 07:23:21
redis的持久化有两种方案: 一.Snapshotting快照 快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置 redis在 n 秒内如果超过 m 个 key 被修改就自动做快照,下面是默认的快照保存配置: save 900 1 #900 秒内如果超过 1 个 key 被修改,则发起快照保存 save 300 10 #300 秒内容如超过 10 个 key 被修改,则发起快照保存 save 60 10000 下面介绍详细的快照保存过程: 1.redis 调用 fork,现在有了子进程和父进程。 2. 父进程继续处理 client 请求,子进程负责将内存内容写入到临时文件。由于 os 的实时复制机制( copy on write)父子进程会共享相同的物理页面,当父进程处理写请求时 os 会为父进程要修改的页面创建副本,而不是写共享的页面。所以子进程地址空间内的数据是 fork时刻整个数据库的一个快照。 3.当子进程将快照写入临时文件完毕后,用临时文件替换原来的快照文件,然后子进程退出。client 也可以使用 save 或者 bgsave 命令通知 redis 做一次快照持久化。 save 操作是在主线程中保存快照的,由于 redis 是用一个主线程来处理所有

Redis持久化机制

纵然是瞬间 提交于 2019-11-30 07:00:53
Redis持久化机制 众所周知,Redis是一个内存数据库。但它与其它内存数据库(如memcache)等有一个很大的区别,就是Redis可以持久化到磁盘。有了持久化方案,Redis就可以对数据进行备份、恢复、复制。 Redis提供了两种持久化方案:RDB和AOF。在Redis 4.0中,提供了一个新特性:两者的混合持久化。下面将介绍Redis的各种持久化方案的原理和配置。 使用 info persistence 命令可以查看当前所有有关持久化的信息: RDB 原理 RDB持久化是通过快照方式来完成的。当达到触发条件时,Redis会自动将内存中所有数据以二进制方式生成一份副本并存储在硬盘上。 在配置文件可以配置当前配置的备份文件和目录,使用 config 命令也可以查看和设置: 触发条件 RDB分为主动触发和被动触发。 主动触发指的是客户端执行 save 和 bgsave 命令会进行持久化。 执行save会使Redis处于阻塞状态,不会响应任何其他客户端发来的请求,直到RDB快照文件执行完毕,需要谨慎使用。 bgsave即background save,后台保存。当执行bgsave命令时,Redis会 fork 出一个子进程来执行快照操作。需要注意的是,在fork子进程的过程中,Redis是阻塞的。而当子进程创建完成后,Redis就可以继续响应客户端的请求了。 子进程创建完成以后

redis持久化机制和内存管理

倾然丶 夕夏残阳落幕 提交于 2019-11-30 06:27:20
  redis持久化方式有两种:RDB方式和AOF方式   1、RDB方式:内存快照,在指定的时间间隔对数据进行快照存储,支持在客户端直接BGSAVE或者SAVE命令来创建一个内存快照,BGSAVE会fork一个子进程将快照写入磁盘,父进程仍可处理其它命令,SAVE则执行过程中不处理其它命令;在redis.conf可以调整save配置选项来设置持久化的触发策略,当在规定时间内Redis发生了写操作的个数满足设定的条件触发持久化。   2、AOF方式:记录每次对服务器的写操作,当服务器重启时会重新执行这些命令来恢复数据,通过在redis.conf中配置appendonly yes开启AOF方式 ,通过调整appendsync参数来设置同步的策略   RDB方式优点:对性能影响小、恢复数据快,缺点:会丢失数据、fork子进程会影响提供服务的能力。   AOF方式优点:安全、可容灾、可读 缺点:文件体积大、性能损耗、数据恢复慢   redis内存管理   在redis.conf中通过maxmemory 来配置最大内存,通过maxmemory-policy来配置到达阈值的策略,可选策略如下   其中LRU (最近最少使用) 根据数据的历史访问记录来淘汰数据,LFU(历史访问次数),历史访问频率来淘汰数据,具体可参考redis官网。   reids还可以配置内存压缩

Scrapy框架的基本组成及功能使用

本秂侑毒 提交于 2019-11-30 06:17:20
1.什么是scrapy? Scrapy是一个为了爬取网站数据,提取结构性数据而编写的应用框架。框架的本质就是集成各种功能、具有很强通用性的项目模板。 2.安装    Linux: pip3 install scrapy   Windows:===》见Twisted安装 a. pip3 install wheel b. 下载twisted http: / / www.lfd.uci.edu / ~gohlke / pythonlibs / #twisted c. 进入下载目录,执行 pip3 install Twisted‑ 17.1 . 0 ‑cp35‑cp35m‑win_amd64.whl d. pip3 install pywin32 e. pip3 install scrapy 3.基础使用===》相关命令都是在命令行执行   3.1.创建项目:scrapy startproject 项目名称   3.2.创建爬虫应用程序:       cd project_name(进入项目目录)       scrapy genspider 应用名称 爬取网页的起始url (例如:scrapy genspider qiubai www.qiushibaike.com)       在步骤2执行完毕后,会在项目的spiders中生成一个应用名的py爬虫文件   3.3

Redis持久化

只谈情不闲聊 提交于 2019-11-30 05:55:59
 这节介绍Redis的持久化,包括RDB和AOF两种方式。 1.RDB持久化  Redis能够将内存中的数据持久化到RDB文件中,避免数据丢失。RDB文件的格式如下示:  第一部分是开头的5个字节,值为REDIS,第二部分是长度为4个字节的版本号,值为一个字符串表示的整形。database部分包含零个或任意多个数据库,以及各个数据库中的键值对数据,database的结构如下示:  EOF为1字节的结束符号,check_sum为8字节长的校验和,这个校验和是通过前面4个部分计算出来的。  可以使用SAVE或者BGSAVE命令生成RDB文件。SAVE命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在服务器进程阻塞期间,服务器不能处理任何命令请求。BGSAVE命令则会派生出一个子进程,然后由子进程负责创建RDB文件,父进程继续处理命令请求。  BGSAVE除了可以通过命令来手动执行外,还可以通过配置项来定期执行,该功能可以将某个时间点上的数据库状态保存到一个RDB文件中。配置格式为: save N M  表示服务器在N秒内对数据进行了至少M次修改。该配置可以有多个,只要满足其中一个条件就会触发BGSAVE。当BGSAVE命令执行时,父进程会fork一个子进程,子进程会将当前内存中的数据写到磁盘上的一个临时文件。当临时文件写完后会将原来的RDB文件替换掉,这样的好处是可以使用

Redis 持久化

泪湿孤枕 提交于 2019-11-30 05:54:43
Redis 有两种持久化方案,RDB (Redis DataBase)和 AOF (Append Only File)。 RDB 详解 RDB 是 Redis 默认的持久化方案。在指定的时间间隔内,执行指定次数的写操作,则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。 从配置文件了解RDB 打开 redis.conf 文件,找到 SNAPSHOTTING 对应内容 1 RDB核心规则配置(重点) save <seconds> <changes> # save "" save 900 1 save 300 10 save 60 10000 解说:save <指定时间间隔> <执行指定次数更新操作>,满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改,300秒内有10个更改以及60秒内有10000个更改,则将内存中的数据快照写入磁盘。 若不想用RDB方案,可以把 save "" 的注释打开,下面三个注释。 2 指定本地数据库文件名,一般采用默认的 dump.rdb dbfilename dump.rdb 3 指定本地数据库存放目录,一般也用默认配置 dir ./ 4 默认开启数据压缩 rdbcompression yes 解说:配置存储至本地数据库时是否压缩数据,默认为yes

Java----IO流

萝らか妹 提交于 2019-11-30 04:29:17
1、标准设备输入、输出流: 2、 打印流 :把不同类型的数据 打印到控制台(标准输出设备)或者 文件中。 System.out————>标准输出流。out的类型为PrintStream类型。 3、 数据流 :用来读取 / 写出 基本数据类型和String的变量。 4、 对象流:用来持久化 和 反持久化对象 相比于比DataInput/OutStream更强大: 数据流只能持久化 和 反持久化 基本类型变量。 而对象流:还可以持久 和 反持久化一个对象。对象中可以包含基本类型的变量 和 引用变量。 可序列化的对象要满足的要求: 要 实现Serializable 接口 为类提供一个全局常量:可序列化版本号:private static final long serialVersionUID = 1122L; 序列化版本号的目的: 让序列化 和 反序列化时,有一个相同的版本号,反序列化时,能够成功还原成 原来的版本对象。 假若 没有显示定义这个序列化版本号,则程序运行时会自己生成一个版本号,若我们修改了类的属性,则下次运行程序的序列化版本号就会改变。那么我们再反序列化时,就会失败。 static 和 transient修饰属性,属性不能倍序列化。 5、 任意存取文件流:RandomAccessFile 继承体系: 应用:迅雷多线程断点下载文件 来源: https://blog.csdn

spring-session(一)揭秘

浪尽此生 提交于 2019-11-30 01:41:53
引自: spring-session(一)揭秘 前言 在开始spring-session揭秘之前,先做下热脑(活动活动脑子)运动。主要从以下三个方面进行热脑: 为什么要spring-session 比较traditional-session方案和spring-session方案 JSR340规范与spring-session的透明继承 一.为什么要spring-session 在传统单机web应用中,一般使用tomcat/jetty等web容器时,用户的session都是由容器管理。浏览器使用cookie中记录sessionId,容器根据sessionId判断用户是否存在会话session。这里的限制是,session存储在web容器中,被单台服务器容器管理。 但是网站主键演变,分布式应用和集群是趋势(提高性能)。此时用户的请求可能被负载分发至不同的服务器,此时传统的web容器管理用户会话session的方式即行不通。除非集群或者分布式web应用能够共享session,尽管tomcat等支持这样做。但是这样存在以下两点问题: 需要侵入web容器,提高问题的复杂 web容器之间共享session,集群机器之间势必要交互耦合 基于这些,必须提供新的可靠的集群分布式/集群session的解决方案,突破traditional-session单机限制(即web容器session方式