数据持久化

Redis是什么? Redis (REmote DIctionary Server)是一个开源（BSD许可），内存存储的数据结构服务器，可用作数据库，高速缓存和消息队列,是一个高性能的key-value数据库。 Redis与其他key-value缓存产品有以下三个特点： Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。 Redis不仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。 Redis支持数据的备份，即master-slave模式的数据备份。 为什么要用Redis 性能极高 – Redis读的速度是110000次/s,写的速度是81000次/s 。 丰富的数据类型 – Redis支持Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。 原子 – Redis的所有操作都是原子性的，即要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。 丰富的特性 – Redis还支持publish/subscribe, key过期等特性。 Redis的数据类型及使用场景 Redis支持五种数据类型：string（字符串），hash（哈希），list（列表），set（集合

一个老外的有关Redis的博客文章中提到一个有趣的事情：它们在测试期间获得的延迟图。为了持久化Redis的数据到磁盘（例如：RDB持久化），Redis需要调用fork()系统命令。 通常使用物理服务器和大多数虚拟机管理程序进行fork是很快的，即使很大的进程也是如此。 然而，Xen的fork()速度很慢，因此对于某些EC2实例类型（以及其他虚拟服务器提供程序），每次父进程调用fork()以便进行RDB持久化时，可能会出现严重的延迟峰值。 如下图所示，清晰的展示了延迟峰值： 您可以想象一下，如果您在fork()的时候做一个延迟测试，那么在父进程fork()的时候，所有请求将延迟一秒（以上图为例）。 这将产生大量具有高延迟的样本，并且将影响99%的结果。 要更改实例类型，配置，设置或其他任何内容以改善此行为是一个好主意，并且有些用例即使单个请求具有过高延迟也是不可接受的。然而很明显的是，每30分钟发生1秒的延迟峰值不是很明显，因为这与在请求中均匀分布延迟峰值有很大不同。 如果是均匀分布的峰值，如果访问某个页面需要对Redis服务器执行大量请求，则访问页面很可能会碰到延迟：这会严重影响服务质量。 然而，如上图所示，每运行30分钟后1秒的延迟是完全不同的事情。具有良好延迟表现的百分比随着请求数量的增加而变得更好，因为请求越多，这个延迟就越不可能在样本中过度表示出来，反而会被隐藏

原文: http://blog.gqylpy.com/gqy/363 基于终端指令的持久化存储 前提：保证爬虫文件中的 parse 方法的返回值为可迭代数据类型(通常为list/dict)。 该返回值可以通过终端指令的形式写入指定格式的文件中进行持久化存储。 执行如下命令进行持久化存储： scrapy crawl 应用名称 -o xx.文件格式 其支持的文件格式有： 'json', 'jsonlines', 'jl', 'csv', 'xml', 'marshal', 'pickle' 基于管道的持久化存储 Scrapy框架为我们提供了高效、便捷的持久化操作功能，我们直接使用即可。 在使用之前，我们先来认识下这两个文件： items.py ： 数据结构模板文件，用于定义数据属性。 pipelines.py ： 管道文件，接收数据(items)，进行持久化操作。 ---------------------------↓ 持久化流程： 应用文件爬取到数据后，将数据封装到 items 对象中。 使用 yield 关键字将 items 对象提交给 pipelines 管道进行持久化操作。 在管道文件中的类中的 process_item 方法接收爬虫文件提交过来的 item 对象， 然后编写持久化存储的代码将 item 对象中存储的数据进行持久化存储。 注意： 在 settings.py

4. redis持久化 Redis 是一种内存型数据库，一旦服务器进程退出，数据库的数据就会丢失，为了解决这个问题， Redis 提供了两种持久化的方案，将内存中的数据保存到磁盘中，避免数据的丢失。 4.1 RDB持久化 redis 提供了 RDB持久化 的功能，这个功能可以将 redis 在内存中的的状态保存到硬盘中，它可以 手动执行。 也可以再 redis.conf 中配置， 定期执行 。 RDB持久化产生的RDB文件是一个 经过压缩 的 二进制文件 ，这个文件被保存在硬盘中，redis可以通过这个文件还原数据库当时的状态。 优点: 速度快，适合做备份，主从复制就是基于RDB持久化功能实现 配置参数: touch redis-rdb.conf 加入如下的内容 daemonize yes #后台运行redis port 6379 #指定redis的端口 logfile /data/6379/redis.log #redis日志文件 dir /data/6379/ #定义持久化文件存储位置，需要手动创建文件夹 dbfilename redis-rdb.rdb #rdb持久化文件 bind 0.0.0.0 #redis启动地址 save 10 5 #10秒内，超过5个修改类的操作，就触发持久化 手动触发 127.0.0.1:6379> save OK 4.2 AOF持久化 AOF

1.3.1 RDB 快照存储 将内存中的所有数据完整的保存到硬盘中 机制 fork出一个子进程,专门进行数据持久化, 将内存中所有数据保存到单个rdb文件中(默认为dump.rdb) redis重启后, 会加载rdb文件中的数据到内存中 触发方式 配置中设置自动持久化策略 SAVE | BGSAVE | SHUTDOWN (前提是设置了自动持久化策略) 相关配置 save 60 1000 # 多久执行一次自动快照操作 60秒内如果更新了1000次, 则持久化一次 stop-writes-on-bgsave-error no # 创建快照失败后,是否继续执行写命令 rdbcompression yes # 是否对快照文件进行压缩 dbfilename dump.rdb # 如何命名快照文件 dir ./ # 快照文件保存的位置 save # 关闭RDB机制 优缺点 优点 方便数据备份: 由于保存到单独的文件中, 易于数据备份 (可以使用定时任务, 定时将文件发送给数据备份中心) 写时复制: 子进程单独完成持久化操作, 父进程不参与IO操作, 最大化redis性能 恢复大量数据时, 速度优于 AOF 缺点 不是实时保存数据, 如果redis意外停止工作(如电源断电等), 则可能会丢失一段时间的数据 数据量大时, fork进程会比较慢, 持久化时使redis响应速度变慢 1.3.2

一、常用配置属性 　　以下配置文件目录均为：${activemq_home}/conf/activemq.xml 　　1、定期扫描清理 　　　　ActiveMQ中有一项功能：Delete Inactive Destination。可以处理 “ 没有消费者且未处理的Destination”，也就是 queue 或者 topic 在规定时间内，没有入队记录或者有效订阅，会被清理删除。 　　　　下面基于Queue的配置，Topic的配置类似。 　　　　 　　　　其中属性定义：schedulePeriodForDestinationPurge - 必填。声明扫描闲置队列的周期，单位毫秒。默认值0，为不扫描。 　　　　　　　　　　　gcInactiveDestinations - 必填。针对Destination的配置，声明Broker扫描闲置队列时，是否扫描此队列。默认值false 　　　　　　　　　　　inactiveTimoutBeforeGC - 选填。配合gcInactiveDestinations=true时才生效。声明Destination闲置多久可以进行删除，单位毫秒。默认值60。 　　2、存储空间设置 　　　　 　　　　其中的配置标签： memoryUsage - 表示ActiveMQ使用的内存

今天呢，我就详细的写着 Hibernate框架的一种检索方式：Criteria查询。下面我写的这些案例，可能对于大牛没有什么好看的，但是对于初学者来说，却是一笔财富。 首先我们要知道的检索方式： Hibernate框架提供了5种检索对象的方式 1.导航对象图检索方式：根据已经加载的对象导航到其他对象 2.OID检索方式：按照对象的OID来检索对象 3.HQL检索方式：使用面向对象的HQL查询语言 4.QBC检索方式：使用QBC(Query By Criteria)API来检索对象，这种API封装了基于字符串形式的查询语句，提供了更加面向对象的查询接口 5.本地SQL检索方式：使用本地数据库的SQL查询语句 什么是Criteria Criteria是一种比hql更面向对象的查询方式。 Criteria 可使用 Criterion 和 Projection 设置查询条件。可以设置 FetchMode(联合查询抓取的模式 ) ，设置排序方式，Criteria 还可以设置 FlushModel （冲刷 Session 的方式）和 LockMode。 Criteria查询 就是 通过面向对象化的设计，将数据查询条件封装为一个对象 Criteria是一个接口，它继承了 另一个接口。 它里面有很多的方法，看图说话： 有了这些方法，我们可以再深度研究，这个方法里面的参数，有了什么接口或是类的类型

piplines的使用 取消setings.py文件内管道的注释，开启数据管道，使得爬取到的数据可以传送过来。 初始代码解释 利用重写spider的方法实现功能 # 初始化SpiderdmPipeline类时调用一次 def __init__(self): # 创建数据库的连接对象 # 数据表的创建 pass # 启动爬虫时调用一次 def open_spider(self, spider): # 同__init__方法，实现爬虫开始时，只需要执行一次的操作。 pass # 每传送一条数据就掉用一次 def process_item(self, item, spider): # 实现处理每一条数据保存和处理的代码 # 或者直接交给下一个管道处理 return item # 关闭爬虫时掉用一次 def close_spider(self, spider): # 断开数据库连接 # 释放资源等，在关闭爬虫前需要的操作。 pass 多个管道处理实现数据流水线处理 创建SpiderdmPipeline_1类 注册SpiderdmPipeline_1类并设置与资源调度器的距离 SpiderdmPipeline_1 先拿到数据后，处理item数据。return 一个item给下一个比它距离数值更大的下一个管道处理（SpiderdmPipeline），注意return返回的只是 Item

1.项目中缓存是如何使用的？为什么要用缓存？缓存使用不当会造成什么后果？ 面试题剖析 为什么要用缓存？ 用缓存，主要有两个用途： 高性能 、 高并发 。 高性能 假设这么个场景，你有个操作，一个请求过来，吭哧吭哧你各种乱七八糟操作 mysql，半天查出来一个结果，耗时 600ms。但是这个结果可能接下来几个小时都不会变了，或者变了也可以不用立即反馈给用户。那么此时咋办？ 缓存啊，折腾 600ms 查出来的结果，扔缓存里，一个 key 对应一个 value，下次再有人查，别走 mysql 折腾 600ms 了，直接从缓存里，通过一个 key 查出来一个 value，2ms 搞定。性能提升 300 倍。 就是说对于一些需要复杂操作耗时查出来的结果，且确定后面不怎么变化，但是有很多读请求，那么直接将查询出来的结果放在缓存中，后面直接读缓存就好。 高并发 mysql 这么重的数据库，压根儿设计不是让你玩儿高并发的，虽然也可以玩儿，但是天然支持不好。mysql 单机支撑到 2000QPS 也开始容易报警了。 所以要是你有个系统，高峰期一秒钟过来的请求有 1万，那一个 mysql 单机绝对会死掉。你这个时候就只能上缓存，把很多数据放缓存，别放 mysql。缓存功能简单，说白了就是 key-value 式操作，单机支撑的并发量轻松一秒几万十几万，支撑高并发 so easy。单机承载并发量是

ActiveMQ中对于投递模式设置为持久化的消息， broker 接收到到消息之后，会 先把消息存储到存储介质 ，然后 再转发到消息的监听者 ActiveMQ持久化方式：AMQ、KahaDB、JDBC、LevelDB 持久化配置路径： ActiveMQ\apache-activemq\conf\activemq.xml Message保存方式 PERSISTENT ：保存到磁盘，consumer消费之后，message被删除。 NON_PERSISTENT ：保存到内存，消费之后message被清除。 kahaDB 持久化为文件（默认） 所有消息顺序添加到一个日志文件中，同时另外有一个索引文件记录指向这些日志的存储地址，还有一个事务日志用于消息回复操作。 特点：基于文件的本地数据库储存形式，是一个支持事务，可靠，高性能，可扩展的消息存储器。 在data/kahadb这个目录下，会生成四个文件，来完成消息持久化 db.data 它是消息的索引文件，本质上是 B-Tree（B树） ，使用B-Tree作为索引指向 db-*.log 里面存储的消息 一旦这个消息不在被需要,数据文件可以被删除或归档。 db.redo 用来进行消息恢复 db-*.log 存储消息内容。新的数据以 APPEND 的方式追加到日志文件末尾。属于顺序写入，因此消息存储是比较快的。默认是 32M ，达到阀值会自动递增