数据持久化

8.Redis的持久化 两种策略的选择： RDB持久化方式能够在指定的时间间隔内对数据进行快照存储。AOF持久化方式记录每次对服务器的写操作，当服务器重启时会重新执行这些写命令来恢复原始的数据，AOF命令以redis协议追加保存每次写操作到文件末尾。 Redis能对AOF文件进行后台重写，使得AOF文件体积不会过大 只做缓存：如果希望数据在服务器运行的时候存在，也可以不使用任何持久化方式。 官网建议如果使用，两种同时使用： 在这种情况下，redis先载入AOF文件来恢复原始数据，因为通常AOF数据比RDB数据更完整。当RDB数据不正确时，服务器重启也只会加载AOF文件。RDB用于备份数据库，快速重启，以防万一。 性能建议 RDB（Redis DataBase） 定义：在指定的时间间隔内将内存中的数据集快照写入磁盘，Snapshot快照，它恢复时是将快照文件直接读到内存里。 Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。 Fork 作用是复制一个与当前进程一样的进程

一、RabbitMQ 1）生产者弄丢了数据 　　生产者将数据发送到rabbitmq的时候，可能因为网络问题导致数据就在半路给搞丢了。 1.可以选择用rabbitmq提供的事务功能，在生产者发送数据之前开启rabbitmq事务（channel.txSelect），然后发送消息，如果消息没有成功被rabbitmq接收到，那么生产者会收到异常报错，此时就可以回滚事务（channel.txRollback），然后重试发送消息；如果收到了消息，那么可以提交事务（channel.txCommit）。但是问题是，开始rabbitmq事务机制，基本上吞吐量会下来，因为太耗性能。 2.（推荐）可以开启confirm模式，在生产者那里设置开启confirm模式之后，你每次写的消息都会分配一个唯一的id，然后如果写入了rabbitmq中，rabbitmq会给你回传一个ack消息，告诉你说这个消息ok了。如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息接收失败，你可以重试。而且你可以结合这个机制自己在内存里维护每个消息id的状态，如果超过一定时间还没接收到这个消息的回调，那么你可以重发。 　　 　　事务机制和cnofirm机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是confirm机制是异步的，你发送个消息之后就可以发送下一个消息

本文以在 CentOS 7.2 中的实际例子来说明如何通过 MySQL 来存储相关的 MQTT 数据。 MySQL 属于传统的关系型数据库产品，其开放式的架构使得用户的选择性很强，而且随着技术的逐渐成熟，MySQL 支持的功能也越来越多，性能也在不断地提高，对平台的支持也在增多，此外，社区的开发与维护人数也很多。当下，MySQL 因为其功能稳定、性能卓越，且在遵守 GPL 协议的前提下，可以免费使用与修改，因此深受用户喜爱。 安装与验证 MySQL 服务器 读者可以参考 MySQL 官方文档 或使用 Docker 来下载安装 MySQL 服务器，本文章使用 MySQL 5.6 版本。 为方便管理操作，可下载使用官方免费图形化管理软件 MySQL Workbeanch 。 如果读者使用的是 MySQL 8.0 及以上版本，MySQL 需按照 EMQ X 无法连接 MySQL 8.0 教程特殊配置。 准备 初始化数据表 插件运行依赖以下几张数据表，数据表需要用户自行创建，表结构不可改动。 mqtt_client 存储设备在线状态 DROP TABLE IF EXISTS ` mqtt_client ` ; CREATE TABLE ` mqtt_client ` ( ` id ` int ( 11 ) unsigned NOT NULL AUTO_INCREMENT , `

Redis有两种持久化方式，第一种是快照（SNAPSHOTTING），第二种是AOF(append-only file) 快照方式 # 900秒内有1条数据更新就保存 save 900 1 # 300秒内有10条数据更新就保存 save 300 10 # 60秒内有10000条数据更新就保存 save 60 10000 #快照文件名称 dbfilename dump.rdb #保存路径 dir /var/lib/redis AOF方式 # 开启AOF备份方式，如果关闭，则改为no appendonly yes # 文件名称，路径和快照路径一样 appendfilename "appendonly.aof" # 有三种模式向磁盘写入数据 # 每次写入仅追加日志后 # appendfsync always # 每秒钟只同步一次 appendfsync everysec # 计算机决定什么时候写入 # appendfsync no # 随着时间的推移，AOF文件会越来越大，所以要压缩文件。 # 以下配置可以自动执行 BGREWRITEAOF命令 # 当AOF文件的体积大于64mb并且AOF文件的体积比上一次重写之后的体积大了至少1倍（100%）redis将执行 # BGREWRITEAOF命令 auto-aof-rewrite-percentage 100 auto-aof

一、数据持久化 默认情况下 Redis 的数据都是保存在内存中，为避免 Redis 进程意外退出而导致数据丢失的问题，Redis 提供了 RDB 和 AOF 两种方式来实现数据的持久化存储。 二、RDB 机制 RDB 机制是以指定的时间间隔将 Redis 中的数据生成快照并保存到硬盘中，它更适合于定时备份数据的应用场景。可以通过手动或者自动的方式来触发 RDB 机制： 2.1 手动触发 可以通过以下两种方式来手动触发 RDB 机制： save ：save 命令会阻塞当前 Redis 服务，直到 RDB 备份过程完成，在这个时间内，客户端的所有查询都会被阻塞； bgsave ：Redis 进程会 fork 出一个子进程，阻塞只会发生在 fork 阶段，之后持久化的操作则由子进程来完成。 2.2 自动触发 除了手动使用命令触发外，在某些场景下也会自动触发 Redis 的 RDB 机制： 在 redis.conf 中配置了 save m n ，表示如果在 m 秒内存在了 n 次修改操作时，则自动触发 bgsave ; 如果从节点执行全量复制操作，则主节点自动执行 bgsave ，并将生成的 RDB 文件发送给从节点； 执行 debug reload 命令重新加载 Redis 时，会触发 save 操作； 执行 shutdown 命令时候，如果没有启用 AOF 持久化则默认采用

https://segmentfault.com/a/1190000004135982 redis 主从复制 Redis主从复制的原理 当建立主从关系时，slave配置slaveof <master_host> <master_port> 。slave服务器会向主服务器发送一个sync命令。master接受并fork一个进程来执行BGSAVE命令。该命令生成一个RDB文件并且全量发送给slave服务器，slave服务器接收并载入RDB文件，同时，主服务器将缓冲区的命令以增量的方式发送给从服务器，最终使从服务器的数据状态和主服务器保持一致。 RDB的工作原理 当redis生成dump.rdb文件时，工作过程如下 redis主进程fork一个子进程 fork出来的子进程将内存的数据集dump到临时的RDB中 当子进程对临时的RDB文件写入完毕，redis用新的RDB文件代替旧的RDB文件 AOF的工作原理 AOF ：append only file。每当Redis执行一个改变数据集的命令时，这个命令都会被追加到AOF文件的末尾。当redis重新启动时，程序可以通过AOF文件恢复数据 持久化文件监控 Redis 监控最直接的方法当然就是使用系统提供的 info 命令来做了，只需要执行下面一条命令，就能获得 Redis 系统的状态报告。 redis-cli info RDB文件状态监控

Redis是我们常用的key-value数据库，其中可持久化的特性也是被各路开发者喜爱。接下来，我们来简单聊聊Redis的两种持久化机制RDB和AOF。 一、RDB 1、RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。RDB是Redis默认的持久化方式，会在对应的目录下生产一个dump.rdb文件，重启会通过加载dump.rdb文件恢复数据。 2、优点 1）只有一个文件dump.rdb，方便持久化； 2） 容灾性好，一个文件可以保存到安全的磁盘； 3） 性能最大化，fork子进程来完成写操作，让主进程继续处理命令，所以是IO最大化（使用单独子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能) ； 4）如果数据集偏大，RDB的启动效率会比AOF更高。 3、缺点 1）数据安全性低。（RDB是间隔一段时间进行持久化，如果持久化之间redis发生故障，会发生数据丢失。所以这种方式更适合数据要求不是特别严格的时候） 2）由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。 二、AOF 1、AOF持久化是以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录

使用JPA持久化对象的步骤 创建 persistence.xml, 在这个文件中配置持久化单元 需要指定跟哪个数据库进行交互; 需要指定 JPA 使用哪个持久化的框架以及配置该框架的基本属性 创建实体类, 使用 annotation 来描述实体类跟数据库表之间的映射关系. 使用 JPA API 完成数据增加、删除、修改和查询操作 创建 EntityManagerFactory (对应 Hibernate 中的 SessionFactory); 创建 EntityManager (对应 Hibernate 中的Session); JPA 规范要求在类路径的 META-INF 目录下放置persistence.xml，文件的名称是固定的 来源： https://www.cnblogs.com/fuyiming/p/5797066.html

概念： 控制算子有三种，cache,persist,checkpoint ，以上算子都可以将RDD持久化，持久化的单位是partition。cache和persist都是懒执行的。必须有一个action类算子触发执行。checkpoint算子不仅能将RDD持久化到磁盘，还能切断RDD之间的依赖关系。 cache 默认将RDD的数据持久化到内存中。cache是懒执行。 注意 ：cache () = persist()=persist(StorageLevel.Memory_Only) 测试代码： SparkConf conf = new SparkConf ( ) ; conf . setMaster ( "local" ) . setAppName ( "CacheTest" ) ; JavaSparkContext jsc = new JavaSparkContext ( conf ) ; JavaRDD < String > lines = jsc . textFile ( "./NASA_access_log_Aug95" ) ; lines = lines . cache ( ) ; long startTime = System . currentTimeMillis ( ) ; long count = lines . count ( ) ; long endTime

传统DB的缺点 像Mysql、和Oracle 这种关系型数据库，虽然有着数据稳定和服务稳定、数据一致性的特点，但也存在一个致命的缺陷: 高并发下DB不稳定 在高并发的情况下，DB的不稳定性，在大量用户访问时DB出奇的慢，因为对磁盘操作需要使用IO流，一个字节一个字节存取操作。要将所有数据读取到内存中后才可以操作。所以在高并发下DB的 高可用 便成了问题。这时NoSQL便应运而生。 什么是NOSQl NoSQL是对不同于传统的关系数据库的数据库管理系统的统称。即非关系型数据库 NOSQL：因为是内存操作数据，非常快,解决了三高问题（高并发、高海量、高可用） 非关系型数据库与非关系型数据库的区别 关系型数据库 非关系型数据库 以文件方式保存 存储在内存中，服务器关闭数据可能会丢失 数据可以永久保存 不能持久化保存，可能导致数据丢失 查询速度慢 存取速度快 常见的NOSQL数据库 Redis 简单翻译下 Redis是一个开源(BSD许可)的内存数据结构存储，用作数据库、缓存和消息代理。它支持诸如字符串、散列、列表、集、带范围查询的排序集、位图、hyperloglogs、带半径查询和流的地理空间索引等数据结构。Redis具有内置的复制、Lua脚本、LRU清除、事务和不同级别的磁盘持久性，并通过Redis Sentinel和带有Redis集群的自动分区提供高可用性