数据持久化

　　1. Redis 有两种持久化方案，RDB （Redis DataBase）和 AOF （Append Only File）。 RDB： Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。 AOF：Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个 写操作 ，并 追加 到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。 　　2. 两者的优缺点。 RDB的优点：（1）适合大规模的数据恢复； （2）如果业务对数据一致性和完整性要求不高，是很好的选择 RDB的缺点：（1）数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了；（2）备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件； AOF的优点：（1）数据一致性和完整性都很好。 AOF的缺点：（1）AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。 　　3. 配置文件（redis.conf） RDB：　　save <seconds> <changes> # 　　　　　　　　save "" save 900 1 　　　　　　　

一、沙盒机制 沙盒就是一个文件，沙盒的目录结构： "应用程序包" Documents Library Caches Preferences tmp 文件夹解释： "应用程序包": 这里面存放的是应用程序的源文件，包括资源文件和可执行文件。 NSString *path = [[NSBundle mainBundle] bundlePath]; NSLog(@"%@", path); Documents: 最常用的目录，iTunes同步该应用时会同步此文件夹中的内容，适合存储重要数据。 NSString *path = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory, NSUserDomainMask, YES).firstObject; NSLog(@"%@", path); Library/Caches: iTunes不会同步此文件夹，适合存储体积大，不需要备份的非重要数据。 NSString *path = NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES).firstObject; NSLog(@"%@", path); Library/Preferences: iTunes同步该应用时会同步此文件夹中的内容

目录：1）Ceph介绍 2）部署Ceph集群 采用版本【2020最新nautilus (stable)14.2.7】 为什么使用Ceph？ ceph其实早在2004年的时候写的第一行代码，它是到2012年才有的第一个开发版本，到2014年的时候ceph才慢慢有公司在生产上应用了，那时候一般有的版本也不是很稳定，也是进行一些二次的研发，包装成一些自己的东西，不过现在ceph的版本已经很稳定了，已经适合在生产用了，目前用的比较多的，社区影响比较好的是这个luminous版本，这个版本也是比较稳定，也是比较流行，目前也是用的比较多。 另外就是ceph和其他存储有些不一样的地方，它可扩展，有很好的性能，有稳定存储的计算模块，在没用ceph之前用的一般都是一些传统的存储或者就是商业的存储，像商业的成本一般比较高，需要一些设备或者存储到云端，另外就是拿服务器做挂载共享，这种一个是不利于横向扩展，它很难保证数据的稳定性，数据的访问速率，因为用挂载模式的话，它挂载的模式访问是比较差的，所以基于这种原因来采用ceph，目前像腾讯、乐视、新浪、国外的公司雅虎也都是用的ceph，像国内用的比较成功的x-sky这个用的也比较多，所以这个ceph已经很稳定了，目前市面的ceph人员也比较缺少。 GlusterFS和ceph的区别 分布式存储的话无疑就是横向扩展，任何一个节点挂了的话，可以不整体影响一个运行

RDB快照 在默认情况下，Redis将内存数据库快照保存到dump.rdb的二进制文件中。 可以对Redis进行设置，让它在“N秒内数据集至少有N个改动”， 这一条件被满足时，自动保存一次数据集。比如说：让Redis满足“60秒内至少有1000个键被改动”这一个条件时，自动保存一次数据集。 save 60 1000 除了在配置文件中使用save关键字设置RDB快照，还可以在命令行中手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件。 每次执行命令都会将所有redis内存快照保存到一个rdb文件里，并覆盖原有的rdb快照文件。 save是同步命令，bgsave是异步命令，bgsave会从redis主进程fork出一个子进程专门用来生成rdb二进制文件。 AOF（append only file） 快照功能并不是非常durable，如果redis因为某些原因而造成故障停机，那么服务器将丢失最近写入且未保存到快照中的那些数据。从1.1版本，redis增加了一种完全durable的方式：AOF持久化，将修改的每一条指令记录进appendonly.aof中。修改配置文件来打开aof功能： appendonly yes 打开aof功能，每当redis执行一个改变数据集的命令时，这个命令就会追加到aof文件的末尾。这样的话

作者：陈肃 整理：周奇，Apache Flink 社区志愿者 本文根据陈肃老师在 Apache Kafka x Flink Meetup 深圳站的分享整理而成，文章首先将从数据融合角度，谈一下 DataPipeline 对批流一体架构的看法，以及如何设计和使用一个基础框架。其次，数据的一致性是进行数据融合时最基础的问题。如果数据无法实现一致，即使同步再快，支持的功能再丰富，都没有意义。 另外，DataPipeline 目前使用的基础框架为 Kafka Connect。为实现一致性的语义保证，我们做了一些额外工作，希望对大家有一定的参考意义。 最后，会提一些我们在应用 Kafka Connect 框架时，遇到的一些现实的工程问题，以及应对方法。尽管大家的场景、环境和数据量级不同，但也有可能会遇到这些问题。希望对大家的工作有所帮助。 一、批流一体架构 批和流是数据融合的两种应用形态 下图来自 Flink 官网。传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的 ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。 另一种是 Data Pipeline 模式。与批模式相比相比， 其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于数据库的日志、消息队列的消息。进而通过一个实时计算引擎

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

一、ORM是什么？ 对象关系映射（Object Relational Mapping，简称ORM）模式是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。简单的说，ORM是通过使用描述对象和数据库之间映射的元数据，将程序中的对象自动持久化到关系数据库中。那么，到底如何实现持久化呢？一种简单的方案是采用硬编码方式，为每一种可能的数据库访问操作提供单独的方法。 这种方案存在以下不足： 1.持久化层缺乏弹性。一旦出现业务需求的变更，就必须修改持久化层的接口 2.持久化层同时与域模型与关系数据库模型绑定，不管域模型还是关系数据库模型发生变化，毒药修改持久化曾的相关程序代码，增加了软件的维护难度。 ORM提供了实现持久化层的另一种模式，它采用映射元数据来描述对象关系的映射，使得ORM中间件能在任何一个应用的业务逻辑层和数据库层之间充当桥梁。Java典型的ORM中间件有:Hibernate,ibatis,speedframework。 ORM的方法论基于三个核心原则： 　　· 简单：以最基本的形式建模数据。 　　· 传达性：数据库结构被任何人都能理解的语言文档化。 　　· 精确性：基于数据模型创建正确标准化了的结构。 二、ORM的概念 让我们从O/R开始。字母O起源于"对象"(Object),而R则来自于"关系"(Relational)。几乎所有的程序里面，都存在对象和关系数据库

持久化 持久化是将程序数据在持久状态和瞬时状态间转换的机制。 即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、XML数据文件中等等。 JDBC就是一种持久化机制。文件IO也是一种持久化机制。 在生活中 : 将鲜肉冷藏，吃的时候再解冻的方法也是。将水果做成罐头的方法也是。 为什么需要持久化服务呢？那是由于内存本身的缺陷引起的 内存断电后数据会丢失，但有一些对象是无论如何都不能丢失的，比如银行账号等，遗憾的是，人们还无法保证内存永不掉电。 内存过于昂贵，与硬盘、光盘等外存相比，内存的价格要高2~3个数量级，而且维持成本也高，至少需要一直供电吧。所以即使对象不需要永久保存，也会因为内存的容量限制不能一直呆在内存中，需要持久化来缓存到外存。 持久层 什么是持久层？ 完成持久化工作的代码块 . ----> dao层 【DAO (Data Access Object) 数据访问对象】 大多数情况下特别是企业级应用，数据持久化往往也就意味着将内存中的数据保存到磁盘上加以固化，而持久化的实现过程则大多通过各种 关系数据库 来完成。 不过这里有一个字需要特别强调，也就是所谓的“层”。对于应用系统而言，数据持久功能大多是必不可少的组成部分。也就是说，我们的系统中，已经天然的具备了“持久层”概念？也许是

RDB存储 RDB方式的持久化是通过快照完成的，当符合一定条件时Redis会自动将内存中的所有数据生成一份副本并存储在硬盘上。 Redis会在一下集中情况下对数据进行快照： 根据配置规则进行快照； 用户执行SAVE或BGSAVE命令； 执行FLUSHALL命令； 执行复制时； 根据配置规则进行快照 # 时间策略 save 900 1 save 300 10 save 60 10000 # 文件名称 dbfilename dump.rdb # 文件保存路径 dir /home/work/app/redis/data/ # 如果持久化出错，主进程是否停止写入 stop-writes-on-bgsave-error yes # 是否压缩 rdbcompression yes # 导入时是否检查 rdbchecksum yes 例如Redis的配置文件中： # 时间策略 save 900 1 save 300 10 save 60 10000 如果符合其中的任意一条，则会触发一次快照。 当然如果你想要禁用RDB配置，也是非常容易的，只需要在save的最后一行写上： save "" SAVE或BGSAVE 当执行SAVE时，Redis会同步进行快照操作，快照执行过程中会阻塞所有来自客户端的请求。 当执行BGSAVE时，可以在后台异步进行快照操作，快照的同时服务器还可以继续响应来自客户端的请求

redis的概念： Redis是一款开源的、高性能的键-值存储（key-value store）。它常被称作是一款数据结构服务器（data structure server）。 reids的数据类型： 字符串（strings）类型 列表（lists） 集合（sets） 有序集合（sorted sets） 哈希（hashes） redis的特点 Redis采用了内存中（in-memory）数据集（dataset）的方式 Redis支持数据的持久化 Redis同样支持主从复制 具有非常快速的非阻塞首次同步（ non-blocking first synchronization）、网络断开自动重连 简单的事物支持、发布订阅 （ pub/sub）、管道（pipeline）和虚拟内存（vm） Redis具有丰富的客户端，支持现阶段流行的大多数编程语言 redis持久化介绍 　　1. 由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了 　　2. redis提供两种方式进行持久化： 　　　　　第一种：RDB （将Redis中数据定时dump到硬盘） 　　　　　第二种：AOF （将Reids的操作日志以追加的方式写入文件） RDB持久化原理 RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘 实际操作过程是fork一个子进程，先将数据集写入临时文件