Redis面试那些事（30问与答）

清疚 2022-09-14 08:51 210阅读 0赞

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5LiD5ZOl6IGK57yW56iL_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]

大家好，我是七哥。

自从上次分享了小伙伴在实习和秋招期间历经几十场面试总结下来的 MySQL 面试那些事，小伙伴反响很不错，连我这平均阅读100左右的号，那篇文章也获得了将近900的阅读量，我猜应该很多小伙伴都热心转给了睡在自己上铺的兄弟。

![b83d30e5cc84d87f0b194ecf9be211b3.png][]

> 公众号：七哥聊编程。

所以今天咱继续安排，七哥苦苦滴从最近面试的小伙伴那里收集了 Redis 面试常考题（包括Oppo、字节、快手、阿里等公司），还贴心的整理了答案，快来看看你能答对几个。

## 一、基础篇 ##

### 什么是Redis ###

Redis 是一个使用 C 语言写成的，开源的高性能key-value非关系缓存数据库。它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。Redis的数据都基于缓存的，所以很快，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。Redis也可以实现数据写入磁盘中，保证了数据的安全不丢失，而且Redis的操作是原子性的。

### Redis有哪些优缺点 ###

#### 优点 ####

*  读写性能优异， Redis能读的速度是110000次/s，写的速度是81000次/s。
 *  支持数据持久化，支持AOF和RDB两种持久化方式。
 *  支持事务，Redis的所有操作都是原子性的，同时Redis还支持对几个操作合并后的原子性执行。
 *  数据结构丰富，除了支持string类型的value外还支持hash、set、zset、list等数据结构。
 *  支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

#### 缺点 ####

*  数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
 *  Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。
 *  主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。
 *  Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

### 为什么要用 Redis / 为什么要用缓存 ###

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

#### 高性能 ####

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

#### 高并发 ####

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

### 为什么要用 Redis 而不用 Map/Guava 做缓存 ###

*  缓存分为本地缓存和分布式缓存。以 Java 为例，使用自带的 map 或者 guava 实现的是本地缓存，最主要的特点是轻量以及快速，生命周期随着 jvm 的销毁而结束，并且在多实例的情况下，每个实例都需要各自保存一份缓存，缓存不具有一致性。
 *  使用 redis 或 memcached 之类的称为分布式缓存，在多实例的情况下，各实例共用一份缓存数据，缓存具有一致性。缺点是需要保持 redis 或 memcached服务的高可用，整个程序架构上较为复杂。

### Redis为什么这么快 ###

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

### Redis有哪些数据类型 ###

*  Redis主要有5种数据类型，包括String，List，Set，Zset，Hash，满足大部分的使用要求。

### Redis的应用场景 ###

*  **计数器**。可以对 String 进行自增自减运算，从而实现计数器功能。Redis 这种内存型数据库的读写性能非常高，很适合存储频繁读写的计数量。
 *  **缓存**。将热点数据放到内存中，设置内存的最大使用量以及淘汰策略来保证缓存的命中率。
 *  **会话缓存**。可以使用 Redis 来统一存储多台应用服务器的会话信息。当应用服务器不再存储用户的会话信息，也就不再具有状态，一个用户可以请求任意一个应用服务器，从而更容易实现高可用性以及可伸缩性。
 *  **全页缓存（FPC）**。除基本的会话 token之外，Redis还提供很简便的FPC平台。以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。
 *  **查找表**。例如 DNS 记录就很适合使用 Redis 进行存储。查找表和缓存类似，也是利用了 Redis 快速的查找特性。但是查找表的内容不能失效，而缓存的内容可以失效，因为缓存不作为可靠的数据来源。
 *  **消息队列(发布/订阅功能)**。List 是一个双向链表，可以通过 lpush 和 rpop 写入和读取消息。不过最好使用 Kafka、RabbitMQ 等消息中间件。
 *  **分布式锁实现**。在分布式场景下，无法使用单机环境下的锁来对多个节点上的进程进行同步。可以使用 Redis 自带的 SETNX 命令实现分布式锁，除此之外，还可以使用官方提供的 RedLock 分布式锁实现。
 *  **其它**。Set 可以实现交集、并集等操作，从而实现共同好友等功能。ZSet 可以实现有序性操作，从而实现排行榜等功能。

### Redis的持久化方式？优缺点？ ###

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

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

*  RDB是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。

![img][]

**优点**：

1.  只有一个文件 dump.rdb，方便持久化。
2.  容灾性好，一个文件可以保存到安全的磁盘。
3.  性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO 最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis 的高性能。
4.  相对于数据集大时，比 AOF 的启动效率更高。

**缺点**：

1.  数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候)
2.  AOF（Append-only file)持久化方式： 是指所有的命令行记录以 redis 命令请 求协议的格式完全持久化存储)保存为 aof 文件。

*  AOF：持久化。AOF持久化(即Append Only File持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中，当重启Redis会重新将持久化的日志中文件恢复数据。当两种方式同时开启时，数据恢复Redis会优先选择AOF恢复。

![img][img 1]

**优点**：

1.  数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次 命令操作就记录到 aof 文件中一次。
2.  通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof 工具解决数据一致性问题。
3.  AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令 进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)。

**缺点**：

1.  AOF 文件比 RDB 文件大，且恢复速度慢。
2.  数据集大的时候，比 rdb 启动效率低。

**俩种持久化的优缺点是什么？**

*  AOF文件比RDB更新频率高，优先使用AOF还原数据。
 *  AOF比RDB更安全也更大。
 *  RDB性能比AOF好。
 *  如果两个都配了优先加载AOF。

### Redis持久化数据和缓存怎么做扩容 ###

*  如果Redis被当做缓存使用，使用一致性哈希实现动态扩容缩容。
 *  如果Redis被当做一个持久化存储使用，必须使用固定的keys-to-nodes映射关系，节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况），必须使用可以在运行时进行数据再平衡的一套系统，而当前只有Redis集群可以做到这样。

### Redis的过期键的删除策略 ###

> 我们都知道，Redis是key-value数据库，我们可以设置Redis中缓存的key的过期时间。Redis的过期策略就是指当Redis中缓存的key过期了，Redis如何处理。

**过期策略通常有以下三种：**

*  **立即过期**：每个设置过期时间的key都需要创建一个定时器，到过期时间就会立即清除。该策略可以立即清除过期的数据，对内存很友好；但是会占用大量的CPU资源去处理过期的数据，从而影响缓存的响应时间和吞吐量。
 *  **惰性过期**：只有当访问一个key时，才会判断该key是否已过期，过期则清除。该策略可以最大化地节省CPU资源，却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问，从而不会被清除，占用大量内存。
 *  **定期过期**：每隔一定的时间，会扫描 expires 字典中一定数量的key，并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得CPU和内存资源达到最优的平衡效果。 (expires字典会保存所有设置了过期时间的key的过期时间数据，其中，key是指向键空间中的某个键的指针，value是该键的毫秒精度的UNIX时间戳表示的过期时间。键空间是指该Redis集群中保存的所有键。)

> Redis中同时使用了惰性过期和定期过期两种过期策略。

### Redis key的过期时间和永久有效分别怎么设置？ ###

*  expire和 persist 命令。

### MySQL里有2000w数据，Redis中只存20w的数据，如何保证Redis中的数据都是热点数据 ###

*  Redis内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。

### Redis的内存淘汰策略有哪些 ###

> Redis的内存淘汰策略是指在Redis的用于缓存的内存不足时，怎么处理需要新写入且需要申请额外空间的数据。

**全局的key选择性移除**

*  noeviction：当内存不足以容纳新写入数据时，新写入操作会报错。
 *  allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key。（这个是最常用的）
 *  allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key。

**设置过期时间的key选择性移除**

*  volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key。
 *  volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key。
 *  volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除。

> 这里Redis的内存淘汰策略的选取并不会影响过期的key的处理。内存淘汰策略是用于处理内存不足时的需要申请额外空间的数据；而过期策略用于处理过期的缓存数据。

### Redis主要消耗什么物理资源？ ###

*  内存。

### Redis的内存用完了会发生什么？ ###

*  如果达到设置的上限，Redis的写命令会返回错误信息（但是读命令还可以正常返回。）或者你可以配置内存淘汰机制，当Redis达到内存上限时会冲刷掉旧的内容。

### Redis如何做内存优化？ ###

*  可以好好利用Hash,list,sorted set,set等集合类型数据，因为通常情况下很多小的Key-Value可以用更紧凑的方式存放到一起。尽可能使用散列表（hashes），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key，而是应该把这个用户的所有信息存储到一张散列表里面。

## 二、线程模型 ##

### Redis线程模型 ###

Redis基于Reactor模式开发了网络事件处理器，这个处理器被称为文件事件处理器（file event handler）。它的组成结构为4部分：**多个套接字、IO多路复用程序、文件事件分派器、事件处理器**。因为文件事件分派器队列的消费是单线程的，所以Redis才叫单线程模型。

*  文件事件处理器使用 I/O 多路复用（multiplexing）程序来同时监听多个套接字， 并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
 *  当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时， 与操作相对应的文件事件就会产生， 这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

虽然文件事件处理器以单线程方式运行， 但通过使用 I/O 多路复用程序来监听多个套接字， 文件事件处理器既实现了高性能的网络通信模型， 又可以很好地与 redis 服务器中其他同样以单线程方式运行的模块进行对接， 这保持了 Redis 内部单线程设计的简单性。

## 三、事务 ##

### 什么是事务？ ###

*  事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
 *  事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

### Redis事务的概念 ###

*  Redis 事务的本质是通过MULTI、EXEC、WATCH等一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。
 *  总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

### Redis事务的三个阶段 ###

1.  事务开始 MULTI
2.  命令入队
3.  事务执行 EXEC

> 事务执行过程中，如果服务端收到有EXEC、DISCARD、WATCH、MULTI之外的请求，将会把请求放入队列中排队。

### Redis事务相关命令 ###

Redis事务功能是通过MULTI、EXEC、DISCARD和WATCH 四个原语实现的，Redis会将一个事务中的所有命令序列化，然后按顺序执行。

1.  **Redis 不支持回滚**，“Redis 在事务失败时不进行回滚，而是继续执行余下的命令”， 所以 Redis 的内部可以保持简单且快速。
2.  **如果在一个事务中的命令出现错误，那么所有的命令都不会执行**；
3.  **如果在一个事务中出现运行错误，那么正确的命令会被执行**。

*  WATCH 命令是一个乐观锁，可以为 Redis 事务提供 check-and-set （CAS）行为。 可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行，监控一直持续到EXEC命令。
 *  MULTI命令用于开启一个事务，它总是返回OK。 MULTI执行之后，客户端可以继续向服务器发送任意多条命令，这些命令不会立即被执行，而是被放到一个队列中，当EXEC命令被调用时，所有队列中的命令才会被执行。
 *  EXEC：执行所有事务块内的命令。返回事务块内所有命令的返回值，按命令执行的先后顺序排列。 当操作被打断时，返回空值 nil 。
 *  通过调用DISCARD，客户端可以清空事务队列，并放弃执行事务， 并且客户端会从事务状态中退出。
 *  UNWATCH命令可以取消watch对所有key的监控。

### 事务管理（ACID）概述 ###

*  原子性（Atomicity），原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。
 *  一致性（Consistency），事务前后数据的完整性必须保持一致。
 *  隔离性（Isolation），多个事务并发执行时，一个事务的执行不应影响其他事务的执行
 *  持久性（Durability），持久性是指一个事务一旦被提交，它对数据库中数据的改变就是永久性的，接下来即使数据库发生故障也不应该对其有任何影响

> Redis的事务总是具有ACID中的一致性和隔离性，其他特性是不支持的。当服务器运行在\_AOF\_持久化模式下，并且appendfsync选项的值为always时，事务也具有耐久性。

### Redis事务支持隔离性吗 ###

*  Redis 是单进程程序，并且它保证在执行事务时，不会对事务进行中断，事务可以运行直到执行完所有事务队列中的命令为止。因此，Redis 的事务是总是带有隔离性的。

### Redis事务保证原子性吗，支持回滚吗 ###

*  Redis中，单条命令是原子性执行的，但**事务不保证原子性，且没有回滚**。事务中任意命令执行失败，其余的命令仍会被执行。

### Redis事务其他实现 ###

*  基于Lua脚本，Redis可以保证脚本内的命令一次性、按顺序地执行。其同时也不提供事务运行错误的回滚，执行过程中如果部分命令运行错误，剩下的命令还是会继续运行完。
 *  基于中间标记变量，通过另外的标记变量来标识事务是否执行完成，读取数据时先读取该标记变量判断是否事务执行完成。但这样会需要额外写代码实现，比较繁琐。

## 四、集群相关 ##

### Redis哨兵机制？哨兵如何判断主挂了？ ###

**哨兵的介绍**

![f23b761be3b225a578672c34efac43f1.png][]

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

*  集群监控：负责监控 redis master 和 slave 进程是否正常工作。
 *  消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
 *  故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。
 *  配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。

**哨兵如何判断主挂了**

1.  哨兵启动后根据配置向 master 发送info指令，获取并且保存所有哨兵状态，主节点和从节点的信息；
2.  主节点 master 会记录所有 从节点和与它连接的哨兵实例的信息；
3.  哨兵会根据在主节点拿到的从节点信息，给对应的从节点建立连接后发送info指令；
4.  接着哨兵2来了，同样的也会给主节点发送 info 指令，同时拿到了从节点和哨兵的实例信息；
5.  此时哨兵2也会保存跟哨兵1一样的信息，只不过它保存的哨兵信息是2个；
6.  这个时候为了每个哨兵的信息都一致它们之间建立了一个发布订阅，互相发送 ping 命令 保证信息长期对称；
7.  当再来一个哨兵3时，也会做同样的事情，给主节点和从节点发送info，并且跟哨兵1和哨兵2建立连接；

### 官方Redis Cluster 方案 ###

**架构图**

![7f309238755c8c1c42c6da025860a9d0.png][]

**架构细节**

1.  图中描述的是六个redis实例构成的集群，6379端口为客户端通讯端口，16379端口为集群总线端口
2.  集群内部划分为16384个数据分槽，分布在三个主redis中。
3.  从redis中没有分槽，不会参与集群投票，也不会帮忙加快读取数据，仅仅作为主机的备份。
4.  三个主节点中平均分布着16384数据分槽的三分之一，每个节点中不会存有有重复数据，仅仅有自己的从机帮忙冗余。
5.  所有的redis主节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
6.  客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
7.  节点的fail是通过集群中超过半数的节点检测失效时才生效。

**操作原理演示**

![49f3fc2188c02967000e63bb416e03fa.png][]

Redis 集群中内置了 16384个哈希槽，当需要在 Redis 集群中放置一个 key-value 时，redis 先对 key使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。

**优点**

*  无中心架构，支持动态扩容，对业务透明
 *  具备Sentinel的监控和自动Failover(故障转移)能力
 *  客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
 *  高性能，客户端直连redis服务，免去了proxy代理的损耗

**缺点**

*  运维也很复杂，数据迁移需要人工干预
 *  只能使用0号数据库
 *  不支持批量操作(pipeline管道操作)
 *  分布式逻辑和存储模块耦合等

### Redis 主从架构 ###

*  单机的 redis，能够承载的 QPS 大概就在上万到几万不等。对于缓存来说，一般都是用来支撑**读高并发**的。因此架构做成主从(master-slave)架构，一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的**读请求全部走从节点**。这样也可以很轻松实现水平扩容，**支撑读高并发**。

![a4b08e28468916e598d4d55793e9347a.png][]

**Redis 主从复制的核心原理**

*  当启动一个 slave node 的时候，它会发送一个 `PSYNC` 命令给 master node。
 *  如果这是 slave node 初次连接到 master node，那么会触发一次 `full resynchronization` 全量复制。此时 master 会启动一个后台线程，开始生成一份 `RDB` 快照文件，
 *  同时还会将从客户端 client 新收到的所有写命令缓存在内存中。`RDB` 文件生成完毕后， master 会将这个 `RDB` 发送给 slave，slave 会先**写入本地磁盘，然后再从本地磁盘加载到内存**中，
 *  接着 master 会将内存中缓存的写命令发送到 slave，slave 也会同步这些数据。
 *  slave node 如果跟 master node 有网络故障，断开了连接，会自动重连，连接之后 master node 仅会复制给 slave 部分缺少的数据。

![5e44317cfc223fb4b365fd9c12560f19.png][]

**缺点**

所有的slave节点数据的复制和同步都由master节点来处理，会照成master节点压力太大，使用主从从结构来解决

### Redis集群的主从复制模型是怎样的？ ###

为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型，每个节点都会有N-1个复制品。

### 说说Redis哈希槽的概念？ ###

Redis集群没有使用一致性hash,而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

### Redis集群会有写操作丢失吗？为什么？ ###

Redis并不能保证数据的强一致性，这意味这在实际中集群在特定的条件下可能会丢失写操作。

### Redis集群之间是如何复制的？ ###

采用异步复制。

![img][]

### Redis集群最大节点个数是多少？ ###

16384个。

### Redis集群如何选择数据库？ ###

Redis集群目前无法做数据库选择，默认在0数据库。

## 五、分区 ##

### Redis是单线程的，如何提高多核CPU的利用率？ ###

可以在同一个服务器部署多个Redis的实例，并把他们当作不同的服务器来使用，在某些时候，无论如何一个服务器是不够的， 所以，如果你想使用多个CPU，你可以考虑一下分片（shard）。

### 为什么要做Redis分区？ ###

分区可以让Redis管理更大的内存，Redis将可以使用所有机器的内存。如果没有分区，你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升，Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。

### 你知道有哪些Redis分区实现方案？ ###

*  客户端分区就是在客户端就已经决定数据会被存储到哪个redis节点或者从哪个redis节点读取。大多数客户端已经实现了客户端分区。
 *  代理分区 意味着客户端将请求发送给代理，然后代理决定去哪个节点写数据或者读数据。代理根据分区规则决定请求哪些Redis实例，然后根据Redis的响应结果返回给客户端。redis和memcached的一种代理实现就是Twemproxy。
 *  查询路由(Query routing) 的意思是客户端随机地请求任意一个Redis实例，然后由Redis将请求转发给正确的Redis节点。Redis Cluster实现了一种混合形式的查询路由，但并不是直接将请求从一个Redis节点转发到另一个Redis节点，而是在客户端的帮助下直接redirected到正确的Redis节点。

### Redis分区有什么缺点？ ###

*  涉及多个key的操作通常不会被支持。例如你不能对两个集合求交集，因为他们可能被存储到不同的Redis实例（实际上这种情况也有办法，但是不能直接使用交集指令）。
 *  同时操作多个key,则不能使用Redis事务。
 *  分区使用的粒度是key，不能使用一个非常长的排序key存储一个数据集。
 *  当使用分区的时候，数据处理会非常复杂，例如为了备份你必须从不同的Redis实例和主机同时收集RDB / AOF文件。
 *  分区时动态扩容或缩容可能非常复杂。Redis集群在运行时增加或者删除Redis节点，能做到最大程度对用户透明地数据再平衡，但其他一些客户端分区或者代理分区方法则不支持这种特性。然而，有一种预分片的技术也可以较好的解决这个问题。

## 六、分布式问题 ##

### Redis实现分布式锁 ###

*  Redis为单进程单线程模式，采用队列模式将并发访问变成串行访问，且多客户端对Redis的连接并不存在竞争关系Redis中可以使用setNx命令实现分布式锁。
 *  当且仅当 key 不存在，将 key 的值设为 value。 若给定的 key 已经存在，则 setNx不做任何动作
 *  SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写。
 *  返回值：设置成功，返回 1 。设置失败，返回 0 。

![484b1f4994dc48972c09e817a2b75f07.png][]

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

*  使用SETNX命令获取锁，若返回0（key已存在，锁已存在）则获取失败，反之获取成功;
 *  为了防止获取锁后程序出现异常，导致其他线程/进程调用setNx命令总是返回0而进入死锁状态，需要为该key设置一个“合理”的过期时间释放锁，使用DEL命令将锁数据删除;

### 如何解决 Redis 的并发竞争 Key 问题 ###

所谓 Redis 的并发竞争 Key 的问题也就是多个系统同时对一个 key 进行操作，但是最后执行的顺序和我们期望的顺序不同，这样也就导致了结果的不同！

推荐一种方案：分布式锁（zookeeper 和 redis 都可以实现分布式锁）。（如果不存在 Redis 的并发竞争 Key 问题，不要使用分布式锁，这样会影响性能）

基于zookeeper临时有序节点可以实现的分布式锁。大致思想为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。完成业务流程后，删除对应的子节点释放锁。

**在实践中，当然是从以可靠性为主。所以首推Zookeeper。**

### 分布式Redis是前期做还是后期规模上来了再做好？为什么？ ###

*  既然Redis是如此的轻量（单实例只使用1M内存），为防止以后的扩容，最好的办法就是一开始就启动较多实例。即便你只有一台服务器，你也可以一开始就让Redis以分布式的方式运行，使用分区，在同一台服务器上启动多个实例。
 *  一开始就多设置几个Redis实例，例如32或者64个实例，对大多数用户来说这操作起来可能比较麻烦，但是从长久来看做这点牺牲是值得的。
 *  这样的话，当你的数据不断增长，需要更多的Redis服务器时，你需要做的就是仅仅将Redis实例从一台服务迁移到另外一台服务器而已（而不用考虑重新分区的问题）。一旦你添加了另一台服务器，你需要将你一半的Redis实例从第一台机器迁移到第二台机器。

### 什么是 RedLock ###

Redis 官方站提出了一种权威的基于 Redis 实现分布式锁的方式名叫Redlock。此种方式比原先的单节点的方法更安全。它可以保证以下特性：

*  安全特性：互斥访问，即永远只有一个 client 能拿到锁；
 *  避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了或者出现了网络分区；
 *  容错性：只要大部分 Redis 节点存活就可以正常提供服务；

## 七、缓存异常 ##

#### 什么是Redis穿透？ ####

一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如MySQL）。如果key对应的value是一定不存在的，并且对该key并发请求量很大，就会对后端系统造成很大的压力。

**也就是说，对不存在的key进行高并发访问，导致数据库压力瞬间增大，这就叫做【缓存穿透】。**

**解决方案：**

*  对查询结果为空的情况也进行缓存，缓存时间设置短一点。
 *  该key对应的数据 insert 了之后清理缓存。
 *  采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力。

#### 什么是Redis雪崩？ ####

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

**突然间大量的key失效了或Redis重启，大量访问数据库而导致的系统压力剧增问题就是缓存雪崩啦。**

**解决方案:**

1.  key的失效期分散开，不同的key设置不同的有效期；
2.  设置二级缓存；
3.  高可用方案，比如Redis集群，保证不会因为缓存系统崩溃而导致缓存雪崩；

### 什么是Redis缓存击穿？ ###

对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。

缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

**解决方案：**

1.  用分布式锁控制访问的线程，如：使用redis的setnx互斥锁先进行判断，这样其他线程就处于等待状态，保证不会有大并发操作去操作数据库。

if(redis.sexnx()==1){ 
    	//先查询缓存 
    	//查询数据库 
    	//加入缓存 
    }

### 缓存预热 ###

缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

**解决方案**

1.  直接写个缓存刷新页面，上线时手工操作一下；
2.  数据量不大，可以在项目启动的时候自动进行加载；
3.  定时刷新缓存；

### 缓存降级 ###

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

**缓存降级**的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

*  info：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
 *  warning：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
 *  error：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
 *  fatal：比如因为特殊原因数据错误了，此时需要紧急人工降级。

服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是，Redis出现问题，不去数据库查询，而是直接返回默认值给用户。

### 热点数据和冷数据 ###

**热点数据，缓存才有价值。**

*  对于冷数据而言，大部分数据可能还没有再次访问到就已经被挤出内存，不仅占用内存，而且价值不大。频繁修改的数据，看情况考虑使用缓存。
 *  对于热点数据，比如我们的某IM产品，生日祝福模块，当天的寿星列表，缓存以后可能读取数十万次。再举个例子，某导航产品，我们将导航信息，缓存以后可能读取数百万次。
 *  数据更新前至少读取两次，缓存才有意义。这个是最基本的策略，如果缓存还没有起作用就失效了，那就没有太大价值了。
 *  那存不存在，修改频率很高，但是又不得不考虑缓存的场景呢？有！比如，这个读取接口对数据库的压力很大，但是又是热点数据，这个时候就需要考虑通过缓存手段，减少数据库的压力，比如我们的微信公众号助手，点赞数，收藏数，分享数等是非常典型的热点数据，但是又不断变化，此时就需要将数据同步保存到Redis缓存，减少数据库压力。

## 八、常用工具 ##

### Redis支持的Java客户端都有哪些？官方推荐用哪个？ ###

Redisson、Jedis、lettuce等等，官方推荐使用Redisson。

### Redis和Redisson有什么关系？ ###

Redisson是一个高级的分布式协调Redis客服端，能帮助用户在分布式环境中轻松实现一些Java的对象。

### Jedis与Redisson对比有什么优缺点？ ###

Jedis是Redis的Java实现的客户端，其API提供了比较全面的Redis命令的支持；Redisson实现了分布式和可扩展的Java数据结构，和Jedis相比，功能较为简单，不支持字符串操作，不支持排序、事务、管道、分区等Redis特性。Redisson的宗旨是促进使用者对Redis的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上。

## 九、其他问题 ##

### Redis与Memcached的区别 ###

两者都是非关系型内存键值数据库，现在公司一般都是用 Redis 来实现缓存，而且 Redis 自身也越来越强大了！Redis 与 Memcached 主要有以下不同：

1.  Memcached所有的值均是简单的字符串，Redis作为其替代者，支持更为丰富的数据类型；
2.  Redis可以将长时间不用的key落盘，Memcached的数据则会一直在内存中，所以不适合存储大量数据；
3.  Redis可以持久化其数据；

### 如何保证缓存与数据库双写时的数据一致性？ ###

你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？

一般来说，就是如果你的系统不是严格要求缓存+数据库必须一致性的话，缓存可以稍微的跟数据库偶尔有不一致的情况，最好不要做这个方案，读请求和写请求串行化，串到一个内存队列里去，这样就可以保证一定不会出现不一致的情况

串行化之后，就会导致系统的吞吐量会大幅度的降低，用比正常情况下多几倍的机器去支撑线上的一个请求。

先来看下我们日常的这些操作是如何造成双鞋数据不一致的吧：

1.  **先更新数据库再更新缓存(不建议使用)；**

**操作步骤**（线程A和线程B都对同一数据进行更新操作）：

> 1.  线程A更新了数据库
> 2.  线程B更新了数据库
> 3.  线程B更新了缓存
> 4.  线程A更新了缓存

显而易见，这面这种操作的问题在于：**脏读、浪费性能**

1.  **先更新数据库再删除缓存（推荐）；**

**操作步骤：**

> 1.  请求A进行写操作，删除缓存，此时A的还没有删除缓存
> 2.  请求B查询到缓存中的旧值后返回
> 3.  请求A将缓存删除成功
> 4.  请求C发现缓存为空去读取数据库中正确的值
> 5.  请求C根据数据到缓存

此方案，可以看到在步骤2会将旧值读取到，最终造成脏读，这种方案暂时产生不一致的情况，但是发生的几率特别小。

1.  **先删除缓存再更新数据库**

操作步骤：

> 1.  用户A删除缓存失败
> 2.  用户A成功更新了数据

或者：

> 1.  用户A删除了缓存；
> 2.  用户B读取缓存，缓存不存在；
> 3.  用户B从数据库拿到旧数据；
> 4.  用户B更新了缓存；
> 5.  用户A更新了数据库;

按照上面的步骤，此方案也是会出现脏读问题，导致数据双写不一致而引发业务系统异常。

**这里给出几种解决方案：**

*  解决方案1：设置缓存有效时间（最简单），在接受最终一致性的场景下，配置合理的失效时间。
 *  解决方案2：使用消息队列，例如rocketMq等消息队列可以保证数据操作顺序一致性，确保缓存系统的数据正常。

### Redis官方为什么不提供Windows版本？ ###

因为目前Linux版本已经相当稳定，而且用户量很大，无需开发windows版本，反而会带来兼容性等问题。

### 一个字符串类型的值能存储最大容量是多少？ ###

512M。

### Redis回收使用的是什么算法？ ###

LRU算法。

### 假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？ ###

使用keys指令可以扫出指定模式的key列表。

对方接着追问：如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？

这个时候你要回答Redis关键的一个特性：**Redis的单线程的**。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

### 使用Redis做过异步队列吗，是如何实现的 ###

使用list类型保存数据信息，rpush生产消息，lpop消费消息，当lpop没有消息时，可以sleep一段时间，然后再检查有没有信息，如果不想sleep的话，可以使用blpop, 在没有信息的时候，会一直阻塞，直到信息的到来。redis可以通过pub/sub主题订阅模式实现一个生产者，多个消费者，当然也存在一定的缺点，当消费者下线时，生产的消息会丢失。

### Redis如何实现延时队列 ###

使用 sortedset，使用时间戳做score, 消息内容作为key,调用zadd来生产消息，消费者使用zrangbyscore获取n秒之前的数据做轮询处理。

--------------------

好了，上面的问题都过一遍，应付面试中 Redis 相关的问题基本上就稳了。

关注公众号：七哥聊编程，我们一起探讨，帮助修改简历、回答疑问、项目分析，只为帮助迷茫的你高效斩获心仪的 offer。

另外技术 **读者群** 也开通了，公众号添加七哥个人微信回复：**进群**，一起成长交流。群里有腾讯、字节等大厂的大佬，也有在校学习的大学生，可以内推哦 ~

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5LiD5ZOl6IGK57yW56iL_size_20_color_FFFFFF_t_70_g_se_x_16_pic_center]: /images/20220828/9d1074adc3f540cdab03e2b4a765abb0.png
[b83d30e5cc84d87f0b194ecf9be211b3.png]: /images/20220828/a3d4622f9559486e84f36f955a80ca32.png
[img]: /images/20220828/cdf71d7a21114cf6bb00870b29b6a2e3.png
[img 1]: /images/20220828/f4779ed493714356b1a8c62a55cc9b9c.png
[f23b761be3b225a578672c34efac43f1.png]: /images/20220828/4c6780beed844615989d86160422d743.png
[7f309238755c8c1c42c6da025860a9d0.png]: /images/20220828/550c2a3da68d42228fe815f9abd8add5.png
[49f3fc2188c02967000e63bb416e03fa.png]: /images/20220828/505c8a13573f4093988db9bff553a21b.png
[a4b08e28468916e598d4d55793e9347a.png]: /images/20220828/ebf65eaa4ca64ee58d0ba2ba2e4ea873.png
[5e44317cfc223fb4b365fd9c12560f19.png]: /images/20220828/4dab616eb3134987a8c453adc6228c6c.png
[484b1f4994dc48972c09e817a2b75f07.png]: /images/20220828/bca9da6f18a94699b7b7f9141bc919fa.png