1.Redis是什么？有哪些用途？
简单来说 Redis 就是⼀个使⽤ C 语⾔开发的数据库，不过与传统数据库不同的是 Redis 的数据 是存在内存中的 ，也就是它是内存数据库，所以读写速度⾮常快，因此 Redis 被⼴泛应⽤于缓存 ⽅向。另外，Redis 除了做缓存之外，Redis 也经常⽤来做分布式锁，甚⾄是消息队列。 Redis 提供了多种数据类型来⽀持不同的业务场景。Redis 还⽀持事务 、持久化、Lua 脚本、多 种集群⽅案。
2. Redis 常见数据结构、常用命令以及使⽤场景分析?
1) String:
* 介绍 ：底层是SDS,Redis 的 SDS 不光可以保存⽂本数据还可以保存 ⼆进制数据，并且获取字符串⻓度复杂度为 O(1)（C 字符串为 O(N)）,除此之外,Redis 的 SDS API 是安全的，不会造成缓冲区溢出。默认是1M,最大长度是512M。
* 常⽤命令: set,get,strlen,exists,dect,incr,setex 等等。
* 应⽤场景 ：⼀般常⽤在需要计数的场景，⽐如⽤户的访问次数、热点⽂章的点赞转发数量等 等。
2) List
* 介绍 ：list 即是 链表。链表是⼀种⾮常常⻅的数据结构，特点是易于数据元素的插⼊和删除 并且且可以灵活调整链表⻓度，但是链表的随机访问困难。许多⾼级编程语⾔都内置了链表 的实现⽐如 Java 中的 LinkedList，但是 C 语⾔并没有实现链表，所以 Redis 实现了⾃⼰ 的链表数据结构。Redis 的 list 的实现为⼀个 双向链表，即可以⽀持反向查找和遍历，更⽅ 便操作，不过带来了部分额外的内存开销。
* 常⽤命令: rpush,lpop,lpush,rpop,lrange,llen 等。
* 应⽤场景: 发布与订阅或者说消息队列、慢查询。
3) Hash
* 介绍 ：hash 类似于 JDK1.8 前的 HashMap，内部实现也差不多(数组 + 链表)。不过， Redis 的 hash 做了更多优化。另外，hash 是⼀个 string 类型的 field 和 value 的映射表， 特别适合⽤于存储对象，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的 值。 ⽐如我们可以 hash 数据结构来存储⽤户信息，商品信息等等。
* 常⽤命令： hset,hmset,hexists,hget,hgetall,hkeys,hvals 等。
* 应⽤场景: 系统中对象数据的存储。
4) Set
* 介绍 ： set 类似于 Java 中的 HashSet 。Redis 中的 set 类型是⼀种⽆序集合，集合中的元 素没有先后顺序。当你需要存储⼀个列表数据，⼜不希望出现重复数据时，set 是⼀个很好 的选择，并且 set 提供了判断某个成员是否在⼀个 set 集合内的重要接⼝，这个也是 list 所 不能提供的。可以基于 set 轻易实现交集、并集、差集的操作。⽐如：你可以将⼀个⽤户所 有的关注⼈存在⼀个集合中，将其所有粉丝存在⼀个集合。Redis 可以⾮常⽅便的实现如共 同关注、共同粉丝、共同喜好等功能。这个过程也就是求交集的过程。
* 常⽤命令： sadd,spop,smembers,sismember,scard,sinterstore,sunion 等。
* 应⽤场景: 需要存放的数据不能重复以及需要获取多个数据源交集和并集等场景
5) Sorted set
* 介绍： 和 set 相⽐，sorted set 增加了⼀个权重参数 score，使得集合中的元素能够按 score 进⾏有序排列，还可以通过 score 的范围来获取元素的列表。有点像是 Java 中 HashMap 和 TreeSet 的结合体。
* 常⽤命令： zadd,zcard,zscore,zrange,zrevrange,zrem 等。
* 应⽤场景： 需要对数据根据某个权重进⾏排序的场景。⽐如在直播系统中，实时排⾏信息包 含直播间在线⽤户列表，各种礼物排⾏榜，弹幕消息（可以理解为按消息维度的消息排⾏ 榜）等信息。
3.为什么 Redis 选择单线程模型?
Redis 选择使用单线程模型处理客户端的请求主要还是因为 CPU 不是 Redis 服务器的瓶颈，所以使用多线程模型带来的性能提升并不能抵消它带来的开发成本和维护成本，系统的性能瓶颈也主要在网络 I/O 操作上；而 Redis 引入多线程操作也是出于性能上的考虑，对于一些大键值对的删除操作，通过多线程非阻塞地释放内存空间也能减少对 Redis 主线程阻塞的时间，提高执行的效率。
4.过期的数据的删除策略知道吗？
惰性删除 ：只会在取出key的时候才对数据进⾏过期检查。这样对CPU最友好，但是可能会 造成太多过期 key 没有被删除。
定期删除 ： 每隔⼀段时间抽取⼀批 key 执⾏删除过期key操作。并且，Redis 底层会通过限 制删除操作执⾏的时⻓和频率来减少删除操作对CPU时间的影响。
定期删除对内存更加友好，惰性删除对CPU更加友好。两者各有千秋，所以Redis 采⽤的是 定期 删除+惰性/懒汉式删除 。 但是，仅仅通过给 key 设置过期时间还是有问题的。因为还是可能存在定期删除和惰性删除漏掉 了很多过期 key 的情况。这样就导致⼤量过期 key 堆积在内存⾥，然后就Out of memory了。 怎么解决这个问题呢？答案就是： Redis 内存淘汰机制。
5.Redis 内存淘汰机制了解么？
Redis 提供 6 种数据淘汰策略
1. volatile-lru（least recently used）：从已设置过期时间的数据集（server.db[i].expires） 中挑选最近最少使⽤的数据淘汰
2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
4. allkeys-lru（least recently used）：当内存不⾜以容纳新写⼊数据时，在键空间中，移除 最近最少使⽤的 key（这个是最常⽤的）
5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
6. no-eviction：禁⽌驱逐数据，也就是说当内存不⾜以容纳新写⼊数据时，新写⼊操作会报 错。这个应该没⼈使⽤吧！ 4.0 版本后增加以下两种：
7. volatile-lfu（least frequently used）：从已设置过期时间的数据集(server.db[i].expires)中 挑选最不经常使⽤的数据淘汰
8. allkeys-lfu（least frequently used）：当内存不⾜以容纳新写⼊数据时，在键空间中，移 除最不经常使⽤的 key
6.Redis 持久化机制了解吗？
快照（snapshotting）持久化（RDB）
Redis 可以通过创建快照来获得存储在内存里面的数据在某个时间点上的副本。Redis 创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本（Redis 主从结构，主要用来提高 Redis 性能），还可以将快照留在原地以便重启服务器的时候使用。
快照持久化是 Redis 默认采用的持久化方式，在 Redis.conf 配置文件中默认有此下配置：
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
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 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。
7.说说缓存穿透与缓存雪崩？
7.1 什么是缓存穿透？ 缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。
7.2 如何解决？ 缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。
最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。
1）缓存无效 key
如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间，具体命令如下： SET key value EX 10086 。这种方式可以解决请求的 key 变化不频繁的情况，如果黑客恶意攻击，每次构建不同的请求 key，会导致 Redis 中缓存大量无效的 key 。很明显，这种方案并不能从根本上解决此问题。如果非要用这种方式来解决穿透问题的话，尽量将无效的 key 的过期时间设置短一点比如 1 分钟。
2）布隆过滤器
布隆过滤器是一个非常神奇的数据结构，通过它我们可以非常方便地判断一个给定数据是否存在于海量数据中。我们需要的就是判断 key 是否合法，有没有感觉布隆过滤器就是我们想要找的那个“人”。
具体是这样做的：把所有可能存在的请求的值都存放在布隆过滤器中，当用户请求过来，先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话，直接返回请求参数错误信息给客户端，存在的话才会走下面的流程。
但是，需要注意的是布隆过滤器可能会存在误判的情况。总结来说就是： 布隆过滤器说某个元素存在，小概率会误判。布隆过滤器说某个元素不在，那么这个元素一定不在。
为什么会出现误判的情况呢? 我们还要从布隆过滤器的原理来说！
我们先来看一下，当一个元素加入布隆过滤器中的时候，会进行哪些操作：
- 使用布隆过滤器中的哈希函数对元素值进行计算，得到哈希值（有几个哈希函数得到几个哈希值）。
- 根据得到的哈希值，在位数组中把对应下标的值置为 1。
我们再来看一下，当我们需要判断一个元素是否存在于布隆过滤器的时候，会进行哪些操作：
- 对给定元素再次进行相同的哈希计算；
- 得到值之后判断位数组中的每个元素是否都为 1，如果值都为 1，那么说明这个值在布隆过滤器中，如果存在一个值不为 1，说明该元素不在布隆过滤器中。
然后，一定会出现这样一种情况：不同的字符串可能哈希出来的位置相同。 （可以适当增加位数组大小或者调整我们的哈希函数来降低概率）
更多关于布隆过滤器的内容可以看我的这篇原创：《不了解布隆过滤器？一文给你整的明明白白！》 ，强烈推荐，个人感觉网上应该找不到总结的这么明明白白的文章了。
7.3. 什么是缓存雪崩？
我发现缓存雪崩这名字起的有点意思，哈哈。
实际上，缓存雪崩描述的就是这样一个简单的场景：缓存在同一时间大面积的失效，后面的请求都直接落到了数据库上，造成数据库短时间内承受大量请求。 这就好比雪崩一样，摧枯拉朽之势，数据库的压力可想而知，可能直接就被这么多请求弄宕机了。
举个例子：系统的缓存模块出了问题比如宕机导致不可用。造成系统的所有访问，都要走数据库。
还有一种缓存雪崩的场景是：有一些被大量访问数据（热点缓存）在某一时刻大面积失效，导致对应的请求直接落到了数据库上。 这样的情况，有下面几种解决办法：
举个例子 ：秒杀开始 12 个小时之前，我们统一存放了一批商品到 Redis 中，设置的缓存过期时间也是 12 个小时，那么秒杀开始的时候，这些秒杀的商品的访问直接就失效了。导致的情况就是，相应的请求直接就落到了数据库上，就像雪崩一样可怕。
7.4. 如何解决？
针对 Redis 服务不可用的情况：
采用 Redis 集群，避免单机出现问题整个缓存服务都没办法使用。
-
限流，避免同时处理大量的请求。
针对热点缓存失效的情况：
设置不同的失效时间比如随机设置缓存的失效时间。
缓存永不失效。
8.如何保证缓存和数据库的一致性？
经典的解决方式是 缓存+数据库读写的模式，就是Cache Aside Pattern。
读的时候先缓存，没缓存再读数据库，然后更新到缓存，同时返回响应。更新的时候，先更新数据库，然后再删除缓存 。
其实删除缓存，而不是更新缓存，就是一个 lazy 计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算。像 mybatis，hibernate，都有懒加载思想。查询一个部门，部门带了一个员工的 list，没有必要说每次查询部门，都里面的 1000 个员工的数据也同时查出来啊。80% 的情况，查这个部门，就只是要访问这个部门的信息就可以了。先查部门，同时要访问里面的员工，那么这个时候只有在你要访问里面的员工的时候，才会去数据库里面查询 1000 个员工。
