数据持久化

RDB持久化概述 Redis是内存数据库,将数据存储到内存中。不想办法持久化到磁盘,则机器断电数据将无法找回。RDB持久化提供了一种Redis数据库持久化方案。 RDB持久化功能将数据库中保存的键值对生成为一个二进制的RDB文件，也可通过RDB文件还原到数据库状态。RDB文件保存在磁盘中，解决了Redis数据丢失的问题。 RDB文件的创建 RDB文件的创建可以通过SAVE或BGSAVE命令。SAVE命令阻塞当前进程，生成RDB文件；BGSAVE命令则是开启子进程创建RDB文件，父进程继续处理其他命令。 RDB文件的创建代码在rdb.c / int rdbSave(char *filename) SAVE和BGSAVE 都会调用rdbSave函数生成RDB文件， 只是BGSAVE先fork出子进程，通过子进程调用。如下图，只截取了部分 命令执行期间注意事项: 1.在BGSAVE执行期间,此时发送SAVE命令会被拒绝执行 2.在BGSAVE执行期间,此时发送BGSAVE命令会被拒绝执行 3.在BGREWIRTEAOF执行期间，发送BGSAVE命令会拒绝执行 4.在BGSAVE执行期间,发送BGREWRITEAOF命令会拒绝执行 以上四点可参考代码段 ，其中rdb_child_pid为-1时，表示此时并未进行BGSAVE命令,在函数rdbSaveBackground调用中，rdb

初探AOF文件 Redis还提供了AOF持久化功能，与RDB持久化不同之处在于，RDB文件保存的数据库的键值对。AOF文件保存的是服务器执行的写入命令。 AOF持久化开关可以在配置文件中appendonly设置，如下图所示。 加载配置会将appendonly赋值到redisServer中的aof_state变量。 举个AOF文件栗子： 向服务器的默认数据库中存入了三个键，使用BGREWRITEAOF命令手动生成了一份AOF文件，查看这个文件内容，可以看到保存的内容如下 *2$6SELECT$10　　　　　　　　　　　　　　　　　　　　// 此条记录由服务器自动添加，即选择当前数据库。 *5$4SADD$6fruits$5peach$6banana$5apple　　　　　　　　 *5$5RPUSH$7numbers$3128$3256$3512 *3$3SET$7message$5hello AOF持久化的实现 1.命令追加：服务器执行完一个写命令时，会将执行的命令追加到aof_buf缓冲区的末尾.aof_buf 是redisServer中的成员，如下图所示 2.文件写入：Redis的服务器进程就是一个事件循环(loop),在这个循环中处理文件事件(比如客户端的读写)，时间事件（执行serverCron函数） 在serverCron函数中会调用aof.c /

Redis的数据全部在内存里，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证Redis的数据不会因为故障而丢失，这种机制就是Redis的持久化机制。 Redis的持久化机制有两种方式， 第一种是快照，第二种是AOF日志。快照是一次全量备份，AOF日志是连续的增量备份 。快照是内存数据的二进制序列化形式，在存储上非常紧凑，而 AOF 日志记录的是内存数据修改的指令记录文本。AOF日志在长期的运行中会变得无比庞大，数据库重启会加载AOF日志进行指令重放，这个时间会无比漫长，所以需要定期进行AOF重写，进行瘦身操作。 快照原理 RDB持久化是把当前进程数据生成快照保存到磁盘的过程，触发RDB持久化过程分为手动触发和自动触发。 触发机制： save命令：阻塞当前redis服务器，直RDB过程完成为止。（如果内存比较大会造成redis长时间阻塞，这样显然不是我们想要的。线上禁止使用） bgsave命令：redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般很短（和实例数据大小有关系） 除了执行命令手动触发之外，存在自动触发RDB的持久化机制。 使用save相关配置，如“save m n” 表示m秒内数据集存在n次修改时（可以配置多组条件，其中一个达标就触发），自动触发bgsave 如果从节点执行全量复制操作

Redis详解（一）——RDB 前言 由于 Redis 是一个内存数据库，所谓内存数据库，就是将数据库中的内容保存在内存中，这与传统的MySQL，Oracle等关系型数据库直接将内容保存到硬盘中相比，内存数据库的读写效率比传统数据库要快的多（内存的读写效率远远大于硬盘的读写效率）。但是保存在内存中也随之带来了一个缺点，一旦断电或者宕机，那么内存数据库中的数据将会全部丢失。 　　为了解决这个缺点，Redis提供了将内存数据持久化到硬盘，以及用持久化文件来恢复数据库数据的功能。Redis 支持两种形式的持久化，一种是RDB快照（snapshotting），另外一种是AOF（append-only-file）。本篇博客先对 RDB 快照进行介绍。 1、RDB 简介 　　RDB是Redis用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里。 2、触发方式 　　RDB 有两种触发方式，分别是自动触发和手动触发。 ①、自动触发 　　在 redis.conf 配置文件中 　　 ①、save： 这里是用来配置触发 Redis的 RDB 持久化条件，也就是什么时候将内存中的数据保存到硬盘。比如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave（这个命令下面会介绍

最近一直在思考一个问题：有没有这样一种可能，就是一个领域模型的状态不依赖于外部，它只负责接收外部的事件，然后根据这些事件做出响应；响应分两种： 根据模型当前的内存状态进行业务逻辑处理，然后产生事件，注意：这个过程不会改变模型当前的内存状态； 根据事件改变自己的状态； 另外，也是最重要的，领域模型不用关心自己所产生的事件到底怎么样了，比如不关心有没有持久化，不关心是否和别的事件有并发冲突。它只管根据自己当前的内存状态做上面这两点的响应； 如果这样的设想有可能，那领域模型就是真正的中央业务逻辑处理器了，和CPU很类似了。这样它才能真正快起来。 简单的说就是：事件->模型->事件 模型只管响应事件，然后响应处理，然后产生新的事件 领域模型就是一黑盒，它只能帮你处理业务逻辑，其他的什么处理结果它一概不关心；当然，领域模型肯定有它自己的状态，但这个状态是驻留在内存的，和领域模型是一体的。 我为什么会有这个想法是因为，我在想，为什么要让领域模型的处理逻辑依赖于它的处理结果是否被正确顺利持久化了？感觉这很荒唐。 既然领域模型有自己的内存状态空间，他的所有逻辑也应该只依赖于这个状态空间，不再依赖于其他任何外部的东西。 当然，以前我们设计的IRepository，实际背后都是直接从数据库取。这样的话，领域模型的状态空间就是数据库了。但是这样其实很不好，为什么不用内存作为领域模型的状态空间呢？

通过前面的学习，了解了redis的各个数据类型后，知晓了为何使用redis 它的优势主要是数据存储和查询比关系型数据库快， 这是因为redis的数据都是存储在内存中的原因，并且具有较多的数据类型， 使得在访问查询高频数据时我们可以放置在redis进行缓存，进而减小mysql的访问压力， 而正因为redis存储在内存中的原因， 导致在redis服务关闭前，如果未将内存中的数据存在磁盘上会导致数据的丢失 redis也在这方面进行了处理，尽最大可能的减少数据丢失的概率 这章也主要学习的就是redis的数据持久化方面的处理操作 主要分两类处理:RDB 和 AOF 前者将根据指定的规则"定时"将内存中的数据存储在硬盘上 后者则是在每次执行命令后将命令本身记录下来 首先学习第一种 RDB RDB方式的持久化是通过快照完成的， 当符合一定条件时Redis会自动将内存中的所有数据生成一份副本并存储在硬盘上 ，这个过程即为"快照" 那么什么为其符合的条件呢： · 根据配置规则进行自动快照 · 用户执行SAVE 或 BGSAVE命令 · 执行FLUSHALL 命令 · 执行复制时 1》 根据配置规则进行自动快照 首先找到配置文件 该配置是用户自定义其快照条件，规则：时间窗口M 和 改动键的个数N 即当在M的时间段内更改键的个数大于N，即为符合自动快照的条件，如： save 900 1 save 300

展开 开发完成Spark作业之后，我们在运行Spark作业的时候需要为其配置一些资源参数，比如num-executors，executor-memory等，这些参数基本上都是可以在spark-submit命令中作为参数设置，但是如何设置合适的参数值是需要我们权衡考虑的（集群资源，调优经验，任务大小等）。参数设置的不合适往往会导致集群资源得不到有效的利用，设置的太大可能会导致资源不够而引发异常，太小的话会使得闲置的资源得不到有效利用，作业运行的极为缓慢。所以，如何合理有效的分配Spark作业资源是需要Spark学习者重点考虑的。下面将一些理论知识结合自己的实践进行讲解。 集群资源情况 我们在为自己的Spark作业设置资源参数的时候，需要对公司的集群资源使用情况有一个较为清晰的了解，主要了解以下几个方面： (1)集群总体情况 公司集群的整体配置信息，比如总内存，内存使用情况，节点数等，对集群的资源有一个整体的认识。 可以从Yarn页面来了解集群整体情况，如红线圈出的一些重要信息： (2)资源队列配置 一般使用资源管理器，比如Yarn，都会设置一些资源队列，比如Hadoop,Spark，default队列等。这里以讯飞公司情况为例讲解，讯飞使用Yarn资源管理器，这里采用Capacity Scheduler任务调度模式，设置了两个资源队列：default和Spark

Append-only File（ AOF ）Redis每次接收到一条改变数据的命令时，它将把该命令写到一个AOF文件中（只记录写操作，不记录读操作），当Redis重启时，它通过执行AOF文件中所有的命令来恢复数据。 AOF是在RDB之后出现的一种技术，这种方式的持久化让redis的数据不会丢失； 当使用Redis存储非临时数据时，一般需要开启AOF持久化来降低Redis故障导致的数据丢失，AOF可以将Redis执行的每一条写命令追加到硬盘文件中，这一过程会降低Redis的性能，但大部分情况下这个影响是能够接受的，另外使用较快的硬盘（固态硬盘）可以提高AOF的性能； AOF方式的数据持久化，仅需在redis.conf文件中配置即可，搜索 APPEND ONLY MODE ； 配置文件 appendonly no 默认是no，改成yes即开启aof持久化； 2.AOF的相关配置选项 appendonly 默认是no，改成yes即开启了aof持久化； appendfilename 指定AOF文件名，默认文件名为appendonly.aof；（该文件要Redis自己启动创建，测试发现我们自己创建该文件，无法向文件写入持久化命令） appendfsync 配置向aof文件写命令数据的策略： no：不主动进行同步操作，而是完全交由操作系统来做（即每30秒一次），比较快但不是很安全;

Cookie&Session会话技术 一.会话技术 1) 从打开一个浏览器访问某个站点，到关闭这个浏览器的整个过程，成为一次会话。会话技术就是记录这次会话中客户端的状态与数据的。 2)会话技术分为Cookie和Session： Cookie：数据存储在客户端本地，减少服务器端的存储的压力，安全性不好，客户端可以清除cookie; Session：将数据存储到服务器端，安全性相对好，增加服务器的压力; 二、Cookie技术 1．服务器端向客户端发送一个Cookie 1）创建Cookie： Cookie cookie = new Cookie(String cookieName,String cookieValue); 注意：Cookie中不能存储中文 。 2）设置Cookie在客户端的持久化时间： cookie.setMaxAge(int seconds); ---时间秒 注意：如果不设置持久化时间，cookie会存储在浏览器的内存中，浏览器关闭 cookie信息销毁（会话级别的cookie），如果设置持久化时间，cookie信息会被持久化到浏览器的磁盘文件里 3）设置Cookie的携带路径： cookie.setPath(String path); 注意：如果不设置携带路径，那么该cookie信息会在访问产生该cookie的 web资源所在的路径都携带cookie信息 4

1 Redis 持久化方案 Redis 是一个 内存 数据库，为了保证数据的持久性，它提供了两种持久化方案 : l RDB 方式（默认） l AOF 方式 1.1 RDB 方式 1.1.1 介绍 l RDB 是 Redis 默认 采用的持久化方式。 l RDB 方式是通过 快照 （ snapshotting ）完成的，当 符合一定条件 时 Redis 会自动将内存中的数据进行快照并持久化到硬盘。 l Redis 会在 指定的情况 下触发快照 1. 符合自定义配置的快照规则 2. 执行 save 或者 bgsave 命令 3. 执行 flushall 命令 4. 执行主从复制操作 l 在 redis.conf 中设置自定义快照规则 1. RDB 持久化条件 格式： save <seconds> <changes> 示例： save 900 1 ： 表示 15 分钟（ 900 秒钟）内 至少 1 个键被更改则进行快照。 save 300 10 ： 表示 5 分钟（ 300 秒）内至少 10 个键被更改则进行快照。 save 60 10000 ：表示 1 分钟内至少 10000 个键被更改则进行快照。 可以配置多个条件（每行配置一个条件），每个条件之间是 “ 或 ” 的关系。 save 900 1 save 300 10 save 60 10000 2. 配置 dir 指定 rdb