Redis个人理解

1. Redis介绍,Redis是什么

正在上传…重新上传取消Redis是NoSql数据库之一,Reids包含多种数据结构,支持网络，基于内存，可选持久性的键值对存储数据库。

Redis数据结构 ：

基于内存的好处 :支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次进行加载使用，并且可以解决高并发的问题。
持久性（持久化）:将内存的数据写入到磁盘中，防止服务器宕机内存数据丢失，就是redis的持久化.

Redis的两种持久化机制 RDB和AOF（默认是RDB快照）
（AOF追加日志）

1. 为什么要是用Redis

   从性能方面考虑，redis读写快，可以提高性能
从并发方面考虑，redis将数据存储于内存中，可以有效的解决高并发问题。

4 redis做缓存的实现步骤

 

1. 使用redis缓存vo数据的方方面面 预热和持久化的过程

  整理：首先VO 为 value 和 object 对象，它主要用来存放没和数据库的任何一个表对应的元素  在项目中我们用其来设计点赞数，收藏数和阅读数

我们将这些key存放到一个枚举类中 因为枚举类更加的直观，类型更安全，其次一个项目中 不可能只有几个key，考虑到多个key创建时，如果使用class来创建需要写大量的private final static 而枚举类创建实例则可以省略这些， 根据其英文意思 设计他的key名字 方便代码的阅读性，key中的time属性 设置为-1 表示持久化，如后续需要更改 可以重新设置时间 （当需要设计限制时，只需要查询redis中有无这个key则可以做到限制）

预热：预热也是初始化的意思 ，我们需要用spring listener来实现，因为如果使用Web listener的话，框架等还未初始化完成会导致初始化不到这些内容。

从Mysql到redis为初始化，我们需要实现正在上传…重新上传取消接口

并实现里面的方法正在上传…重新上传取消

将需要预热的功略存放到集合中 遍历这个结婚 查看redis中是否已经存储了这个vo对象 如果存储了 那么我们就不需要再从mysql中奖数据同步到redis中了。

持久化 redis数据同步到mysql则为数据的持久化正在上传…重新上传取消代表周期性的执行，开启计时任务启动类也需要开启计时任务

将redis查到的vo对象 设置到mysql中通过使用 updateWrapper来进行操作

1. Redis常见面试题、

Redis 内存淘汰机制

Redis中通过maxmemory参数来设定内存的使用上限，当Redis使用内存达到设定的最大值的时候，会根据配置文件中的策略选取要删除的key来删除，从而给新的键值留出空间；

redis 提供 6种数据淘汰策略：(默认策略no-eviction)

volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）

allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。

4.0版本后增加以下两种：

volatile-lfu：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰

allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的key

Redis 持久化机制(怎么保证 redis 挂掉之后再重启数据可以进行恢复)

Redis的一种持久化方式叫快照（snapshotting，RDB），另一种方式是只追加文件（append-only file,AOF）

快照（snapshotting）持久化（RDB）:

Redis可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis主从结构，主要用来提高Redis性能），还可以将快照留在原地以便重启服务器的时候使用。

AOF（append-only file）持久化

与快照持久化相比，AOF持久化 的实时性更好，因此已成为主流的持久化方案。默认情况下Redis没有开启AOF（append only file）方式的持久化，可以通过appendonly参数开启：

appendonly yes

开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof。

在Redis的配置文件中存在三种不同的 AOF 持久化方式，它们分别是：

appendfsync always    #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度
appendfsync everysec  #每秒钟同步一次，显示地将多个写命令同步到硬盘
appendfsync no        #让操作系统决定何时进行同步

为了兼顾数据和写入性能，用户可以考虑 appendfsync everysec选项 ，让Redis每秒同步一次AOF文件，Redis性能几乎没受到任何影响。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。

Redis 4.0 对于持久化机制的优化

Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 aof-use-rdb-preamble 开启）。

如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF 里面的 RDB 部分是压缩格式不再是 AOF 格式，可读性较差。

Redis缓存雪崩

什么是缓存雪崩？

简介：缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。

有哪些解决办法？

1：在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个 key 只允许一个线程查询数据和写缓存，其他线程等待。

2：不同的 key，设置不同的过期时间，让缓存失效的时间点尽量均匀

什么是缓存穿透？

缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。

1）缓存无效 key

如果缓存和数据库都查不到某个 key 的数据就写一个到 redis 中去并设置过期时间，具体命令如下：SET key value EX 10086。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求key，会导致 redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。

2）布隆过滤器

*布隆过滤器是一个非常神奇的数据结构，通过它我们可以非常方便地判断一个给定数据是否存在与海量数据中。我们需要的就是判断 key 是否合法，有没有感觉布隆过滤器就是我们想要找的那个“人”。具体是这样做的：把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，我会先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程

缓存击穿

缓存击穿，就是说某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况，当这个 key 在失效的瞬间，大量的请求就击穿了缓存，直接请求数据库，就像是在一道屏障上凿开了一个洞。

不同场景下的解决方式可如下：

若缓存的数据是基本不会发生更新的，则可尝试将该热点数据设置为永不过期。

若缓存的数据更新不频繁，且缓存刷新的整个流程耗时较少的情况下，则可以采用基于 Redis、zookeeper 等分布式中间件的分布式互斥锁，或者本地互斥锁以保证仅少量的请求能请求数据库并重新构建缓存，其余线程则在锁释放后能访问到新缓存。

若缓存的数据更新频繁或者在缓存刷新的流程耗时较长的情况下，可以利用定时线程在缓存过期前主动地重新构建缓存或者延后缓存的过期时间，以保证所有的请求能一直访问到对应的缓存。

什么是Redis中的BigKey

在Redis中，一个字符串最大512MB，一个二级数据结构（例如hash、list、set、zset）可以存储大约40亿个(2^32-1)个元素，但实际上中如果下面两种情况，我就会认为它是bigkey。

在Redis开发规范中，string类型控制在10KB以内，hash、list、set、zset元素个数不要超过5000。

Redis的BigKey的危害

操作导致超时阻塞：由于Redis单线程的特性，操作bigkey的通常比较耗时，也就意味着阻塞Redis可能性越大，这样会造成客户端阻塞或者引起故障切换，它们通常出现在慢查询中。

查询导致网络阻塞: bigkey也就意味着每次获取要产生的网络流量较大，假设一个bigkey为1MB，客户端每秒访问量为1000，那么每秒产生1000MB的流量，对于普通的千兆网卡(按照字节算是128MB/s)的服务器来说简直是灭顶之灾，而且一般服务器会采用单机多实例的方式来部署，也就是说一个bigkey可能会对其他实例造成影响，其后果不堪设想。

过期删除导致阻塞:有个bigkey，它安分守己（只执行简单的命令，例如hget、lpop、zscore等），但它设置了过期时间，当它过期后，会被删除，如果没有使用Redis 4.0的过期异步删除(lazyfree-lazy-expire yes)，就会存在阻塞Redis的可能性，而且这个过期删除不会从主节点的慢查询发现（因为这个删除不是客户端产生的，是内部循环事件，可以从latency命令中获取或者从slave节点慢查询发现）