‘壹’ 如何从持久化存储中读取数据
对于数据的持久化存储，ios中一般提供了4种不同的机制。
1.属性列表
2.对象归档
3.数据库存储（SQLite3）
4.苹果公司提供的持久性工具Core Data。
其实储存的形式无非就这么几种，而我们还必须要关心的是，这些文件会被放置在那个文件下，然后如何读取。
也就是说：IOS上数据存储，我们要了解的两点，数据存储格式（也就是存储机制），数据存储位置。
1》文件如何存储（如上面4点）
2》文件存储在哪里。
对于数据的操作，其实我们关心的是操作的速率。
就好比在Adnroid中偏好存储，数据库存储，io存储一样。
‘贰’ Linux里面什么是数据持久化
数据持久化顾名思义就是把程序中的数据以某种形式保存到某存贮介质中，以达到持久化的目的。当程序运行时，一些数据是临时保存在内存中，一旦退出系统，这些数据就丢失了。那么，使用某种手段将数据保存在硬盘上或者数据库中，这样即使退出系统后又重新启动系统，那么这些数据仍然可以重新找回来。
例如管理员向一个用户管理系统中添加了一个用户的资料，那么这个系统需要将新添加的资料保存到数据库中，否则系统退出或者电脑重启后该用户资料就会丢失。将数据从内存保存到数据库中，这便是数据的持久化。当然，数据库只是持久化方式中的一种，也可以保存在其他的永久存贮介质中。
图为数据持久化的过程示意图。
持久化（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、XML数据文件中等等。
持久化是将程序数据在持久状态和瞬时状态间转换的机制。
DBC就是一种持久化机制。文件IO也是一种持久化机制。
日常持久化的方法
在一定周期内保持不变就是持久化,持久化是针对时间来说的。数据库中的数据就是持久化了的数据,只要你不去删除或修改。比如在浏览器中一次Session会话中Session对象变量也是不变的,是Session容器中持久化。对象持久化的方式有很多种,根据周期不同有,page,Session,Application。对象序列化机制对于需要将对象的状态保存到文件中，而后能够通过读入对象状态来重新构造对象，恢复程序状态. 对象序列化的过程是对象持久化的方法之一,把对象保存到文件中。
简单的理解持久化可以在二个层面：应用层和系统层、
应用层
如果关闭(shutdown)你的应用然后重新启动则先前的数据依然存在。
系统层
如果关闭(shutdown)你的系统（电脑）然后重新启动则先前的数据依然存在。
持久化是一种对象服务实现至少3个接口
，就是把内存中的对象保存到外存中，让以后能够取回。需要实现至少3个接口：
void Save(object o) 把一个对象保存到外存中
Object Load(object oid) 通过对象标识从外存中取回对象
boolExists(object oid) 检查外存中是否存在某个对象.
类似概念序列化
我们先跳开一下，看看另一个类似的有用概念：序列化Serialize也是一种对象服务，就是把内存中的对象序列化成流、或者把流反序列化成对象。需要实现2个接口：
void Serialize(Stream stream,object o) 把对象序列化到流中
object Deserialize(Stream stream) 把流反序列化成对象
序列化和持久化很相似，有些人甚至混为一谈，其实还是有区别的，序列化是为了解决对象的传输问题，传输可以在线程之间、进程之间、内存外存之间、主机之间进行。我之所以在这里提到序列化，是因为我们可以利用序列化来辅助持久化，可以说凡是可以持久化的对象都可以序列化，因为序列化相对容易一些（也不是很容易），所以主流的软件基础设施，比如.net和java，已经把序列化的框架完成了。
持久化方案可以分为关系数据库方案、文件方案、对象数据库方案、xml数据库方案
现今主流的持久化方案是关系数据库方案，
关系数据库方案不仅解决了并发的问题，更重要的是，关系数据库还提供了持久化服务之外的价值：统计分析功能。刚才我说到，凡是可以序列化的对象都可以持久化，极端的说，我们可以只建立一个表Object(OID,Bytes)，但基本上没有人这么做，因为一旦这样，我们就失去了关系数据库额外的统计分析功能。关系数据库和面向对象之间有一条鸿沟，因为二者模式不匹配，所以就存在一个OR映射问题。
Redis支持两种数据持久化方式：rdb方式和aof方式。前者会根据配置的规则定时将内存中的数据持久化到硬盘上，后者则是在每次执行写命令之后将命令记录下来。两种持久化方式可以单独使用，但是通常会将两者结合使用。
1、RDB方式
RDB方式的持久化是通过快照的方式完成的。当符合某种规则时，会将内存中的数据全量生成一份副本存储到硬盘上，这个过程称作”快照”，redis默认开启该持久化功能，具体配置如下：
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename mp.rdb
#文件名称
dir ./
#rdb文件存放路径
配置后系统会自动进行快照，save 60 10000表示60秒内有10000次写入，那么就会调用bgsave
除了系统自动进行快照外，我们也可以手动执行SAVE或BGSAVE命令主动进行快照操作：
执行SAVE或BGSAVE命令
执行FLUSHALL命令
2、AOF方式
在使用Redis存储非临时数据时，一般都需要打开AOF持久化来降低进程终止导致的数据丢失，AOF可以将Redis执行的每一条写命令追加到硬盘文件中，这一过程会降低Redis的性能。
默认情况下，Redis没有开启AOF（append only file）持久化功能，可以通过在配置文件中作如下配置启用：
appendonly no #是否开启aof，开启时将no改为yes
appendfilename "appendonly.aof" 持久化文件名称
auto-aof-rewrite-percentage 100
#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size 64mb
#当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
appendfsync :everysec (推荐配置)
#持久化策略
always (同步持久化，每次发生数据变更会被立即记录到磁盘，性能差但数据完整性比较好)
everysec (异步操作，每秒记录，如果一秒钟内宕机，有数据丢失)
no （将缓存回写的策略交给系统，linux 默认是30秒将缓冲区的数据回写硬盘的）
一般来说可以考虑同时使用两种持久化方案.
‘叁’ Redis持久化
Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。理解掌握持久化机制对于Redis运维非常重要。本章内容如下：
·首先介绍RDB、AOF的配置和运行流程，以及控制持久化的相关命令，如bgsave和bgrewriteaof。
·其次对常见持久化问题进行分析定位和优化。
·最后结合Redis常见 的单机多实例部署场景进行优化。
5.1RDB
RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。
5.1.1触发机制
手动触发分别对应save和bgsave命令：
·save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。运行save命令对应
的Redis日志如下：
* DB saved on disk
·bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。运行bgsave命令对应的Redis日志如下：
* Background saving started by pid 3151
* DB saved on disk
* RDB: 0 MB of memory used by -on-write
* Background saving terminated with success
显然bgsave命令是针对save阻塞问题做的优化。因此Redis内部所有的涉及RDB的操作都采用bgsave的方式，而save命令已经废弃。
除了执行命令手动触发之外，Redis内部还存在自动触发RDB的持久化机制，例如以下场景：
1）使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。
2）如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点，更多细节见6.3节介绍的复制原理。
3）执行debug reload命令重新加载Redis时，也会自动触发save操作。
4）默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave。
5.1.2流程说明
bgsave是主流的触发RDB持久化方式，下面根据图5-1了解它的运作流程。
1）执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。
2）父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒。
3）父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。
4）子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项。
5）进程发送信号给父进程表示完成，父进程更新统计信息，具体见info Persistence下的rdb_*相关选项。
5.1.3RDB文件的处理
保存：RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定。可以通过执行config set dir{newDir}和config setdbfilename{newFileName}运行期动态执行，当下次运行时RDB文件会保存到新目录。
运维提示
当遇到坏盘或磁盘写满等情况时，可以通过config set dir{newDir}在线修改文件路径到可用的磁盘路径，之后执行bgsave进行磁盘切换，同样适用于AOF持久化文件。
压缩：Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可以通过参数config set rdbcompression{yes|no}动态修改。
运维提示
虽然压缩RDB会消耗CPU，但可大幅降低文件的体积，方便保存到硬盘或通过网络发送给从节点，因此线上建议开启。
校验：如果Redis加载损坏的RDB文件时拒绝启动，并打印如下日志：
# Short read or OOM loading DB. Unrecoverable error, aborting now.
这时可以使用Redis提供的redis-check-mp工具检测RDB文件并获取对应的错误报告。
5.1.4RDB的优缺点
RDB的优点：
·RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。
·Redis加载RDB恢复数据远远快于AOF的方式。
RDB的缺点：
·RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
·RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。
5.2AOF
AOF（append only file）持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。理解掌握好AOF持久化机制对我们兼顾数据安全性和性能非常有帮助。
5.2.1使用AOF
开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。保存路径同RDB持久化方式一致，通过dir配置指定。AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load），如图5-2所示。
1）所有的写入命令会追加到aof_buf（缓冲区）中。
2）AOF缓冲区根据对应的策略向硬盘做同步操作。
3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4）当Redis服务器重启时，可以加载AOF文件进行数据恢复。了解AOF工作流程之后，下面针对每个步骤做详细介绍。
5.2.2命令写入
AOF命令写入的内容直接是文本协议格式。例如set hello world这条命令，在AOF缓冲区会追加如下文本：*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n
Redis协议格式具体说明见4.1客户端协议小节，这里不再赘述，下面介
绍关于AOF的两个疑惑：
1）AOF为什么直接采用文本协议格式？可能的理由如下：
·文本协议具有很好的兼容性。
·开启AOF后，所有写入命令都包含追加操作，直接采用协议格式，避免了二次处理开销。
·文本协议具有可读性，方便直接修改和处理。
2）AOF为什么把命令追加到aof_buf中？Redis使用单线程响应命令，如果每次写AOF文件命令都直接追加到硬盘，那么性能完全取决于当前硬盘负载。先写入缓冲区aof_buf中，还有另一个好处Redis可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡。
5.2.3文件同步
Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制，不同值的含义如表5-1所示。
表5-1AOF缓冲区同步文件策略
系统调用write和fsync说明：
·write操作会触发延迟写（delayed write）机制。Linux在内核提供页缓冲区用来提高硬盘IO性能。write操作在写入系统缓冲区后直接返回。同步硬盘操作依赖于系统调度机制，例如：缓冲区页空间写满或达到特定时间周期。同步文件之前，如果此时系统故障宕机，缓冲区内数据将丢失。
·fsync针对单个文件操作（比如AOF文件），做强制硬盘同步，fsync将阻塞直到写入硬盘完成后返回，保证了数据持久化。除了write、fsync，Linux还提供了sync、fdatasync操作，具体API说明参
见：http://linux.die.net/man/2/write，http://linux.die.net/man/2/fsync，http://linux.die.net/man/2/sync
·配置为always时，每次写入都要同步AOF文件，在一般的SATA硬盘上，Redis只能支持大约几百TPS写入，显然跟Redis高性能特性背道而驰，不建议配置。
·配置为no，由于操作系统每次同步AOF文件的周期不可控，而且会加大每次同步硬盘的数据量，虽然提升了性能，但数据安全性无法保证。
·配置为everysec，是建议的同步策略，也是默认配置，做到兼顾性能和数据安全性。理论上只有在系统突然宕机的情况下丢失1秒的数据。（严格来说最多丢失1秒数据是不准确的，5.3节会做具体介绍到。）
5.2.4重写机制
随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。
重写后的AOF文件为什么可以变小？有如下原因：
1）进程内已经超时的数据不再写入文件。
2）旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set
a111、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
3）多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。
AOF重写降低了文件占用空间，除此之外，另一个目的是：更小的AOF文件可以更快地被Redis加载。AOF重写过程可以手动触发和自动触发：
·手动触发：直接调用bgrewriteaof命令。
·自动触发：根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
·auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB。
·auto-aof-rewrite-percentage：代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。自动触发时机=aof_current_size>auto-aof-rewrite-min-size&&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewrite-percentage其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看。当触发AOF重写时，内部做了哪些事呢？下面结合图5-3介绍它的运行流程。
图5-3AOF重写运作流程
流程说明：
1）执行AOF重写请求。
如果当前进程正在执行AOF重写，请求不执行并返回如下响应：
ERR Background append only file rewriting already in progress
如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成之后再执行，返回如下响应：
Background append only file rewriting scheled
2）父进程执行fork创建子进程，开销等同于bgsave过程。
3.1）主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。
3.2）由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
4）子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。
5.1）新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见info persistence下的aof_*相关统计。
5.2）父进程把AOF重写缓冲区的数据写入到新的AOF文件。
5.3）使用新AOF文件替换老文件，完成AOF重写。
5.2.5重启加载
AOF和RDB文件都可以用于服务器重启时的数据恢复。如图5-4所示，表示Redis持久化文件加载流程。
流程说明：
1）AOF持久化开启且存在AOF文件时，优先加载AOF文件，打印如下日志：
* DB loaded from append only file: 5.841 seconds
2）AOF关闭或者AOF文件不存在时，加载RDB文件，打印如下日志：
* DB loaded from disk: 5.586 seconds
3）加载AOF/RDB文件成功后，Redis启动成功。
4）AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。
5.2.6文件校验
加载损坏的AOF文件时会拒绝启动，并打印如下日志：
# Bad file format reading the append only file: make a backup of your AOF file,
then use ./redis-check-aof --fix <filename>
运维提示
对于错误格式的AOF文件，先进行备份，然后采用redis-check-aof--fix命令进行修复，修复后使用diff-u对比数据的差异，找出丢失的数据，有些可以人工修改补全。
AOF文件可能存在结尾不完整的情况，比如机器突然掉电导致AOF尾部文件命令写入不全。Redis为我们提供了aof-load-truncated配置来兼容这种情况，默认开启。加载AOF时，当遇到此问题时会忽略并继续启动，同时打印
如下警告日志：
# !!! Warning: short read while loading the AOF file !!!
# !!! Truncating the AOF at offset 397856725 !!!
# AOF loaded anyway because aof-load-truncated is enabled
5.3问题定位与优化
Redis持久化功能一直是影响Redis性能的高发地，本节我们结合常见的持久化问题进行分析定位和优化。
5.3.1fork操作
当Redis做RDB或AOF重写时，一个必不可少的操作就是执行fork操作创建子进程，对于大多数操作系统来说fork是个重量级错误。虽然fork创建的子进程不需要拷贝父进程的物理内存空间，但是会复制父进程的空间内存页表。例如对于10GB的Redis进程，需要复制大约20MB的内存页表，因此fork操作耗时跟进程总内存量息息相关，如果使用虚拟化技术，特别是Xen虚拟机，fork操作会更耗时。
fork耗时问题定位：对于高流量的Redis实例OPS可达5万以上，如果fork操作耗时在秒级别将拖Redis几万条命令执行，对线上应用延迟影响非常明显。正常情况下fork耗时应该是每GB消耗20毫秒左右。可以在info stats统计中查latest_fork_usec指标获取最近一次fork操作耗时，单位微秒。
如何改善fork操作的耗时：
1）优先使用物理机或者高效支持fork操作的虚拟化技术，避免使用Xen。
2）控制Redis实例最大可用内存，fork耗时跟内存量成正比，线上建议每个Redis实例内存控制在10GB以内。
3）合理配置Linux内存分配策略，避免物理内存不足导致fork失败，具体细节见12.1节“Linux配置优化”。
4）降低fork操作的频率，如适度放宽AOF自动触发时机，避免不必要的全量复制等。
5.3.2子进程开销监控和优化
子进程负责AOF或者RDB文件的重写，它的运行过程主要涉及CPU、内存、硬盘三部分的消耗。
1.CPU
·CPU开销分析。子进程负责把进程内的数据分批写入文件，这个过程属于CPU密集操作，通常子进程对单核CPU利用率接近90%.
·CPU消耗优化。Redis是CPU密集型服务，不要做绑定单核CPU操作。由于子进程非常消耗CPU，会和父进程产生单核资源竞争。不要和其他CPU密集型服务部署在一起，造成CPU过度竞争。如果部署多个Redis实例，尽量保证同一时刻只有一个子进程执行重写工作，具体细节见5.4节多实例部署”。
2.内存
·内存消耗分析。子进程通过fork操作产生，占用内存大小等同于父进程，理论上需要两倍的内存来完成持久化操作，但Linux有写时复制机制（-on-write）。父子进程会共享相同的物理内存页，当父进程处理写请求时会把要修改的页创建副本，而子进程在fork操作过程中共享整个父进程内存快照。
·内存消耗监控。RDB重写时，Redis日志输出容如下：
* Background saving started by pid 7692
* DB saved on disk
* RDB: 5 MB of memory used by -on-write
* Background saving terminated with success
如果重写过程中存在内存修改操作，父进程负责创建所修改内存页的副本，从日志中可以看出这部分内存消耗了5MB，可以等价认为RDB重写消耗了5MB的内存。
AOF重写时，Redis日志输出容如下：
* Background append only file rewriting started by pid 8937
* AOF rewrite child asks to stop sending diffs.
* Parent agreed to stop sending diffs. Finalizing AOF...
* Concatenating 0.00 MB of AOF diff received from parent.
* SYNC append only file rewrite performed
* AOF rewrite: 53 MB of memory used by -on-write
* Background AOF rewrite terminated with success
* Resial parent diff successfully flushed to the rewritten AOF (1.49 MB)
* Background AOF rewrite finished successfully
父进程维护页副本消耗同RDB重写过程类似，不同之处在于AOF重写需要AOF重写缓冲区，因此根据以上日志可以预估内存消耗为：53MB+1.49MB，也就是AOF重写时子进程消耗的内存量。
运维提示
编写shell脚本根据Redis日志可快速定位子进程重写期间内存过度消耗情况。
内存消耗优化：
1）同CPU优化一样，如果部署多个Redis实例，尽量保证同一时刻只有一个子进程在工作。
2）避免在大量写入时做子进程重写操作，这样将导致父进程维护大量页副本，造成内存消耗。Linux kernel在2.6.38内核增加了Transparent Huge Pages（THP），支持huge page（2MB）的页分配，默认开启。当开启时可以降低fork创建子进程的速度，但执行fork之后，如果开启THP，复制页单位从原来4KB变为2MB，会大幅增加重写期间父进程内存消耗。建议设置“sudo echo never>/sys/kernel/mm/transparent_hugepage/enabled”关闭THP。更多THP细节和配置见12.1Linux配置优化”。
3.硬盘
·硬盘开销分析。子进程主要职责是把AOF或者RDB文件写入硬盘持久化。势必造成硬盘写入压力。根据Redis重写AOF/RDB的数据量，结合系统工具如sar、iostat、iotop等，可分析出重写期间硬盘负载情况。·硬盘开销优化。优化方法如下：
a）不要和其他高硬盘负载的服务部署在一起。如：存储服务、消息队列服务等。
b）AOF重写时会消耗大量硬盘IO，可以开启配置no-appendfsync-on-rewrite，默认关闭。表示在AOF重写期间不做fsync操作。
c）当开启AOF功能的Redis用于高流量写入场景时，如果使用普通机械磁盘，写入吞吐一般在100MB/s左右，这时Redis实例的瓶颈主要在AOF同步硬盘上。
d）对于单机配置多个Redis实例的情况，可以配置不同实例分盘存储AOF文件，分摊硬盘写入压力。运维提示
配置no-appendfsync-on-rewrite=yes时，在极端情况下可能丢失整个AOF重写期间的数据，需要根据数据安全性决定是否配置。
5.3.3AOF追加阻塞
当开启AOF持久化时，常用的同步硬盘的策略是everysec，用于平衡性能和数据安全性。对于这种方式，Redis使用另一条线程每秒执行fsync同步硬盘。当系统硬盘资源繁忙时，会造成Redis主线程阻塞，如图5-5所示。
阻塞流程分析：
1）主线程负责写入AOF缓冲区。
2）AOF线程负责每秒执行一次同步磁盘操作，并记录最近一次同步时间。
3）主线程负责对比上次AOF同步时间：
·如果距上次同步成功时间在2秒内，主线程直接返回。
·如果距上次同步成功时间超过2秒，主线程将会阻塞，直到同步操作完成。
通过对AOF阻塞流程可以发现两个问题：
1）everysec配置最多可能丢失2秒数据，不是1秒。
2）如果系统fsync缓慢，将会导致Redis主线程阻塞影响效率。
AOF阻塞问题定位：
1）发生AOF阻塞时，Redis输出如下日志，用于记录AOF fsync阻塞导致拖慢Redis服务的行为：
Asynchronous AOF fsync is taking too long (disk is busy). Writing the AOF buffer
without waiting for fsync to complete, this may slow down Redis
2）每当发生AOF追加阻塞事件发生时，在info Persistence统计中，aof_delayed_fsync指标会累加，查看这个指标方便定位AOF阻塞问题。
3）AOF同步最多允许2秒的延迟，当延迟发生时说明硬盘存在高负载问题，可以通过监控工具如iotop，定位消耗硬盘IO资源的进程。优化AOF追加阻塞问题主要是优化系统硬盘负载，优化方式见上一节。
5.4多实例部署
Redis单线程架构导致无法充分利用CPU多核特性，通常的做法是在一台机器上部署多个Redis实例。当多个实例开启AOF重写后，彼此之间会产生对CPU和IO的竞争。本节主要介绍针对这种场景的分析和优化。上一节介绍了持久化相关的子进程开销。对于单机多Redis部署，如果同一时刻运行多个子进程，对当前系统影响将非常明显，因此需要采用一种措施，把子进程工作进行隔离。Redis在info Persistence中为我们提供了监控子进程运行状况的度量指标，如表5-2所示。
我们基于以上指标，可以通过外部程序轮询控制AOF重写操作的执行，整个过程如图5-6所示。
流程说明：
1）外部程序定时轮询监控机器（machine）上所有Redis实例。
2）对于开启AOF的实例，查看（aof_current_size-aof_base_size）/aof_base_size确认增长率。
3）当增长率超过特定阈值（如100%），执行bgrewriteaof命令手动触发当前实例的AOF重写。
4）运行期间循环检查aof_rewrite_in_progress和aof_current_rewrite_time_sec指标，直到AOF重写结束。
5）确认实例AOF重写完成后，再检查其他实例并重复2）~4）步操作。从而保证机器内每个Redis实例AOF重写串行化执行。
5.5本章重点回顾
1）Redis提供了两种持久化方式：RDB和AOF。
2）RDB使用一次性生成内存快照的方式，产生的文件紧凑压缩比更高，因此读取RDB恢复速度更快。由于每次生成RDB开销较大，无法做到实时持久化，一般用于数据冷备和复制传输。
3）save命令会阻塞主线程不建议使用，bgsave命令通过fork操作创建子进程生成RDB避免阻塞。
4）AOF通过追加写命令到文件实现持久化，通过appendfsync参数可以控制实时/秒级持久化。因为需要不断追加写命令，所以AOF文件体积逐渐变大，需要定期执行重写操作来降低文件体积。
5）AOF重写可以通过auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数控制自动触发，也可以使用bgrewriteaof命令手动触发。
6）子进程执行期间使用-on-write机制与父进程共享内存，避免内存消耗翻倍。AOF重写期间还需要维护重写缓冲区，保存新的写入命令避免数据丢失。
7）持久化阻塞主线程场景有：fork阻塞和AOF追加阻塞。fork阻塞时间跟内存量和系统有关，AOF追加阻塞说明硬盘资源紧张。
8）单机下部署多个实例时，为了防止出现多个子进程执行重写操作，建议做隔离控制，避免CPU和IO资源竞争。
‘肆’ 数据持久化方案解析（八） —— UIDocument的数据存储（一）
首先看下框架基本信息
使用 UIDocument 及其底层架构的应用程序可为其文档带来许多好处：
在 Model-View-Controller 设计模式中， UIDocument 对象是模型对象或模型控制器对象 - 它管理文档的数据或共同构成文档数据的聚合模型对象。您通常将其与视图控制器配对，该视图控制器管理显示文档内容的视图。 UIDocument 不支持管理文档视图。
基于文档的应用程序包括可以生成多个文档的应用程序，每个文档都有自己的文件系统位置。基于文档的应用程序必须为其文档创建 UIDocument 的子类。有关详细信息，请参阅下面的 Subclassing Notes 。
UIDocument 体系结构中文档的主要属性是其文件URL。 通过调用 initWithFileURL: 初始化文档子类的实例时，必须传递在应用程序沙箱中查找文档文件的文件 URL 。 UIDocument 从文件URL确定文件类型（与文件扩展名关联的统一类型标识符）和文档名称（文件名组件）。 您可以覆盖 fileType 和 localizedName 属性的访问器方法以提供不同的值。
以下概述了典型 document 的生命周期（有关实现细节，请参阅 Subclassing Notes ）：
典型的基于文档的应用程序在主线程上调用 openWithCompletionHandler: ， closeWithCompletionHandler: 和 saveToURL:forSaveOperation:completionHandler: 。当这些方法启动的读取或保存操作结束时，完成处理程序块在调用该方法的同一调度队列上执行，允许您根据读取或保存操作完成任何任务。如果操作不成功，则将 NO 传递到完成 - 处理 (completion-hander) 程序块。
UIDocument 类采用 NSFilePresenter 协议。当另一个客户端尝试读取基于 UIDocument 的应用程序的文档时，该读取将暂停，直到 UIDocument 对象有机会保存对该文档所做的任何更改。
虽然有些实现什么都不做，但 UIDocument 实现了所有 NSFilePresenter 方法。具体来说， UIDocument ：
在您的 UIDocument 子类中，如果重写 NSFilePresenter 方法，则始终可以调用超类实现 （super） 。
每个基于文档的应用程序必须创建 UIDocument 的子类，其实例表示其文档。大多数应用程序的子类化要求很简单：
contentsForType：error： 和 loadFromContents：ofType：error： 通常在主队列上调用方法。进一步来说：
如果您对读取和写入 contentsForType：error： 和 loadFromContents：ofType：error： 方法的文档数据有特殊要求，则可以重写 UIDocument 类的其他方法。有关这些要求和方法的讨论，请参阅 Advanced Overrides 。
要启用 UIDocument 的自动保存功能，您必须在用户更改文档时通知它。 UIDocument 定期检查 hasUnsavedChanges 方法是否返回 YES ; 如果是，则启动文档的保存操作。
在 UIDocument 子类中实现更改跟踪有两种主要方法：
UIDocument 对象在其生命周期中的任何时刻都具有特定状态。您可以通过查询 documentState 属性来检查当前状态，并通过观察 通知获得有关更改的通知。
如果为 iCloud 启用了文档，则检查是否存在冲突版本并尝试解决冲突非常重要。通过侦听 通知然后检查文档状态是否为 UIDocumentStateInConflict 来执行此操作。此状态表示文档存在冲突版本，您可以通过调用 NSFileVersion 类方法 ： 来访问该文档，并传入文档的文件URL。如果您无需用户交互即可正确解决冲突，请执行此操作。否则，离散地通知用户存在冲突并让他们选择如何解决冲突。可能的方法包括：
除了指示文件间冲突之外，文档状态可以指示错误。例如， UIDocumentStateClosed 表示读取时出错， UIDocumentStateSavingError 表示保存或还原文档时出错。通过传递给 openWithCompletionHandler： ， closeWithCompletionHandler： ， revertToContentsOfURL：completionHandler： 和 saveToURL：forSaveOperation：completionHandler： 方法的完成处理程序的 success 参数，通知您的应用程序读取和写入错误。
您可以通过调用或实现 handleError:userInteractionPermitted: 方法来处理错误；此方法由 openWithCompletionHandler 的默认实现调用和 saveToURL：forSaveOperation：completionHandler： 分别在 UIDocument 对象遇到读取或写入错误时的方法。您可以通过通知用户来处理读取，保存和还原错误，如果情况允许，则尝试从错误中恢复。
请务必阅读 contentsForType：error： 方法的说明，以获取有关处理文档保存期间遇到的错误的指导。
如果应用程序对读取或写入文档数据有特殊要求，它可以覆盖除 loadFromContents:ofType:error: 和 contentsForType:error: 之外的 UIDocument 方法。这些要求通常包括以下内容：
如果覆盖大多数这些方法，请注意所有文档数据的读取和写入必须在后台队列上完成，并且必须与其他尝试读取和写入同一文档文件相协调。因此，您通常应该将超类实现 （super） 作为覆盖的一部分来调用，如果调用其他 UIDocument 方法，则通常应该在传入 ： 方法调用的块中调用它们。阅读方法描述以获取详细信息。
如果通过覆盖相关的访问器方法来覆盖任何文档属性属性（在 Accessing Document Attributes 下列出），请注意 UIKit 框架可以在后台线程上调用这些访问器方法。 因此，您的重写实现必须是线程安全的。
返回使用其文件系统位置初始化的文档对象。
‘伍’ k8s etcd 与持久化存储
1、是什么
2、etcd架构及工作原理
(1) 数据流程
一个用户的请求发送过来，会经过HTTP Server转发给store进行具体事务处理，如果涉及到节点的修改，则需要交给raft模块进行状态的变更，日志的记录，然后再同步给别的etcd节点确认数据提交，最后进行数据提交，再次同步
(2)工作原理
Etcd使用 Raft协议 来维护集群内各个节点状态的 一致性 。简单说，ETCD集群是一个分布式系统，由多个节点相互通信构成整体对外服务， 每个节点都存储了完整的数据 ，并且通过Raft协议保证每个节点维护的数据是一致的
(3) 主要组成部分
(4)etcd集群中的术语
3、k8s中的etcd
(1)etcd在k8s中的作用： etcd在kubernetes集群是用来存放数据并通知变动的
(2)为什么k8s选择etcd：
PV 目前支持的类型包括：gcePersistentDisk 、AWSElasticBlockStore 、AzureFile 、AzureDisk 、FC ( Fibre Channel ） 、Flocker、NFS 、iSCSI 、RBD (Rados Block Device ）、CephFS 、Cinder、GlusterFS 、V sphere Volume 、Quobyte Volumes 、VMware Photon 、Portwonc
Volumes 、ScaleIO Volumes 和HostPath （仅供单机测试）。
如果某个Pod 想申请某种类型的PY ，则首先需要定义一个PersistentVolurneClaim ( PVC )对象，然后，在Pod 的Volume 定义中引用上述PVC 即可：
‘陆’ 如何在java里长期存储数据 不要数据库的那种
长期存储数据，即把数据（如内存中的）保存到可永久保存的存储设备中（如硬盘、U盘），也就是人们常说的持久化。
常用持久化的方案有数据库、XML文件和文件存储。
数据库是按照数据结构来存储和管理数据的仓库，后文不再做详细介绍。
XML是可扩展标记语言，最早是为了简化Internet的文档数据传输，它提供统一的语法格式来描述数据的结构，通常XML文件用于一些少量且无特殊类型要求的文本存储。示例代码使用W3C标准的接口生成XML：
importjava.io.FileOutputStream;
importjava.io.PrintWriter;
importjavax.xml.parsers.DocumentBuilderFactory;
importjavax.xml.transform.OutputKeys;
importjavax.xml.transform.Transformer;
importjavax.xml.transform.TransformerFactory;
importjavax.xml.transform.dom.DOMSource;
importjavax.xml.transform.stream.StreamResult;
importorg.w3c.dom.Document;
importorg.w3c.dom.Element;
publicclass${
publicstaticvoidmain(String[]args)throwsException{
Documentdocument=DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
//创建根节点为students的XML文件
Elementstudents=document.createElement("students");
document.appendChild(students);
//在根节点下创建一个子节点学生
Elementstudent=document.createElement("student");
students.appendChild(student);
//创建节点学生姓名，值为张三
Elementname=document.createElement("name");
name.appendChild(document.createTextNode("张三"));
student.appendChild(name);
//创建节点学生年龄，值为18
Elementage=document.createElement("age");
age.appendChild(document.createTextNode("18"));
student.appendChild(age);
//创建节点学生编号，值为150101
Elementnumber=document.createElement("number");
number.appendChild(document.createTextNode("150101"));
student.appendChild(number);
//在根节点下创建第二个子节点学生
student=document.createElement("student");
students.appendChild(student);
//创建节点学生姓名，值为李四
name=document.createElement("name");
name.appendChild(document.createTextNode("李四"));
student.appendChild(name);
//创建节点学生年龄，值为20
age=document.createElement("age");
age.appendChild(document.createTextNode("20"));
student.appendChild(age);
//创建节点学生编号，值为150102
number=document.createElement("number");
number.appendChild(document.createTextNode("150102"));
student.appendChild(number);
//将XML文件保存到硬盘
Transformertransformer=TransformerFactory.newInstance().newTransformer();
transformer.setOutputProperty(OutputKeys.ENCODING,"utf-8");
transformer.setOutputProperty(OutputKeys.INDENT,"yes");
PrintWriterwriter=newPrintWriter(newFileOutputStream("/home/test.xml"));
transformer.transform(newDOMSource(document),newStreamResult(writer));
}
}
无论是数据库还是XML文件，它们都使用了能让数据快速方便进出的标准规范。其它文件如propeties、json，都可以使用类似XML的方式来打包数据，然后通过Java丰富的io流接口保存到磁盘中。
‘柒’ 什么是数据持久化为什么要持久化
数据持久化就是将内存中的数据模型转换为存储模型,以及将存储模型转换为内存中的数据模型的统称. 数据模型可以是任何数据结构或对象模型,存储模型可以是关系模型、XML、二进制流等。cmp和Hibernate只是对象模型到关系模型之间转换的不同实现。
数据持久化对象的基本操作有：保存、更新、删除、查询等。
Hibernate框架中数据持久化机制：
在业务程序与数据库之间，Hibernate框架使用Session会话，来完成数据的提交、更新、删除、查询等等。
1、向数据库提交数据
在程序中保存对象时，会把数据保存到Session会话中，然后根据框架的配置文件，自动或手动决定什么时候把这种保存提交到数据库。
2、从数据库中查询数据
在查询数据之前，需要清理缓存（手动清理，或者通过配置文件框架自动清理）清理缓存的目的是为了使Session会话中的数据与数据库中的数据保持一致。然后程序只需要查询Session会话中的数据即可。
(7)具有返回值的持久化存储模块扩展阅读：
使用数据持久化有以下好处：
1、程序代码重用性强，即使更换数据库，只需要更改配置文件，不必重写程序代码。
2、业务逻辑代码可读性强，在代码中不会有大量的SQL语言，提高程序的可读性。
3、持久化技术可以自动优化，以减少对数据库的访问量，提高程序运行效率。
‘捌’ JPA2.0对于javaEE的进步在哪儿
JavaEE 5平台引入了Java持久化API(Java Persistence API，JPA)，它为Java EE和Java SE应用程序提供了一个基于POJO的持久化模块。JPA处理关系数据与Java对象之间的映射，它使对象/关系(O/R)映射标准化，JPA已经被广泛采用，已经成为事实上的O/R持久化企业标准。
Java EE 6带来了JPA的最新版本 — JSR 317：Java持久化2.0，JPA 2.0带来了许多新特性和增强，包括：
1、对象/关系映射增强;
2、Java持久化查询语言增强;
3、一种新的基于标准的查询API;
4、支持悲观锁定。
对象/关系映射增强
JPA 1.0支持集合的映射，但这些集合只能包含实体，JPA 2.0增加了集合映射的基础数据类型，如String和Integer，以及嵌入式对象的集合。JPA中的嵌入式对象是一个不能存在于它自身的对象，而是作为父对象的一部分存在，即它的数据不是存在于它自己的表中，而是嵌入在父对象的表中。
JPA 2.0增加了两个支持新的集合映射的注解：@ElementCollection 和 @CollectionTable。使用@ElementCollection注解指定集合的嵌入式对象，这些集合是独立存储 href=”http://storage.it168.com/” target=_blank>存储在集合表中的，使用@CollectionTable注解指定集合表的详细信息，如它包含的列。
下面是一个嵌入式类，表示了车辆的访问服务，它存储了访问的日期，描述和费用，此外，车辆可以配备一或多个可选功能，每个功能是FeatureType类型的一个枚举值。
publicenumFeatureType { AC, CRUISE, PWR, BLUETOOTH, TV, … }
@Embeddable
publicclassServiceVisit {
@Temporal(DATE)
@Column(name=”SVC_DATE”)
Date serviceDate;
String workDesc;
intcost;
}
枚举值和嵌入式对象可以在一个表示车辆服务历史的实体中使用，如：
@Entity
public
class
Vehicle {
@Id
int
vin;
@ElementCollection
@CollectionTable
(name=”VEH_OPTNS”)
. @Column(name=”FEAT”) Set<FeatureType> optionalFeatures;
@ElementCollection
@CollectionTable(name=”VEH_SVC”)
@OrderBy(“serviceDate”)
List<ServiceVisit>
serviceHistory;
… }
Vehicle实体中的第一对注解@ElementCollection 和 @CollectionTable指定FeatureType值存储在VEH_OPTNS集合表中，第二对注解@ElementCollection 和 @CollectionTable指定ServiceVisit嵌入式对象存储在VEH_SVC集合表中。
虽然在例子中没有显示，@ElementCollection注解有两个属性：targetClass 和 fetch。targetClass属性指定基础类或嵌入式类的类名，如果字段或属性是使用泛型定义的，那这两个属性是可选的，上面这个例子就是这样。Fetch属性是可选的，它指定集合是延后检索还是立即检索，使用javax.persistence.FetchType常量，值分别用LAZY和EAGER，默认情况下，集合是延后匹配的。
JPA 2.0中还有其它许多关于对象/关系映射的增强，例如，JPA 2.0支持嵌套式嵌入，关系嵌入和有序列表，也增加了新的注解增强映射功能，通过@Access注解更灵活地支持特定的访问类型，更多用于实体关系的映射选项，如对单向一对多关系的外键映射支持，通过@MapsId注解支持派生身份，支持孤体删除。
Java持久化查询语言增强
JPA 1.0定义了一个广泛的Java持久化查询语言，使用它你可以查询实体和它们的持久化状态。JPA 2.0对JPQL做了大量改进，如现在可以在查询中使用case表达式。在下面的查询中，如果雇员的评分为1，则通过乘以1.1对雇员的薪水进行了增长，如果评分为2，则乘以1.05，其它评分则乘以1.01。
UPDATE
Employeee
SETe.salary
=
CASEWHENe.rating =1THENe.salary *
1.1
WHENe.rating =2THENe.salary *
1.05
ELSEe.salary *
1.01
END
JPA 2.0也为JPQL增加了大量新的运算符，如NULLIF和COALESCE，当数据库使用其它非空数据解码时，NULLIF运算符是非常有用的，使用NULLIF，你可以在查询中将这些值转换为空值，如果参数等于NULLIF，NULLIF会返回空值，否则返回第一个参数的值。
假设薪水数据保存在employee表中，数据类型为整数，却掉的薪水解码为-9999，下面的查询返回薪水的平均值，为了正确地忽略却掉的薪水，查询使用NULLIF将-9999转换为空值。
SELECTAVG(NULLIF(e.salary, -
99999
))
FROM
Employeee
COALESCE运算符接收一串参数，从列表中返回第一个非空值，相当于下面的case表达式：
CASEWHENvalue1 ISNOTNULL
THEN
value1
WHENvalue2 ISNOTNULL
THEN
value2
WHENvalue3 ISNOTNULL
THEN
value3
…
ELSENULL
END
COALESCE运算符接收一串参数，从列表中返回第一个非空值，相当于下面的case表达式：
SELECTName,
COALESCE
(e.work_phone, e.home_phone) phone
FROM
Employeee
假设employee表包括一个办公电话号码和家庭电话号码列，无电话号码的列使用空值表示。下面的查询返回每个雇员的姓名和电话号码，COALESCE运算符指定查询返回办公电话号码，但如果为空，则返回家庭电话号码，如果两者都为空，则返回一个空值。
JPA 2.0向JPQL增加的其它运算符是INDEX，TYPE，KEY，VALUE和ENTRY。INDEX运算符指定查询时的排序顺序，TYPE运算符选择一个实体的类型，将查询限制到一或多个实体类型，KEY，VALUE和ENTRY运算符是JPA 2.0中的泛化映射功能的一部分。使用KEY运算符提取映射键，VALUE运算符提取映射值，ENTRY运算符选择一个映射实体。
此外，JPA 2.0增加了选择列表、以及集合值参数和非多态查询中运算符的支持。
标准的API
JPA 2.0中引入的另一个重要特性是标准的API，利用这个API可以动态地构建基于对象的查询，本质上，这个标准API等价于面向对象的JPQL，使用它，你可以使用基于对象的方法创建查询，不再需要JPQL使用的字符串操作。
标准API是基于元模型的，元模型是一个提供了架构级关于持久化单元托管类的元数据的抽象模型， 元模型让你构建强类型的查询，它也允许你浏览持久化单元的逻辑结构。
通常，一个注解处理器使用元模型生成静态元模型类，这些类提供持久化状态和持久化单元托管类的关系，但你可以对静态元模型类编码。下面是一个实体实例：
@Entity
public
class Employee {
@Id
Long
Id;
String firstName;
String lastName;
Department dept; }
下面是对应的静态元模型类：
importjavax.persistence.meta,model.SingularAttribute;
import
javax.persistence.meta,model.StaticMetamodel;
@Generated(“EclipseLink JPA 2.0 Canonical Model Generation”
@StaticMetamodel(Employee.
class
)
public
class
Employee_ {
publicstatic
volatile
SingularAttribute<Employee, Long> id;
publicstatic
volatile
SingularAttribute<Employee, String> firstName;
publicstatic
volatile
SingularAttribute<Employee, String> lastName;
publicstatic
volatile
SingularAttribute<Employee, Department> dept;
}
此外，JPA 2.0元模型API允许你动态访问元模型，因此当你使用标准API时，既可以静态访问元模型类，也可以动态访问元模型类。标准API提供了更好的灵活性，既可以使用基于对象的方法，又可以使用基于字符串的方法导航元模型，这意味着你有四种使用标准API的方法：
1、静态使用元模型类
2、静态使用字符串
3、动态使用元模型
4、动态使用字符串
无论你使用哪种方法，通过构造一个CriteriaQuery对象定义一个基于标准API的查询时，使用一个工厂对象CriteriaBuilder构造CriteriaQuery，可以从EntityManager 或 EntityManagerFactory类中获得CriteriaBuilder。下面的代码构造一个CriteriaQuery对象：
EntityManager em = … ;
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Customer> cq = cb.createQuery(Customer.
class
);
注意CriteriaQuery对象是泛型类型，使用CriteriaBuilder 的createQuery方法创建一个CriteriaQuery，并为查询结果指定类型。在这个例子中，createQuery 方法的Employee.class参数指定查询结果类型是Employee。CriteriaQuery对象和创建它们的方法是强类型的。
接下来，为CriteriaQuery对象指定一个或多个查询源，查询源表示查询基于的实体。你创建一个查询源，然后使用AbstractQuery接口的from()方法将其添加到查询。AbstractQuery接口是众多接口中的一员，如CriteriaQuery，From和root，它们都定义在标准API中。CriteriaQuery接口继承AbstractQuery接口的属性。
from()方法的参数是实体类或EntityType实体的实例，from()方法的结果是一个Root对象，Root接口扩展From接口，它表示某个查询的from子句中可能出现的对象。
下面的代码增加一个查询源到CriteriaQuery对象：
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Employee> cq = cb.createQuery(Employee.
class
);
Root<Employee> emp = cq.from(Employee.
class
);
当你向CriteriaQuery对象添加一个或多个查询源后，你访问元模型，然后构造一个查询表达式，你如何做取决于你是以静态方式提交查询还是以动态方式提交查询，以及是使用元模型还是字符串导航元模型。下面是一个使用元模型类静态查询的例子：
cq.select(emp);
cq.where(cb.equal(emp.get(Employee_.lastName), “Smith”));
TypedQuery<Employee> query = em.createQuery(cq);
List<Employee> rows = query.getResultList();
CriteriaQuery接口的select() 和 where()方法指定查询结果返回的选择项目。
注意，你使用EntityManager创建查询时，可以在输入中指定一个CriteriaQuery对象，它返回一个TypedQuery，它是JPA 2.0引入javax.persistence.Query接口的一个扩展，TypedQuery接口知道它返回的类型。
在元模型术语中，Employee_是对应于Employee实体类的规范化元模型类，一个规范化元模型类遵循JPA 2.0规范中描述的某些规则。例如，元模型类的名字来源于托管类，一般都是在托管类名字后面追加一个下划线“_”。一个规范化元模型是一个包含静态元模型类的元模型，这个静态元模型对应于实体，映射的超类，以及持久化单元中的嵌入式类。实际上，这个查询使用了规范化元模型。下面是一个完整的查询：
EntityManager em = … ;
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Employee> cq = cb.createQuery(Employee.
class
);
Root<Employee> emp = cq.from(Employee.
class
);
cq.select(emp);
cq.where(cb.equal(emp.get(Employee_.lastName), “Smith”));
TypedQuery<Employee> query = em.createQuery(cq);
List<Employee> rows = query.getResultList();
下面是使用元模型API查询的动态版本：
EntityManager em = … ;
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Employee> cq = cb.createQuery(Employee.
class
);
Root<Employee> emp = cq.from(Employee.
class
);
EntityType<Employee> emp_ = emp.getModel();
cq.select(emp);
cq.where(cb.equal(emp.get(emp_.getSingularAttribute(“lastName”, String.
class
)),”Smith”));
TypedQuery<Employee> query=em.createQuery(cq);
List<Employee> rows=query.getResultList();
使用元模型API的标准查询提供了与使用规范化元模型相同的类型，但它比基于规范化元模型的查询更冗长。
Root的getModel()方法返回根对应的元模型实体，它也允许运行时访问在Employee实体中声明的持久化属性。
getSingularAttribute()方法是一个元模型API方法，它返回一个持久化的单值属性或字段，在这个例子中，它返回值为Smith 的lastName属性。下面是使用字符串的元数据导航查询的静态版本：
EntityManager em = … ;
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Employee> cq = cb.createQuery(Employee.
class
);
Root<Employee> emp = cq.from(Employee.
class
);
cq.select(emp);
cq.where(cb.equal(emp.get(“lastName”), “Smith”));
TypedQuery query = em.createQuery(cq);
List <Employee>rows = query.getResultList();
这个基于字符串的方法要相对容易使用些，但却失去了元模型具有的类型安全href=”http://safe.it168.com/” target=_blank>安全。
支持悲观锁
锁是处理数据库事务并发的一种技术，当两个或更多数据库事务并发地访问相同数据时，锁可以保证同一时间只有一个事务可以修改数据。
锁的方法通常有两种：乐观锁和悲观锁。乐观锁认为多个并发事务之间很少出现冲突，也就是说不会经常出现同一时间读取或修改相同数据，在乐观锁中，其目标是让并发事务自由地同时得到处理，而不是发现或预防冲突。两个事务在同一时刻可以访问相同的数据，但为了预防冲突，需要对数据执行一次检查，检查自上次读取数据以来发生的任何变化。
悲观锁认为事务会经常发生冲突，在悲观锁中，读取数据的事务会锁定数据，在前面的事务提交之前，其它事务都不能修改数据。
JPA 1.0只支持乐观锁，你可以使用EntityManager类的lock()方法指定锁模式的值，可以是READ或WRITE，如：
EntityManager em = … ;em.lock (p1, READ);
对于READ锁模式，JPA实体管理器在事务提交前都会锁定实体，检查实体的版本属性确定实体自上次被读取以来是否有更新，如果版本属性被更新了，实体管理器会抛出一个OptimisticLockException异常，并回滚事务。
对于WRITE锁模式，实体管理器执行和READ锁模式相同的乐观锁操作，但它也会更新实体的版本列。
JPA 2.0增加了6种新的锁模式，其中两个是乐观锁。JPA 2.0也允许悲观锁，并增加了3种悲观锁，第6种锁模式是无锁。
下面是新增的两个乐观锁模式：
1、OPTIMISTIC：它和READ锁模式相同，JPA 2.0仍然支持READ锁模式，但明确指出在新应用程序中推荐使用OPTIMISTIC。
2、OPTIMISTIC_FORCE_INCREMENT：它和WRITE锁模式相同，JPA 2.0仍然支持WRITE锁模式，但明确指出在新应用程序中推荐使用OPTIMISTIC_FORCE_INCREMENT。
下面是新增的三个悲观锁模式：
1、PESSIMISTIC_READ：只要事务读实体，实体管理器就锁定实体，直到事务完成锁才会解开，当你想使用重复读语义查询数据时使用这种锁模式，换句话说就是，当你想确保数据在连续读期间不被修改，这种锁模式不会阻碍其它事务读取数据。
2、PESSIMISTIC_WRITE：只要事务更新实体，实体管理器就会锁定实体，这种锁模式强制尝试修改实体数据的事务串行化，当多个并发更新事务出现更新失败几率较高时使用这种锁模式。
3、PESSIMISTIC_FORCE_INCREMENT：当事务读实体时，实体管理器就锁定实体，当事务结束时会增加实体的版本属性，即使实体没有修改。
你也可以指定新的锁模式NONE，在这种情况下表示没有锁发生。
JPA 2.0也提供了多种方法为实体指定锁模式，你可以使用EntityManager的lock() 和 find()方法指定锁模式。此外，EntityManager.refresh()方法可以恢复实体实例的状态。
下面的代码显示了使用PESSIMISTIC_WRITE锁模式的悲观锁：
// read
Part p = em.find(Part.
class
, pId);
// lock and refresh before update
em.refresh(p, PESSIMISTIC_WRITE);
int
pAmount = p.getAmount();
p.setAmount(pAmount - uCount);
在这个例子中，它首先读取一些数据，然后应用PESSIMISTIC_WRITE锁，在更新数据之前调用EntityManager.refresh()方法，当事务更新实体时，PESSIMISTIC_WRITE锁锁定实体，其它事务就不能更新相同的实体，直到前面的事务提交。
‘玖’ android中数据持久化方式有哪些
android中数据持久化方式有以下五种：
1、Shared Preferences
Store private primitive data in key-value pairs。
2、Internal Storage
Store private data on the device memory，把数据持久化存储到手机内部存储空间，它主要用于私有数据存储。
3、External Storage
Store public data on the shared external storage，把数据持久化存储到手机外部SD卡中，它主要用于非隐秘数据存储。
4、SQLite Databases
Store structured data in a private database。
5、Network Connection
Store data on the web with your own network server，
Android provides a way for you to expose even your private data to other applications — with a content provider. A content provider is an optional component that exposes read/write access to your application data, subject to whatever restrictions you want to impose. For more information about using content providers, see the Content Providers documentation。
‘拾’ Redis的持久化机制 (RDB&amp;AOF&amp;混合模式)
RDB（Redis DataBase，快照方式） 是将某一个时刻的内存数据，以二进制的方式写入磁盘。 AOF（Append Only File，文件追加方式） 是指将所有的操作命令，以文本的形式追加到文件中。
RDB
RDB 默认的保存文件为 mp.rdb，优点是以二进制存储的，因此 占用的空间更小 、数据存储更紧凑，并且与 AOF 相比，RDB 具备 更快的重启恢复能力 。
AOF
AOF 默认的保存文件为 appendonly.aof，它的优点是存储频率更高，因此 丢失数据的风险就越低 ，并且 AOF 并不是以二进制存储的，所以它的存储信息更易懂。缺点是 占用空间大 ， 重启之后的数据恢复速度比较慢 。
混合
在 Redis 4.0 就推出了混合持久化的功能。Redis 混合持久化的存储模式是， 开始的数据以 RDB 的格式进行存储 ，因此只会占用少量的空间， 并且之后的命令会以 AOF 的方式进行数据追加 ，这样就可以减低数据丢失的风险，同时可以提高数据恢复的速度。
Fork
Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时（ 默认值 64M ），Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。Redis 会fork出一条新进程来将 文件重写Rewrite (也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的set语句。重写aof文件的操作，并没有读取旧的aof文件， 而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。