文章目录：

1.什么是Redis？

2.为什么要用 Redis / 为什么要用缓存？

3.Redis为什么这么快？

4.Redis都有哪些数据类型？

5.什么是Redis持久化？Redis 的持久化有哪些实现方式？

6.什么是Redis事务？

7.谈谈你对Redis集群方案——哨兵模式 的理解

8.Redis主从复制的原理是什么？

9.Redis如何实现分布式锁？

10.Redis中的缓存穿透、缓存击穿、缓存雪崩是什么？

1.什么是Redis？

Redis(Remote Dictionary Server) 是一个使用 C 语言编写的，开源的（BSD许可）高性能非关系型（NoSQL）的键值对数据库。

Redis 可以存储键和五种不同类型的值之间的映射。键的类型只能为字符串，值支持五种数据类型：字符串、列表、散列表、集合、有序集合。

与传统数据库不同的是 Redis 的数据是存在内存中的，所以读写速度非常快，因此 redis 被广泛应用于缓存方向，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。另外，Redis 也经常用来做分布式锁。除此之外，Redis 支持事务 、持久化、LUA脚本、LRU驱动事件、多种集群方案。

2.为什么要用 Redis / 为什么要用缓存？

主要从“高性能”和“高并发”这两点来看待这个问题。

高性能

假如用户第一次访问数据库中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。再将该用户访问的数据存在缓存中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。如果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！

高并发

直接操作缓存能够承受的请求是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。

3.Redis为什么这么快？

1. 完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是O(1)；
2. 数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的；
3. 采用单线程，避免了不必要的上下文切换和竞争，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；
4. 使用 I/O 多路复用模型，非阻塞 IO；

4.Redis都有哪些数据类型？

Redis主要有5种数据类型，包括String，List，Hash，Set，ZSet。

5.什么是Redis持久化？Redis 的持久化有哪些实现方式？

持久化就是把内存的数据写到磁盘中去，防止服务宕机了内存数据丢失。

Redis 提供两种持久化机制 RDB（默认） 和 AOF 机制：

RDB持久化：是Redis DataBase缩写，快照

RDB是Redis默认的持久化方式。在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。

如何触发RDB快照；保持策略。

配置文件中默认的快照配置，这三行save代码的意思是：

在3600秒（一个小时）内，如果有1个数据发生改变，则进行持久化。

在30秒内，如果有10个数据发生改变，则进行持久化。（原先是 save 300 100），我为了后面测试RDB，这里进行了修改。

在60秒内，如果有10000个数据发生改变，则进行持久化。

工作流程

1. redis根据配置尝试去生成rdb快照文件

2. redis主进程fork一个子进程出来

3. 子进程尝试将内存中的数据dump到临时的rdb快照文件中

4. 完成rdb快照文件的生成之后，覆盖旧的快照文件

优点

1. 只有一个文件 dump.rdb，方便持久化，容灾性好。

2. 性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，保证了 redis 的高性能

3. 数据集大时，比 AOF 的启动效率更高。

缺点

1. 数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。

AOF持久化：Append Only File缩写

将Redis执行的每条写命令记录到单独的aof日志文件中，当重启Redis服务时，会从持久化的日志文件中恢复数据。

当两种方式同时开启时，数据恢复时，Redis会优先选择AOF恢复。

配置

# 表示是否开启AOF持久化(默认no,关闭)
appendonly yes

工作流程

1. 所有的写入命令会追加到AOF缓冲区中。

2. AOF缓冲区根据对应的策略向硬盘做同步操作。

3. 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。

4. 当Redis服务器重启时，可以加载AOF文件进行数据恢复。

优点

1. 数据安全，可以配置每进行一次命令操作就记录到 aof 文件中一次。

2. 通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。

缺点

1. AOF 文件比 RDB 文件大，且恢复速度慢。

2. 数据集大时，比 rdb 启动效率低。

6.什么是Redis事务？

事务是逻辑上的一组操作，要么都执行，要么都不执行。Redis 事务不是严格意义上的事务，只是用于帮助用户在一个步骤中执行多个命令。单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不是原子性的。

Redis 事务可以理解为一个打包的批量执行脚本，redis 事务不保证原子性，且没有回滚，中间某条命令执行失败，前面已执行的命令不回滚，后续的指令继续执行。

Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：

• 批量操作在发送 EXEC 命令前被放入队列缓存。

• 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，前面已执行的命令不回滚，后续的命令继续执行。

• 事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

Redis事务的三个阶段

1. 事务开始 MULTI

2. 命令入队

3. 事务执行 EXEC

Redis事务的相关命令：

7.谈谈你对Redis集群方案——哨兵模式 的理解

哨兵的介绍

sentinel，中文名是哨兵。哨兵是 redis 集群机构中非常重要的一个组件，主要有以下功能：

• 集群监控：负责监控 redis master 和 slave 进程是否正常工作。

• 消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。

• 故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。

• 配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

哨兵用于实现 redis 集群的高可用，本身也是分布式的，作为一个哨兵集群去运行，互相协同工作。

8.Redis主从复制的原理是什么？

1. 从节点执行 slaveof 命令

2. 从节点只是保存了 slaveof 命令中主节点的信息，并没有立即发起复制

3. 从节点内部的定时任务发现有主节点的信息，开始使用 socket 连接主节点

4. 连接建立成功后，发送 ping 命令，希望得到 pong 命令响应，否则会进行重连

5. 如果主节点设置了权限，那么就需要进行权限验证；如果验证失败，复制终止。

6. 权限验证通过后，进行数据同步，这是耗时最长的操作，主节点将把所有的数据全部发送给从节点。

7. 当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来，主节点就会持续的把写命令发送给从节点，保证主从数据一致性。

9.Redis如何实现分布式锁？

Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系，Redis中可以使用SETNX命令实现分布式锁。

SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。

当且仅当 key 不存在，将 key 的值设为 value。若给定的 key 已经存在，则 SETNX 不做任何动作

返回值：设置成功，返回 1 。设置失败，返回 0 。

使用SETNX完成同步锁的流程及事项如下：

• 使用SETNX命令获取锁，若返回0（key已存在，锁已存在）则获取失败，若返回1则获取成功

• 为了防止获取锁后程序出现异常，导致其他线程/进程调用SETNX命令总是返回0而进入死锁状态，需要为该key设置一个合理的过期时间

• 释放锁，使用DEL命令将锁数据删除

10.Redis中的缓存穿透、缓存击穿、缓存雪崩是什么？

缓存穿透：

当我们访问某个key时，这个key对应的数据在数据源并不存在，每次针对这个key的请求从缓存中都获取不到，那么这些请求都会压到数据源（DB），从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

解决方案：

• 对空值缓存：如果一个查询返回的数据为空（不管是数据是否不存在），我们仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。
• 设置可访问的名单（白名单）：使用bitmaps类型定义一个可以访问的名单，名单id作为bitmaps的偏移量，每次访问和bitmap里面的id进行比较，如果访问id不在bitmaps里面，进行拦截，不允许访问。
• 采用布隆过滤器：将所有可能存在的数据哈希到一个足够大的bitmaps中，一个一定不存在的数据会被 这个bitmaps拦截掉，从而避免了对底层存储系统的查询压力。

缓存击穿：

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案：

• 预先设置热门数据：在redis高峰访问之前，把一些热门数据提前存入到redis里面，加大这些热门数据key的存活时长，避免在高并发期间这些数据过期。
• 实时调整：现场监控哪些数据热门，实时调整key的过期时长。
• 使用锁

缓存雪崩：

当我们访问多个key对应的数据时，这些key在redis中都过期（无法获取）了，那么这些大量的高并发请求就会转到后端DB中去查找访问，进而造成了数据库的崩溃现象。缓存雪崩与缓存击穿的区别在于：缓存雪崩是针对很多key而言的缓存，而缓存击穿则是针对某一个key。

解决方案：

• 构建多级缓存架构：nginx缓存 + redis缓存 +其他缓存（ehcache等）。
• 使用锁或队列：用加锁或者队列的方式保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况。
• 设置过期标志更新缓存：记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际key的缓存。
• 将缓存失效时间分散开：比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。