数据持久化

参考 https://blog.csdn.net/zdp072/article/details/50991116 https://blog.csdn.net/qq_34337272/article/details/80012284#commentBox 坑人无数的Redis面试题（未整理，写的很棒，超出了理论范围，结合实际中的问题，给出不错的解决方案） https://blog.csdn.net/u011405515/article/details/79190652 0 什么是Redis？ Redis 是一个使用 C 语言写成的，开源的，基于内存的 key-value 数据库。 支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。 与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。目前，Vmware在资助着redis项目的开发和维护。 1 使用redis有哪些好处

一、RDB 1、RDB是什么 （1）在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里 （2）Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。 （3）fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程 （4）rdb 保存的是dump.rdb文件 2、如何触发RDB快照 （1）配置文件中默认的快照配置 （2）命令save或者是bgsave 3、如何恢复 （1）将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可 （2）CONFIG GET dir获取目录 4、优势和劣势 （1）优势 （2）劣势 二、AOF 1、是什么 （1）以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件

Redis的数据回写机制 Redis的数据回写机制分同步和异步两种， 同步回写即SAVE命令，主进程直接向磁盘回写数据。在数据大的情况下会导致系统假死很长时间，所以一般不是推荐的。 异步回写即BGSAVE命令，主进程fork后，复制自身并通过这个新的进程回写磁盘，回写结束后新进程自行关闭。由于这样做不需要主进程阻塞，系统不会假死，一般默认会采用这个方法。 个人感觉方法２采用fork主进程的方式很拙劣，但似乎是唯一的方法。内存中的热数据随时可能修改，要在磁盘上保存某个时间的内存镜像必须要冻结。冻结就会导致假死。fork一个新的进程之后等于复制了当时的一个内存镜像，这样主进程上就不需要冻结，只要子进程上操作就可以了。 在小内存的进程上做一个fork,不需要太多资源，但当这个进程的内存空间以Ｇ为单位时，fork就成为一件很恐怖的操作。何况在16G内存的主机上fork 14G内存的进程呢？肯定会报内存无法分配的。更可气的是，越是改动频繁的主机上fork也越频繁，fork操作本身的代价恐怕也不会比假死好多少。 找到原因之后，直接修改/etc/sysctl.conf内核参数vm.overcommit_memory= 1 sysctl -p Linux内核会根据参数vm.overcommit_memory参数的设置决定是否放行。 vm.overcommit_memory = 0：则比较

Redis数据库持久化 一、数据库概述； 二、持久化的作用以及实现方式； 三、RDB持久化方式配置； 四、AOF持久化方式配置； 一、数据库概述： Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务器。 二、持久化的作用以及实现方式： 作用： 实现方式： RDB持久化：将Reids在内存中的数据库记录定时dump到磁盘上，类似于快照功能。 AOF持久化：append only file--原理是将Reids的操作日志以追加的方式写入文件，近似实时性。 二者的区别： RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。 AOF持久化是以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。 RDB的优势： 1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据

1.memcached：单一键值对内存缓存的，做对象缓存无可替代的分布式缓存； 2.redis：是算法和数据结构的集合，快速的数据结构操作是他最大的特点，支持数据持久化； 3.mongodb 是 bson 结构、介于 rdb 和 nosql 之间的，更松散更灵活的，但是不支持事务，只用作非重要数据存储。 转载请标明出处: Nosql 数据库 MemCache、Redis、MongoDB 的区别 文章来源: https://blog.csdn.net/tlsxtk/article/details/92084613

1、前言 Redis 是一种高级 key - value 数据库。 Redis 跟 Memcached 类似，不过数据可以持久化，而且支持的数据类型很丰富。有 str 、 list 、 set 、 hash 、 zset(sorted set) 。支持在服务器端计算集合的并、交和补集，还支持各种排序功能。所以 Redis 也可以被看成是一个数据结构服务器。 Redis 的所有数据都是保存在内存中，然后不定期的通过 异步 方式保存到磁盘上(这称为"半持久化模式"- RDB )；也可以把每一次数据变化都写入到一个 Append Only File 里面（这称为"全持久化模式"- AOF ）。 由于 Redis 的数据都存放在内存中，如果没有配置持久化， Redis 重启后数据就全丢失了，于是需要开启 Redis 的持久化功能，将数据保存到磁盘上，当 Redis 重启后，可以从磁盘中恢复数据。 Redis 提供两种方式进行持久化，一种是 RDB 持久化（原理是将 Redis 在内存中的数据库记录定时 Dump 到磁盘上的 RDB 持久化），另外一种是 AOF （ Append Only File )持久化（原理是将 Redis 的操作日志以追加的方式写入文件）。 那么这两种持久化有什么区别呢，该如何选择呢？ 2、两者的区别 RDB 持久化是指在制定的时间间隔内将内存中的数据集快照写入磁盘

【本文内容来自网络总结】 Redis是一个开源、高性能、基于键值对的缓存与存储系统。 劣势：Redis是单线程，Memcached是多线程，在多核服务器上后者的性能理论上会更高一些。 优势：随着Redis3.0的推出，标志着memcache的所有功能都已经成了Redis的子集。同时Redis对集群的支持使得Memcache原有的第三方集群工具不再成为优势。因此，在新项目中使用Redis替代Memcache将会是非常好的选择。 （1）字符串类型 （Key-Value） 使用最多的类型 （2）散列类型 （Hash） 适合存储对象 （3）列表类型 （List） （4）集合类型 （Set） （5）有序集合类型 （Zset） 内存 Remote Dictionary Server（远程数据服务） 共六种数据淘汰策略。（分三类） 一、从已设置过期的数据集 （1）volatile-lru：从已设置过期时间的数据集中，选择最近最少使用的数据淘汰 （2）volatile-ttl：从已设置过期时间的数据集中，选择将要过期的数据淘汰 （3）volatile-random：从已设置过期时间的数据集中，任意选择数据淘汰 二、从整体数据集 （4）allkeys-lru：从全数据集中，选择最近最少使用的数据淘汰 （5）allkeys-random：从全数据集中任意选择数据淘汰 三、驱逐（默认策略-直接返回错误）

1.Spring Data JPA可以极大地简化JPA的写法，在几乎不用写接口实现的情况下完成对数据的访问和操作。 2.Spring Data通过提供Repository接口来约定数据访问的统一标准。 3.Repository接口下包含一些常用的子接口： 4.在进行spring boot 项目的开发中，开发者只需要定义自己项目的数据访问接口，然后实现Spring Data提供的这些接口，就可以实现对数据的CRUD操作。 CrudRepository提供了最基本的对实体类的增删改查操作 新建新的Maven项目，命名SpringBoot_crudrepositorytest,按照Maven项目的规范，在src/main下新建一个名为resource的文件夹 ①修改pom.xml <project xmlns=" http://maven.apache.org/POM/4.0.0 " xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance " http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd "> </project> ②配置基本属性 在src/main/resource下新建一个全局配置文件，命名为application

16.持久化 16.1.持久化存储 16.1.1.ժҪ JCache提供了 javax.cache.integration.CacheLoader 和 javax.cache.integration.CacheWriter API，他们分别用于底层持久化存储的 通读 和 ͨд 虽然Ignite可以单独地配置 CacheRLoader 和 CacheWriter ，但是在两个单独的类中实现事务化存储是非常尴尬的，因为多个 load 和 put 操作需要在同一个事务中的同一个连接中共享状态。为了缓解这个问题，Ignite提供了・org.apacche.ignite.cache.store.CacheStore・接口，他同时扩展了 CacheLoader 和 CacheWriter 。 事务 CacheStore CacheJdbcPojoStore Ignite附带了他自己的 CacheJdbcPojoStore ,他会自动地建立Java POJO和数据库模式之间的映射，可以参照 3.13.自动持久化章节 。 16.1.2.通读和通写 要配置通读和通写，需要实现 CacheStore 接口以及设置 CacheConfiguration 中 cacheStoreFactory 的 readThrough 和 writeThrough 属性，下面的例子会有说明。 16.1.3.后写缓存

1.无状态应用与有状态应用 应用的有状态和无状态是根据应用是否有持久化保存数据的需求而言的，即持久化保存数据的应用为有状态的应用，反之则为无状态的应用。常见的系统往往是有状态的应用，比如对于微博和微信这类应用，所有用户发布的内容和留言都是要保存记录的。但是一个系统往往是由众多微服务或更小的应用模块构成的。有的微服务或模块其实并没有数据持久化的需求。例如，搭建一个Wordpress博客系统需要部署一个前端的PHP应用，以及一个后端的MySQL数据库。虽然整个博客系统有持久化的需求，是一个有状态的系统，但是其子模块前端PHP应用并没有将数据保存在本地，而是存放到MySQL数据库中。所以一个Wordpress系统可以拆解成一个无状态的前端以及一个有状态的后端。有状态和无状态的应用在现实当中比比皆是。从实例数量上来说，无状态的应用应该会更多一些，因为对大多数的系统而言，读请求的数量往往远远高于写请求的数量。 非持久化的容器 容器的一个特点是当容器退出后，其内部所有的数据和状态就会丢失。同样的镜像再次启动一个新的容器实例，该实例默认不会继承之前实例的状态。这对无状态应用来说不是问题，相反是一个很好的特性，可以很好地保证无状态应用的一致性。但是对于有状态的应用来说则是很大的障碍。试想一下，如果你的MySQL容器每次重启后，之前所有的数据都丢失了，那将会是怎样一种灾难！ 容器数据持久化