本地持久化缓存

1. 如何从持久化存储中读取数据

对于数据的持久化存储，ios中一般提供了4种不同的机制。
1.属性列表
2.对象归档
3.数据库存储（sqlite3）
4.苹果公司提供的持久性工具Core Data。
其实储存的形式无非就这么几种，而我们还必须要关心的是，这些文件会被放置在那个文件下，然后如何读取。
也就是说：IOS上数据存储，我们要了解的两点，数据存储格式（也就是存储机制），数据存储位置。
1》文件如何存储（如上面4点）
2》文件存储在哪里。
对于数据的操作，其实我们关心的是操作的速率。
就好比在Adnroid中偏好存储，数据库存储，io存储一样。

2. 什么是数据持久化为什么要持久化

数据持久化就是将内存中的数据模型转换为存储模型,以及将存储模型转换为内存中的数据模型的统称. 数据模型可以是任何数据结构或对象模型,存储模型可以是关系模型、XML、二进制流等。cmp和Hibernate只是对象模型到关系模型之间转换的不同实现。

数据持久化对象的基本操作有：保存、更新、删除、查询等。

Hibernate框架中数据持久化机制：

在业务程序与数据库之间，Hibernate框架使用Session会话，来完成数据的提交、更新、删除、查询等等。

1、向数据库提交数据

在程序中保存对象时，会把数据保存到Session会话中，然后根据框架的配置文件，自动或手动决定什么时候把这种保存提交到数据库。

2、从数据库中查询数据

在查询数据之前，需要清理缓存（手动清理，或者通过配置文件框架自动清理）清理缓存的目的是为了使Session会话中的数据与数据库中的数据保持一致。然后程序只需要查询Session会话中的数据即可。

(2)本地持久化缓存扩展阅读：

使用数据持久化有以下好处：

1、程序代码重用性强，即使更换数据库，只需要更改配置文件，不必重写程序代码。

2、业务逻辑代码可读性强，在代码中不会有大量的SQL语言，提高程序的可读性。

3、持久化技术可以自动优化，以减少对数据库的访问量，提高程序运行效率。

3. java web开发缓存方案，ehcache和redis哪个更好

这里就不再逐个讨论了，我将会在一个实际应用程序开发场景中介绍其中的一些。使用Redis作为一个缓存解决方案我之前提到过，Redis可轻易地用作一个缓存解决方案，碰巧我现在正好需要这样一个！在该应用程序示例中，我将Redis集成到我基于定位的移动Web服务中，称之为Magnus。如果您没有关注本系列，那么我会先使用Play框架实现Magnus，从那时起我就已经在各种实现中开发和重构它了。Magnus是一个简单服务，可以通过HTTPPUT请求使用JSON文档。这些文档描述了特定帐号的位置，表示持有移动设备的人。现在，我想要将缓存集成到Magnus，也就是说我想要通过将不常更改的数据存储在内存中以减少I/O流量。Magnus缓存！在清单5中的第一步中，可以通过get调用了解新引入的帐户名称（一个键）是否为REdis中的一个键。get调用可以将帐户ID作为一个值返回，或者将返回null。如果返回一个值，我将用其作为我的acctId变量。如果返回的是null（表明该帐户名称不是Redis中一个键），那么我将在MongoDB查找该帐户值，并通过set命令将其添加到Redis。这里的优势是速度：接下来，被请求的帐户将提交一个位置，这样我就能够从Redis中获取其ID（作为内存缓存），而不是转到MongoDB并带来额外读取I/O成本。清单5.使用Redis作为内存缓存"/location/:account"{put{defjacksonMapper=newObjectMapper()defjson=jacksonMapper.readValue(request.contentText,Map.class)defformatter=newSimpleDateFormat("dd-MM-yyyyHH:mm")defdt=formatter.parse(json['timestamp'])defres=[:]try{defjedis=pool.getResource()defacctId=jedis.get(request.parameters['account'])if(!acctId){defacct=Account.findByName(request.parameters['account'])jedis.set(request.parameters['account'],acct.id.toString())acctId=acct.id}pool.returnResource(jedis)newLocation(acctId.toString(),dt,json['latitude'].doubleValue(),json['longitude'].doubleValue()).save()res['status']='success'}catch(exp){res['status']="error${exp.message}"}response.json=jacksonMapper.writeValueAsString(res)}}注意，清单5中的aMagnus实现（使用Groovy编写）仍然使用一个NoSQL实现作为数据模型存储；它仅仅使用Redis作为一个缓存实现用于查询数据。因为我的主要帐户数据位于MongoDB中（事实上，它驻留在MongoHQ.com中），而我的Redis数据存储在本地运行。在随后查找帐户ID时，Magnus速度将显着提升。可是等等！我为什么同时需要MongoDB和Redis？难道我就不能单独使用一个吗？ORM的Node.js很多项目均提供ORM类映射用于Redis，其中包括一个极富影响力的基于Ruby的备用方案，称为Ohm。我检查了该项目基于Java的派生产品（称为JOhm），但是最终决定使用一个为Node编写的派生产品。Ohm及其派生项目的妙处在于他们允许您将一个对象模型映射到一个基于Redis的数据结构。因此，您的模型对象是持久性的，同时在大多数情况下其读取速度也非常之快。有了Nohm，我便能够使用JavaScript快速重写我的Magnus应用程序并能立即持久化Location对象。在清单6中，我已定义了一个Location模型，该模型包括3个属性。（注意，我通过将timestamp设置为一个字符串而不是一个真实的时间戳，从而简化我的示例。）清单6.Node.js中的RedisORMvarLocation=nohm.model('Location',{properties:{latitude:{type:'float',unique:false,validations:[['notEmpty']]},longitude:{type:'float',unique:false,validations:[['notEmpty']]},timestamp:{type:'string',unique:false,validations:[['notEmpty']]}}});Node的Express框架使NohmLocation对象的使用变得十分简单。在我的应用程序PUT实现中，我可以捕获正在进入的JSON值，并通过Nohm的p调用将其导入到一个Location实例。然后我再检查该示例是否有效，如果有效，我会对其进行持久化。清单7.在Node的Express.js中使用Nohmapp.put('/',function(req,res){res.contentType('json');varlocation=newLocation;location.p("timestamp",req.body.timestamp);location.p("latitude",req.body.latitude);location.p("longitude",req.body.longitude);if(location.valid()){location.save(function(err){if(!err){res.send(JSON.stringify({status:"success"}));}else{res.send(JSON.stringify({status:location.errors}));}});}else{res.send(JSON.stringify({status:location.errors}));}});正如清单7所示，可以轻易地将Redis构建成一个极其快速的内存数据存储。在一些案例中，它甚至是一个比memcached更好的缓存！结束语Redis对于许多数据存储场景非常有用，因为它可以将数据持久化到磁盘（还因为它支持一个丰富的数据集），有时候，它是memcached的有力竞争对手。有些情况下，对于您的领域也是很有意义的，您可以使用Redis作为数据模型和队列的一个备份存储。Redis客户端实现几乎可被移植到任何编程语言中。Redis不是RDMBS的完全替代品，也不是一个重量级存储，但是和MongoDB一样拥有丰富的功能。然而，在很多情况下，它可与这些技术共存。

4. 如何从持久化存储中读取数据

MySQL 8 之前，使用的动态变量不是永久性的，并且在重启后会重置。可在运行时使用 SET 语句更改这些变量，以影响当前实例的操作，但是我们必须手动更新 my.cnf 配置文件以使其持久化。
在许多情况下，从服务端更新 my.cnf 并不是一个方便的选择，并且使变量仅被更新才能在后续重新启动时动态还原，而没有任何历史记录。
持久化系统变量是 MySQL 8 中引入的功能之一。新功能可帮助 DBA 动态更新变量并注册它们，而无需从服务器端访问配置文件。

如何持久化全局系统变量？
与 SET GLOBAL 一样，SET PERSIST 是可用于在运行时更新系统变量并使它们在重新启动后保持不变的命令。当我们使用 PERSIST 关键字时，变量更改将更新到数据目录中的 mysqld-auto.cnf 选项文件。mysqld-auto.cnf 是仅在第一次执行 PERSIST 或 PERSIST_ONLY 语句时创建的 JSON 格式文件。

5. 缓存与数据持久化有什么区别

持久化就是找个地方存缓存里的数据，以后需要的时候在从这个地方读到缓存里。 查看原帖>>

6. ios缓存跟持久化是一个意思吗

数据的持久化本质上都是就是写文件，但从逻辑上又分成很多种，比如写入沙盒(其实是一个本应用程序才可以访问的路径)，比如存到网络上，比如写入数据库。 你的问题问的是数据库相关，那么针对它讨论， Core data与sqlite还是有联系的，core data 是对sqlite的封装，因为sqlite是c语言的api，然而有人也需要obj-c 的api，所以有了 core data 另外，core data不仅仅是把c的api翻译成oc 的api，还提供了一些管理的功能，使用更加方便。

7. Redis 持久化 ★

1、RDB
2、AOF
3、两种的使用场景

在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

（1）Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程
（2）在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”
（3）一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

在redis.conf中配置文件名称，默认为mp.rdb

rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下
dir "/myredis/"

dir ./ 表示在当前配置文件的文件夹下生成 .rdb文件

（1）配置文件中默认的快照配置

（2）命令save VS bgsave
save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。
bgsave：Redis会在后台异步进行快照操作， 快照同时还可以响应客户端请求。
可以通过lastsave 命令获取最后一次成功执行快照的时间

（3）save（禁用）
格式：save 秒钟 写操作次数
RDB是整个内存的压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件，
默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次。(短时间内越多越快)

不设置save指令，或者给save传入空字符串

（4）stop-writes-on-bgsave-error
如果配置成no，表示你不在乎数据不一致或者有其他的手段发现和控制

（5）rdbcompression 压缩文件
对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能：

（6）rdbchecksum
在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能：

（7）rdb的备份

1）将备份文件 (mp.rdb) 移动到 redis 安装目录并启动服务即可

2）CONFIG GET dir获取目录

（1）优点：
适合大规模的数据恢复
对数据完整性和一致性要求不高更适合使用
节省磁盘空间
恢复速度快

（2）缺点：
Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

（1）客户端的请求写命令会被append追加到AOF缓冲区内；
（2）AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
（3）AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
（4）Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的

可以在redis.conf中配置文件名称，默认为 appendonly.aof
AOF文件的保存路径，同RDB的路径一致。

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。

正常恢复：
修改默认的appendonly no，改为yes
将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
恢复：重启redis然后重新加载

异常恢复：
修改默认的appendonly no，改为yes
如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复
备份被写坏的AOF文件
恢复：重启redis，然后重新加载

appendfsync always
始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好

appendfsync everysec
每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no
redis不主动进行同步，把同步时机交给操作系统。

（1）是什么
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof

（2）重写原理，如何实现重写
AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，redis4.0版本后的重写，是指上就是把rdb 的快照，以二级制的形式附在新的aof头部，作为已有的历史数据，替换掉原来的流水账操作。

no-appendfsync-on-rewrite：
如果 no-appendfsync-on-rewrite=yes ,不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）

重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定Redis要满足一定条件才会进行重写。

（3）重写流程
（1）bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。
（2）主进程fork出子进程执行重写操作，保证主进程不会阻塞。
（3）子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。
（4）
1).子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。
2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。
（5）使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

备份机制更稳健，丢失数据概率更低。
可读的日志文本，通过操作AOF稳健，可以处理误操作。

比起RDB占用更多的磁盘空间。
恢复备份速度要慢。
每次读写都同步的话，有一定的性能压力。
存在个别Bug，造成恢复不能。

官方推荐两个都启用。
如果对数据不敏感，可以选单独用RDB。
不建议单独用 AOF，因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。

https://blog.csdn.net/xm393392625/article/details/89053171

8. 常用的缓存技术

第一章 常用的缓存技术
1、常见的两种缓存

本地缓存：不需要序列化，速度快，缓存的数量与大小受限于本机内存
分布式缓存：需要序列化，速度相较于本地缓存较慢，但是理论上缓存的数量与大小无限（因为缓存机器可以不断扩展）
2、本地缓存

Google guava cache：当下最好用的本地缓存
Ehcache：spring默认集成的一个缓存，以spring cache的底层缓存实现类形式去操作缓存的话，非常方便，但是欠缺灵活，如果想要灵活使用，还是要单独使用Ehcache
Oscache：最经典简单的页面缓存
3、分布式缓存

memcached：分布式缓存的标配
Redis：新一代的分布式缓存，有替代memcached的趋势
3.1、memcached

经典的一致性hash算法
基于slab的内存模型有效防止内存碎片的产生（但同时也需要估计好启动参数，否则会浪费很多的内存）
集群中机器之间互不通信（相较于Jboss cache等集群中机器之间的相互通信的缓存，速度更快<--因为少了同步更新缓存的开销，且更适合于大型分布式系统中使用）
使用方便（这一点是相较于Redis在构建客户端的时候而言的，尽管redis的使用也不困难）
很专一（专做缓存，这一点也是相较于Redis而言的）
3.2、Redis

可以存储复杂的数据结构（5种）
strings-->即简单的key-value，就是memcached可以存储的唯一的一种形式，接下来的四种是memcached不能直接存储的四种格式（当然理论上可以先将下面的一些数据结构中的东西封装成对象，然后存入memcached，但是不推荐将大对象存入memcached，因为memcached的单一value的最大存储为1M，可能即使采用了压缩算法也不够，即使够，可能存取的效率也不高，而redis的value最大为1G）
hashs-->看做hashTable
lists-->看做LinkedList
sets-->看做hashSet，事实上底层是一个hashTable
sorted sets-->底层是一个skipList
有两种方式可以对缓存数据进行持久化
RDB
AOF
事件调度
发布订阅等
4、集成缓存

专指spring cache，spring cache自己继承了ehcache作为了缓存的实现类，我们也可以使用guava cache、memcached、redis自己来实现spring cache的底层。当然，spring cache可以根据实现类来将缓存存在本地还是存在远程机器上。

5、页面缓存

在使用jsp的时候，我们会将一些复杂的页面使用Oscache进行页面缓存，使用非常简单，就是几个标签的事儿；但是，现在一般的企业，前台都会使用velocity、freemaker这两种模板引擎，本身速度就已经很快了，页面缓存使用的也就很少了。

总结：

在实际生产中，我们通常会使用guava cache做本地缓存+redis做分布式缓存+spring cache就集成缓存（底层使用redis来实现）的形式
guava cache使用在更快的获取缓存数据，同时缓存的数据量并不大的情况
spring cache集成缓存是为了简单便捷的去使用缓存（以注解的方式即可），使用redis做其实现类是为了可以存更多的数据在机器上
redis缓存单独使用是为了弥补spring cache集成缓存的不灵活
就我个人而言，如果需要使用分布式缓存，那么首先redis是必选的，因为在实际开发中，我们会缓存各种各样的数据类型，在使用了redis的同时，memcached就完全可以舍弃了，但是现在还有很多公司在同时使用memcached和redis两种缓存。

9. jfinal如何实现缓存持久化

Cache 缓存

1 :EhCache

EhCachePlugin是JFinal集成的缓存插件，通过使用EhCachePlugin可以提高系统的并发访问速度。

网页链接

ehcache.xml简介

EhCache的使用需要有ehcache.xml配置文件支持，该配置文件中配置了很多cache节点，每个cache节点会配置一个name属性，例如：<cache name="blog" …>，该属性是CacheKit取值所必须的。其它配置项如eternal、overflowToDisk、timeToIdleSeconds、timeToLiveSeconds详见EhCache官方文档。cache节点配置为都写入磁盘即可.


2: Redis

RedisPlugin是支持 Redis的极速化插件。使用RedisPlugin可以极度方便的使用redis，该插件不仅提供了丰富的API，而且还同时支持多redis服务端。Redis拥有超高的性能，丰富的数据结构，天然支持数据持久化，是目前应用非常广泛的nosql数据库。对于redis的有效应用可极大提升系统性能，节省硬件成本。网页链接

3:j2cache
开源中国教主红薯的二级缓存,性能非常高,是 EhCache+Redis二合一的处理方式
网页链接

10. memcached可以持久化吗

memcached 是缓存系统，通过名字就可以看出来，官网也明确说了（Free & open source, high-performance, distributed memory object caching system），之所以是缓存系统，就说明它不会作为可靠的数据存储，所以并不支持持久化。
另一个是redis，他是一个存储系统，官网也说了。只不过redis是在内存中存储的，所以速度快，因为是存储系统，所以可以作为一个可靠的数据存储系统。支持持久化。