数据持久化

一、redis持久化的意义 redis持久化的意义，在于故障恢复 比如你部署了一个redis，作为cache缓存，当然也可以保存一些较为重要的数据 如果没有持久化的话，redis遇到灾难性故障的时候，就会丢失所有的数据 如果通过持久化将数据搞一份儿在磁盘上去，然后定期比如说同步和备份到一些云存储服务上去，那么就可以保证数据不丢失全部，还是可以恢复一部分数据回来的 二、为什么要持久化 我们已经知道对于一个企业级的redis架构来说，持久化是不可减少的 企业级redis集群架构：海量数据、高并发、高可用 持久化主要是做灾难恢复，数据恢复，也可以归类到高可用的一个环节里面去 比如你redis整个挂了，然后redis就不可用了，你要做的事情是让redis变得可用，尽快变得可用 重启redis，尽快让它对外提供服务，但是就像上一讲说，如果你没做数据备份，这个时候redis启动了，也不可用啊，数据都没了 很可能说，大量的请求过来，缓存全部无法命中，在redis里根本找不到数据，这个时候就死定了，缓存雪崩问题，所有请求，没有在redis命中，就会去mysql数据库这种数据源头中去找，一下子mysql承接高并发，然后就挂了 mysql挂掉，你都没法去找数据恢复到redis里面去，redis的数据从哪儿来？从mysql来。。。 如果你把redis的持久化做好，备份和恢复方案做到企业级的程度

redis的 rdb 和 aof 持久化的区别 url: http://ptc.35.com/?p=275 aof，rdb是两种 redis持久化的机制。用于crash后，redis的恢复。 rdb的特性如下： Code: fork一个进程，遍历hash table，利用copy on write， 把整个db dump保存下来 。 save, shutdown, slave 命令会触发这个操作。 粒度比较大，如果save, shutdown, slave 之前crash了，则中间的操作没办法恢复 。 aof有如下特性： Code: 把写操作指令，持续的写到一个类似日志文件里。（类似于从postgresql等数据库导出sql一样，只记录写操作） 粒度较小，crash之后，只有crash之前没有来得及做日志的操作没办法恢复。 两种区别就是，一 个是持续的用日志记录写操作，crash后利用日志恢复 ； 一个是平时写操作的时候不触发写，只有手动提交save命令，或者是关闭命令时，才触发备份操作 。 选择的标准，就是看系统是愿意 牺牲一些性能，换取更高的缓存一致性（aof ），还是愿意 写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了 。 redis的 RDB 和 AOF

Redis其实就是一个用C语言写的一个程序，这个程序用来存储 key-value数据，数据先放在内存，然后写入磁盘指定位置。 这么理解十分肤浅，但tm好像就是这样啊。 下面我们梳理一下Redis存储两种方式： RDB和AOF 第一种方式：RDB(Redis DataBase) RDB是将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。 在Redis中，默认开启RDB方式进行数据存储，redis.conf中的 具体配置参数如下 ； #dbfilename：持久化数据存储在本地的文件 dbfilename dump.rdb （dump.rdb为存储的文件名，redis通过io流将内存中的数据，写入该文档） #dir：持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下 dir ./ #save时间，以下分别表示更改了1个key时间隔900s进行持久化存储；更改了10个key时间隔300s进行存储；更改10000个key时间隔60s进行存储。 save 900 1 save 300 10 save 60 10000 这里我们可以继续添加，也可以修改参数 比如 save 10 10000 10000个数据时间间隔10s就持久化 使用命令进行持久化save存储： .

1.基于终端指令的持久化存储 保证爬虫文件的parse方法中有可迭代类型对象（通常为列表or字典）的返回，该返回值可以通过终端指令的形式写入指定格式的文件中进行持久化操作。 执行输出指定格式进行存储：将爬取到的数据写入不同格式的文件中进行存储 scrapy crawl 爬虫名称 -o xxx.json scrapy crawl 爬虫名称 -o xxx.xml scrapy crawl 爬虫名称 -o xxx.csv 2.基于管道的持久化存储 scrapy框架中已经为我们专门集成好了高效、便捷的持久化操作功能，我们直接使用即可。要想使用scrapy的持久化操作功能，我们首先来认识如下两个文件： items.py：数据结构模板文件。定义数据属性。 pipelines.py：管道文件。接收数据（items），进行持久化操作。 持久化流程： 1.爬虫文件爬取到数据后，需要将数据封装到items对象中。 2.使用yield关键字将items对象提交给pipelines管道进行持久化操作。 3.在管道文件中的process_item方法中接收爬虫文件提交过来的item对象，然后编写持久化存储的代码将item对象中存储的数据进行持久化存储 4.settings.py配置文件中开启管道 - 将糗事百科首页中的段子和作者数据爬取下来，然后进行持久化存储 - 爬虫文件：qiubaiDemo.py #

RDB（快照模式） 优点：全量数据快照，文件小，恢复快 缺点：无法保存最近一次快照之后的数据 AOF（Append-Only-File）追加模式 优点：可读性高，适合保存增量数据，数据不易丢失 缺点：文件体积大，恢复时间长 来源： https://www.cnblogs.com/lisongyu/p/11576920.html

RDB和AOF的配置 rdb 概述 RDB是在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复。 优点：使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能 缺点：RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候 配置信息 #dbfilename：持久化数据存储在本地的文件 dbfilename dump.rdb #dir：持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下 dir ./ ##snapshot触发的时机，save <seconds> <changes> ##如下为900秒后，至少有一个变更操作，才会snapshot ##对于此值的设置，需要谨慎，评估系统的变更操作密集程度 ##可以通过“save “””来关闭snapshot功能 #save时间，以下分别表示更改了1个key时间隔900s进行持久化存储；更改了10个key300s进行存储；更改10000个key60s进行存储。 save 900 1 save 300 10 save 60 10000 ##当snapshot时出现错误无法继续时，是否阻塞客户端“变更操作”，“错误

欢迎转载： 攻城狮不是猫 1、RDB和AOF两种持久化机制的介绍 RDB持久化机制，对redis中的数据执行周期性的持久化 AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集 如果我们想要redis仅仅作为纯内存的缓存来用，那么可以禁止RDB和AOF所有的持久化机制 通过RDB或AOF，都可以将redis内存中的数据给持久化到磁盘上面来，然后可以将这些数据备份到别的地方去，比如说阿里云，云服务 如果redis挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷贝回来之前的数据，放到指定的目录中，然后重新启动redis，redis就会自动根据持久化数据文件中的数据，去恢复内存中的数据，继续对外提供服务 如果同时使用RDB和AOF两种持久化机制，那么在redis重启的时候，会使用AOF来重新构建数据，因为AOF中的数据更加完整 ------------------------------------------------------------------------------------- 2、RDB持久化机制的优点 （1）RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备

RDB持久化 1：redis中RDB持久化方式也叫快照方式是redis的默认持久化方式，当符合一定条件时redis会对当前数据库中所有的数据生成一份快照文件并保存到磁盘中。 2：redis.conf中有两个参数dbfilename和dir分别指定了rdb文件的名称和保存路径。默认文件名dump.rdb是一个二进制文件，默认保存路径./当前目录。 3：redis启动时会在当前目录下加载dump.rdb文件，然后使用此文件恢复数据。这就是我们在不同目录下启动redis会发现数据丢失的原因。当然我们也可以更改dir的配置让它指定一个绝对目录。 4：RDB持久化触发条件和关闭 save 900 1 到900秒后发现至少一个key被修改 save 300 10 到900秒后发现至少10个key被修改 save 60 10000 到60秒后发现至少10000个key被修改 以上三个条件任意一个满足则启动持久化，另外我们也可以根据业务来自行设定持久化触发条件。 注释掉触发条件新增一个配置save “” 就会关闭RDB功能，但是如果在redis-cli中手动执行save或bgsave命令会生成dump.rdb文件执行持久化。 5：RDB原理 当开始持久化时redis会调用一个fork函数复制当前进程生成一个子进程，子进程就会将当前数据库中所有的数据写入一个临时文件，写完后替换dump.rdb文件

aof，rdb是两种 redis持久化的机制。用于crash后，redis的恢复。 db的特性如下： Code: fork一个进程，遍历hash table，利用copy on write，把整个db dump保存下来。 save, shutdown, slave 命令会触发这个操作。 粒度比较大，如果save, shutdown, slave 之前crash了，则中间的操作没办法恢复。 aof有如下特性： Code: 把写操作指令，持续的写到一个类似日志文件里。（类似于从postgresql等数据库导出sql一样，只记录写操作） 粒度较小，crash之后，只有crash之前没有来得及做日志的操作没办法恢复。 两种区别就是，一个是持续的用日志记录写操作，crash后利用日志恢复；一个是平时写操作的时候不触发写，只有手动提交save命令，或者是关闭命令时，才触发备份操作。 选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。 redis的rdb和aof模式性能对比 由于是同一台机器，进行相对对比，我就不列配置了。系统是debian testing，kernel 3.2 686。redis 2

Redis强大的功能很大部分是由于他把数据缓存在内存中，为了使Redis在重启的时候，数据不丢失，就需要已某种方式把数据持久化到磁盘中。Redis持久化的方式有俩种，RDB和AOF。 RDB：快照方式，允许你每隔一段时间对内存数据做一次快照然后存储到硬盘中。该方式是Redis默认的持久化方式。 RDB可以通过在配置文件中配置时间或者改动键的个数来定义快照条件，编辑配置文件redis.conf，找到 save 900 1 #15分钟之内至少有一个建被更改则进行快照 save 300 10 #5分钟之内至少有10个建被更改则进行快照 save 60 10000 #1分钟之内至少有1000个建被更改则进行快照 他们之间是或的关系，RDB持久化到磁盘的文件默认路径是在当前目录，文件名为dump.rdb，你可以通过配置文件配置dir和dbfilename来指定文件目录和文件名称，RDB文件还可以进行压缩，你可以通过配置rdbcompression参数来进行压缩。 RDB快照过程： 1、Redis使用fork函数复制一份当前的父进程作为子进程 2、父进程继续处理用户的请求，子进程开始把内存中的数据持久化到磁盘上 3、当子进程把内存中的数据写入到临时文件完成之后，会把该临时文件替换掉旧的RDB文件。 RDB优点：RDB文件内容紧凑，文件小（比AOF文件小）非常适合于灾难恢复