数据持久化

面试题 如何保证消息的可靠性传输？或者说，如何处理消息丢失的问题？ 面试官心理分析 这个是肯定的，用 MQ 有个基本原则，就是 数据不能多一条，也不能少一条 ，不能多，就是前面说的 重复消费和幂等性问题 。不能少，就是说这数据别搞丢了。那这个问题你必须得考虑一下。 如果说你这个是用 MQ 来传递非常核心的消息，比如说计费、扣费的一些消息，那必须确保这个 MQ 传递过程中 绝对不会把计费消息给弄丢 。 面试题剖析 数据的丢失问题，可能出现在生产者、 MQ 、消费者中，咱们从 RabbitMQ 和 Kafka 分别来分析一下吧。 RabbitMQ 生产者弄丢了数据 生产者将数据发送到 RabbitMQ 的时候，可能数据就在半路给搞丢了，因为网络问题啥的，都有可能。 此时可以选择用 RabbitMQ 提供的事务功能，就是生产者 发送数据之前 开启 RabbitMQ 事务 channel.txSelect ，然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务 channel.txRollback ，然后重试发送消息；如果收到了消息，那么可以提交事务 channel.txCommit 。 但是问题是， RabbitMQ 事务机制（同步）一搞，基本上 吞吐量会下来，因为太耗性能 。 所以一般来说，如果你要确保说写 RabbitMQ

一、不是万能的菲关系系数据库redis 在面试的时候，常被问比较下Redis与Memcache的优缺点，个人觉得这二者并不适合一起比较，redis：是非关系型数据库不仅可以做缓存还能干其它事情，Memcache：是仅用做缓存。常常让我们对这二者进行比较，主要也是由于Redis最广泛的应用场景就是Cache。 1.2 redis 都能干嘛 缓存，毫无疑问这是Redis当今最为人熟知的使用场景。再提升服务器性能方面非常有效； 排行榜，在使用传统的关系型数据库（mysql oracle 等）来做这个事儿，非常的麻烦，而利用Redis的SortSet(有序集合)数据结构能够简单的搞定； 计算器/限速器，利用Redis中原子性的自增操作，我们可以统计类似用户点赞数、用户访问数等，这类操作如果用MySQL，频繁的读写会带来相当大的压力；限速器比较典型的使用场景是限制某个用户访问某个API的频率，常用的有抢购时，防止用户疯狂点击带来不必要的压力； 好友关系，利用集合的一些命令，比如求交集、并集、差集等。可以方便搞定一些共同好友、共同爱好之类的功能； 简单消息队列，除了Redis自身的发布/订阅模式，我们也可以利用List来实现一个队列机制，比如：到货通知、邮件发送之类的需求，不需要高可靠，但是会带来非常大的DB压力，完全可以用List来完成异步解耦； Session共享，以PHP为例

Redis 是支持 RDB 和 AOF 两种持久化的机制，持久化的功能可以有效的避免当进程崩溃。退出时造成的数据损失。当进程退出后，我们下次启动的时候，利用之前持久化的文件马上就可以恢复原有的数据。我们先大致理解一下官方的介绍： RDB 持久化的方式，是在指定条件下，能对数据库进行快照存储。比如手动触发或者自动按照时间间隔。 AOF 持久化是以记录命令为条件来完成的。 AOF 打开的时候，对Redis的所有写操作全部按照 Redis 的协议格式进行保存，把新的命令追加到文件末尾来完成 AOF 文件的保存。前边也介绍过可以通过 BGREWRITAOF 这个命令完成 AOF 文件的重写，不至于 AOF 文件过大，成为磁盘或者恢复时的负担。 Redis 还可以同时打开 RDB 和 AOF 持久化，重启的时候优先使用 AOF 文件，因为 AOF 文件更完整。 RDB详解 AOF详解 toc RDB详解 RDB 是 Redis 一种持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中 在 Redis 配置文件 SNAPSHOTTING 板块内容中 ## 前面常用配置提到过，忘记的可以出门左转看一下 ## 分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。 save 900 1 save 300 10

Redis、Memcache和MongoDB的区别 https://www.cnblogs.com/tuyile006/p/6382062.html >>Memcached Memcached的优点： Memcached可以利用多核优势，单实例吞吐量极高，可以达到几十万QPS（取决于key、value的字节大小以及服务器硬件性能，日常环境中QPS高峰大约在4-6w左右）。适用于最大程度扛量。 支持直接配置为session handle。 Memcached的局限性： 只支持简单的key/value数据结构，不像Redis可以支持丰富的数据类型。 无法进行持久化，数据不能备份，只能用于缓存使用，且重启后数据全部丢失。 无法进行数据同步，不能将MC中的数据迁移到其他MC实例中。 Memcached内存分配采用Slab Allocation机制管理内存，value大小分布差异较大时会造成内存利用率降低，并引发低利用率时依然出现踢出等问题。需要用户注重value设计。 >>Redis Redis的优点： 支持多种数据结构，如 string（字符串）、 list(双向链表)、dict(hash表)、set(集合）、zset(排序set)、hyperloglog（基数估算） 支持持久化操作，可以进行aof及rdb数据持久化到磁盘，从而进行数据备份或数据恢复等操作，较好的防止数据丢失的手段。

1. Redis持久化都有哪些类型？ 　　Redis持久化分为两种： RDB持久化与AOF持久化 2. 两种持久化的异同？ 　　（1）RDB持久化：RDB持久化是将我们运行过程中Redis数据库中的对象保存到RDB文件中。 　　　　a. RDB持久化功能所生成的RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件时的数据库状态。 　　　　b. 生成RDB文件的两个命令：SAVE, BGSAVE。 　　　　c. RDB文件载入期间，会一直处于阻塞状态，直到载入工作完成。 　 （2）AOF持久化：AOF持久化是将我们运行过程中的命令保存在AOF文件中，这样只需要重新执行这些命令就可以恢复到原来的状态。 3. SAVE与BGSAVE的区别？ 　　（1） SAVE命令会阻塞当前线程，而BGSAVE命令会派生出一个子进程来负责创建RDB文件。 　　（2） 由于BGSAVE命令不需要阻塞，因此Redis允许通过配置save选项设置保存条件，让服务器每隔一段时间执行一次BGSAVE命令。 　　　　例如：save 200 1 表示在200秒之内至少对数据库进行1次修改时，BGSAVE命令将会执行。 4. AOF持久化功能的实现？ 　　（1）AOF持久化功能的实现可以分为命令追加，文件写入，文件同步三个步骤。 　　　　a. 命令追加：当AOF持久化功能处于打开状态时

Redis持久化--Redis宕机或者出现意外删库导致数据丢失--解决方案 https://www.cnblogs.com/xlecho/p/11834011.html echo编辑整理，欢迎转载，转载请声明文章来源。欢迎添加echo微信(微信号：t2421499075)交流学习。 百战不败，依不自称常胜，百败不颓，依能奋力前行。——这才是真正的堪称强大！！！ Redis持久化的方案其实是很多人接触的比较少的，因为相对应的数据故障不会很多，一次初始化的设置就能保证后续故障的全部顺利解决。本文讲述一下该机制的主要设置方法和持久化方案的对比，同时也会讲述一些持久化的原理。如果对于Redis持久化比较熟悉的希望能够给到你帮助，如果不熟悉的，你大可参考本文对你的Redis进行设置。 什么是Redis的持久化？ 可能很多人很少接触这个词，总觉的我们Redis的所有数据都是全部能够永久存储的。然而你可能不知道的是，Redis的数据都是在内存当中的，如果没有持久化策略，你关闭Redis或者之后，你的数据有可能全部都丢失了。我们每再一次登录Redis访问上一次数据的时候，我们都看到了原来的数据，就是得益于Redis的持久化。Redis的持久化简单说就是，将Redis存在内存中的值存储到可以永久存储的地方（磁盘等） Redis的持久化方案 RDB Redis DataBase AOF Append

为什么用消息队列 举例 比如在一个企业里，技术老大接到boss的任务，技术老大把这个任务拆分成多个小任务，完成所有的小任务就算搞定整个任务了。 那么在执行这些小任务的时候，可能有一个环节很费时间，并且优先级很低，推迟完成也不影响整个任务运转，那么技术老大就会将这个很费时间，且不重要的任务，丢给他的小弟去解决，自己继续完成其他任务。 转化为计算机思想 那个技术老大就是一个 程序系统，那个小弟就是消息队列。 当程序系统发现某些任务耗费时间且优先级较低，迟点完成也不影响整个任务，就把这个任务丢给消息队列。 场景 在程序系统中，例如外卖系统，订单系统，库存系统，优先级较高 发红包，发邮件，发短信，app消息推送等任务优先级很低，很适合交给消息队列去处理，以便于程序系统更快的处理其他请求。 消息队列工作流程 消息队列一般有三个角色： 队列服务端 队列生产者 队列消费者 消息队列工作流程就如同一个流水线，有产品加工，一个输送带，一个打包产品 输送带就是 不停运转的消息队列服务端 加工产品的就是 队列生产者 在传输带结尾打包产品的 就是队列消费者 队列产品 RabbitMQ Erlang编写的消息队列产品，企业级消息队列软件，支持消息负载均衡，数据持久化等。 ZeroMQ saltstack软件使用此消息，速度最快。 Redis key-value的系统，也支持队列数据结构，轻量级消息队列

Redis持久化方案 RDB Redis DataBase; AOF Append Only File; 　RDB是redis默认的持久化方案 , 满足一定的条件的时候,会把当前的数据写入磁盘,生成一个快照文件dump.rdb ; redis重启会通过加载dump.rdb文件恢复数据 ; RDB实现持久化: 　　RDB按照规则来触发持久化存储的 , 在redis.config中我们可以看到以下几个配置: 　　　　save 900 1 # 900秒内至少有一个key被修改(包括添加) 　　　　save 300 10 # 300秒内至少有10个key被修改 　　　　 save 60 10000 60秒内至少有10000个key被修改 注意 : 这几个配置不冲突,只要满足一个就会被触发 ; 　　RDB的优点: 　　　　　　　　1. RDB是一个紧凑的单一文件,很方便; 　　　　　　　　2.与AOF相比,恢复大数据的时候,RDB稍微快一些 ; 　　RDB的缺点: 　　　　　　　　1.没有办法做到实时/秒持久化 ; 原因:因为运行的成本较高,每次运行bgsave都要执行fork操作创建的子进程 ; 　　　　　　　　2.一定的间隔时间内做一次备份,如果redis意外down掉,会丢失最后一次快照之后的所有修改, 如果数据比较重要可以使用AOF进行持久化; AOF持久化： 　　　Redis

一、 对于 hibernate 中的 PO 编写规则 : 1. 必须提供一个无参数的 public 构造方法 2. 所有属性要 private , 对外提供 public 的 get/set 方法 3. 在 PO 类必须提供一个标识属性，让它与数据库中的主键对应，我们管这个属性叫 OID， Hibernate框架它是通过OID来区分不同的PO对象，如果在内存中有两个相同的OID对象，那么hibernate认为它们是同一个对象。 4. PO 类中的属性尽量使用基本数据类型的包装类，使用基本数据类型是没有办法去描述不存在概念，如果使用包装类型，它就是一个对象，对于对象它的默认值是null.。 5. PO 类它不能使用 final 修饰符， Get/load 方法它们都是根据 id 去查询对象。 　　1. get 直接得到了一个持久化类型对象，它就是立即查询操作 　　load 它得到的是持久化类开的代理类型对象（子类对象）。它采用了一种延迟策略来查询数据。 　　2. get 方法在查询时，如果不存在返回 null 　　load 方法在查询时，如果 不存在，会产生异常 ObjectNotFoundException. 二、H ibernate 主键生成策略 Hibernate中定义的主键类型包括：自然主键和代理主键： 自然主键：具有业务含义 字段 作为主键，比如：学号、身份证号 代理主键

问题 如何保证消息的可靠性传输？或者说，如何处理消息丢失的问题？ 数据的丢失问题，可能出现在生产者、MQ、消费者中，从 RabbitMQ 和 Kafka 分别来分析一下吧。 RabbitMQ 生产者弄丢了数据 生产者将数据发送到 RabbitMQ 的时候，可能数据就在半路给搞丢了，因为网络问题啥的，都有可能。 此时可以选择用 RabbitMQ 提供的事务功能，就是生产者发送数据之前开启 RabbitMQ 事务channel.txSelect，然后发送消息，如果消息没有成功被 RabbitMQ 接收到，那么生产者会收到异常报错，此时就可以回滚事务channel.txRollback，然后重试发送消息；如果收到了消息，那么可以提交事务channel.txCommit。 // 开启事务 channel.txSelect try { // 这里发送消息 } catch (Exception e) { channel.txRollback // 这里再次重发这条消息 } // 提交事务 channel.txCommit 但是问题是，RabbitMQ 事务机制（同步）一搞，基本上吞吐量会下来，因为太耗性能。 所以一般来说，如果要确保说写 RabbitMQ 的消息别丢，可以开启 confirm 模式，在生产者那里设置开启 confirm 模式之后，你每次写的消息都会分配一个唯一的 id