Redis 篇

ww_kobe

已于 2023-10-24 07:19:05 修改

阅读量291

点赞数

分类专栏： Java 面经文章标签： redis 数据库缓存 1024程序员节

于 2023-09-18 06:00:18 首次发布

本文链接：https://blog.csdn.net/ww_kobe/article/details/132962403

版权

Java 面经专栏收录该内容

9 篇文章 0 订阅

订阅专栏

1、为什么要用缓存？

使用缓存的目的就是提升读写性能。而实际业务场景下，更多的是为了提升读性能，带来更好的性能，带来更高的并发量。 Redis 的读写性能比 Mysql 好的多，我们就可以把 Mysql 中的热点数据缓存到 Redis 中，提升读取性能，同时也减轻了 Mysql 的读取压力。

2、什么是 Redis？

Redis 是一个开源（BSD 许可）、基于内存、支持多种数据结构的存储系统，可以作为数据库、缓存和消息中间件。它支持的数据结构有字符串（strings）、哈希（hashes）、列表（lists）、集合（sets）、有序集合（sorted sets）等，除此之外还支持 bitmaps、hyperloglogs 和地理空间（geospatial ）索引半径查询等功能。
它内置了复制（Replication）、LUA 脚本（Lua scripting）、LRU 驱动事件（LRU eviction）、事务（Transactions）和不同级别的磁盘持久化（persistence）功能，并通过 Redis 哨兵（哨兵）和集群（Cluster）保证缓存的高可用性（High availability）。

3、说说 Redis 优缺点

优点：

速度快：因为数据存在内存中，类似于 HashMap ， HashMap 的优势就是查找和操作的时间复杂度都是O (1)。
支持多种数据结构：包括字符串、列表、集合、有序集合、哈希等。
支持事务：操作遵守原子性，即对数据的操作要么都执行，要么都不支持。
持久化存储：Redis 提供 RDB 和 AOF 两种数据的持久化存储方案，解决内存数据库最担心的
万一 Redis 挂掉，数据会消失掉。
高可用：内置 Redis Sentinel ，提供高可用方案，实现主从故障自动转移。内置 Redis
Cluster ，提供集群方案，实现基于槽的分片方案，从而支持更大的 Redis 规模。
还拥有其他丰富的功能：key 过期、计数、分布式锁、消息队列等。

缺点：

由于 Redis 是内存数据库，所以，单台机器，存储的数据量，跟机器本身的内存大小。虽然Redis 本身有 Key 过期策略，但是还是需要提前预估和节约内存。如果内存增长过快，需要定期删除数据。
如果进行完整重同步，由于需要生成 RDB 文件，并进行传输，会占用主机的 CPU ，并会消耗现网的带宽。不过 Redis 2.8 版本，已经有部分重同步的功能，但是还是有可能有完整重同步的。比如，新上线的备机。
修改配置文件，进行重启，将硬盘中的数据加载进内存，时间比较久。在这个过程中， Redis不能提供服务。

4、Redis 效率为什么那么高？

C语言实现，效率高。
纯内存操作。
基于非阻塞的IO复用模型机制。
基于单线程的能避免多线程的频繁上下文切换问题。
丰富的数据结构（全称采用hash结构，读取速度非常快，对数据存储进行了一些优化，比如亚索表，跳表等）。

5、说说 Redis 的线程模型

Redis 内部使用文件事件处理器 file event handler ，这个文件事件处理器是单线程的，所以 Redis 才叫做单线程的模型。它采用 IO 多路复用机制同时监听多个 socket ，根据 socket 上的事件来选择对应的事件处理器进行处理。

文件事件处理器的结构包含 4 个部分：

多个 socket 。
IO 多路复用程序。
文件事件分派器。
事件处理器（连接应答处理器、命令请求处理器、命令回复处理器）。

多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用程序会
监听多个 socket，会将 socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事
件，把该事件交给对应的事件处理器进行处理。

客户端与 Redis 的一次通信过程：

客户端 Socket01 向 Redis 的 Server Socket 请求建立连接，此时 Server Socket 会产生一个AE_READABLE 事件，IO 多路复用程序监听到 server socket 产生的事件后，将该事件压入队列中。文件事件分派器从队列中获取该事件，交给连接应答处理器。连接应答处理器会创建一个能与客户端通信的 Socket01，并将该 Socket01 的 AE_READABLE 事件与命令请求处理器关联。
假设此时客户端发送了一个 set key value 请求，此时 Redis 中的 Socket01 会产生AE_READABLE 事件，IO 多路复用程序将事件压入队列，此时事件分派器从队列中获取到该事件，由于前面 Socket01 的 AE_READABLE 事件已经与命令请求处理器关联，因此事件分派器将事件交给命令请求处理器来处理。命令请求处理器读取 Socket01 的 set key value 并在自己内存中完成 set key value 的设置。操作完成后，它会将 Socket01 的 AE_WRITABLE 事件与令回复处理器关联。
如果此时客户端准备好接收返回结果了，那么 Redis 中的 Socket01 会产生一个AE_WRITABLE 事件，同样压入队列中，事件分派器找到相关联的命令回复处理器，由命令回复处理器对 Socket01 输入本次操作的一个结果，比如 ok ，之后解除 Socket01 的AE_WRITABLE 事件与命令回复处理器的关联。

6、Redis 为什么设计成单线程的？

官方FAQ表示，因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了，毕竟采用多线程会有很多麻烦，如多线程的上下文切换和竞争。

7、为什么 Redis 需要把所有数据放到内存中？

Redis 将数据放在内存中有一个好处，那就是可以实现最快的对数据读取，如果数据存储在硬盘中，磁盘 I/O 会严重影响 Redis 的性能。而且 Redis 还提供了数据持久化功能，不用担心服务器重启对内存中数据的影响。其次现在硬件越来越便宜的情况下，Redis 的使用也被应用得越来越多，使得它拥有很大的优势。

8、Redis 为什么要用 pipeline？

使用 pipeline（管道）的好处在于可以将多次 I/O 往返的时间缩短为一次，但是要求管道中执行的指令间没有因果关系。
用 pipeline 的原因在于可以实现请求/响应服务器的功能，当客户端尚未读取旧响应时，它也可以处理新的请求。如果客户端存在多个命令发送到服务器时，那么客户端无需等待服务端的每次响应才能执行下个命令，只需最后一步从服务端读取回复即可。

9、Redis 的同步机制是什么？

Redis 支持主从同步、从从同步。如果是第一次进行主从同步，主节点需要使用 bgsave 命令，再将后续修改操作记录到内存的缓冲区，等 RDB 文件全部同步到复制节点，复制节点接受完成后将 RDB 镜像记载到内存中。等加载完成后，复制节点通知主节点将复制期间修改的操作记录同步到复制节点，即可完成同步过程。

10、Redis 与 Memcache 的区别

Redis和Memcache都是成熟的开源的内存数据库，Memcache远在2003年就开发完成，而稍显年轻的Redis则是在2009年面世。两者各有千秋，但是Redis在如今已成为互联网环境下的首选。

支持的数据类型不同：Redis支持近十种数据类型，比如：String/Hash/List/Set/ZSet/BiiMap/GEO等，而Memcache仅支持简单的K-V结构的数据类型。
单个Value大小不同：Redis 的单个value最大 512m，而Memcache 的单个value最大 1m。
持久化方式不同：Redis支持多种持久化，比如RDB/AOF及Redis 4.0推出的混合持久化，而Memcache不支持持久化。
数据分片方式不同：Redis使用哈希槽进行数据分片，而Memcache一般是客户端采用一致性哈希算法向指定节点发送数据。
内存管理方式不同：Redis比Memcache内存管理更加复杂，支持更多的内存优化策略。
线程模型不同：Redis使用单线程模型，而Memcache使用多线程模型。

11、Redis 缓存刷新策略有哪些？

12、Redis 的过期策略以及内存淘汰机制

过期策略：redis采用的是定期删除+惰性删除策略。为什么不用定时删除策略？定时删除，用一个定时器来负责监视key，过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key，因此没有采用这一策略.。

定期删除+惰性删除是如何工作的呢?

定期删除，redis默认每个100ms检查，是否有过期的key，有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms，全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。采用定期删除+惰性删除就没其他问题了么？不是的，如果定期删除没删除key。然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。

内存淘汰机制： 在redis.conf中有一行配置，该配置就是配内存淘汰策略的。

maxmemory-policy volatile-lru

volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰。
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰。
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰。
allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰。
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰。
no-enviction（驱逐）：禁止驱逐数据，新写入操作会报错。

注意：如果没有设置 expire 的key, 不满足先决条件(prerequisites); 那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

13、说说 Redis 持久化机制

为防止数据丢失以及服务器重启时能够恢复数据，Redis支持三种持久化机制，分别是RDB、AOF以及Redis 4.0提供的混合持久化机制。

RDB

RDB持久化是把当前Redis的数据生成快照保存到磁盘上的过程，在默认情况下，Redis将快照保存在名为dump.rdb的二进制文件中。

触发RDB持久化的方式有2种：分别是手动触发和自动触发。

手动触发：Redis客户端执行save或者bgsave命令。

save命令：阻塞当前Redis服务器，知道RDB完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。
bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只会发生在fork阶段，一般时间很短。

自动触发：以下四种情况会自动触发RDB持久化。

redis.conf中配置save m n，即在m秒内有n次修改时，自动触发bgsave生成rdb文件。
主从复制时，从节点要从主节点进行全量复制时也会触发bgsave操作，生成当时的快照发送到从节点。
执行debug reload命令重新加载Redis时也会触发bgsave操作。
默认情况下执行shutdown命令时，如果没有开启AOF持久化，那么也会触发bgsave操作。

bgsvae命令执行流程：

Redis客户端执行bgsave命令或者自动触发bgsave命令。
主进程判断是否已经存在正在执行的子进程，如果存在，那么主进程直接返回，如果不存在，那么就会fork一个新的子进程进行持久化数据，fork过程是阻塞的，fork操作完成后主进程即可执行其它操作。
子进程先将数据写入到临时的rdb文件中，待快照数据写入完成后在原子替换旧的rdb文件。

优缺点：

优点：快照文件小，恢复速度快，适合做备份和灾难恢复。

缺点：可能丢失数据，文件可读性差。

AOF(Append-only file)

针对RDB不适合实时持久化的问题，Redis 1.1版本又提供了AOF的持久化方式。AOF日志采用先写后日志，即先内存，后写日志。而Mysql数据则是采用WAL机制，即先日志后写内存。

AOF日志记录Redis的每个写命令，步骤分为：命令追加（append）、文件写入（write）和文件同步（sync）。

命令追加：AOF持久化功能开启后，服务器没执行完一个写命令，都会以RESP协议格式将被执行的写命令追加到服务器的aof_buf缓冲区。

文件写入和同步：关于何时将aof_buf缓冲区的内容写入AOF文件中，Redis提供了三种写回策略。

// 每次有新命令追加到AOF文件时就执行一次fsync，非常慢，也非常安全。
appendfsync always

// 没秒 fsync一次，足够快，并且在故障时只会丢失1秒的数据
appendfsync everysec

// 从不fsync，将数据交给操作系统来处理。更快，也更不安全的选择。
appendfsync no

推荐（并且也是默认）的措施为每秒fsync一次，这种fsync策略可以兼顾速度与安全性。

默认情况下，Redis是没有开启AOF的，可以通过配置redis.conf文件来开启AOF持久化。

appendonly yes

优缺点

优点：数据可靠性更高，数据恢复的粒度更细。适合数据存档和数据备份。

缺点：文件大、恢复速度慢。

生产环境RDB和AOF可以都启用，Redis启动时如果既有rdb文件又有aof文件，则优先选择aof文件恢复数据，因为aof一般来说数据更全一点。

混合持久化

综合RDB和AOF两种持久化的优点，Redis 4.0引入混合持久化机制。通过如下配置可以开启混合持久化（必须先开启aof）

aof-use-rdb-preamble yes

如果开启了混合持久化，AOF在重写时，将重写这一刻之前的数据做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令都写入AOF文件。这样Redis重启的时候，可以先加载RDB内容，然后再重放增量AOF日志，重启效率大幅提升，同时也降低了数据丢失的风险。但是，混合持久化模式也使得AOF文件的可读性变得很差，而且也是不能向下兼容的。

bgsave的写时复制机制（COW）

Redis借助操作系统提供的写时复制技术（Copy-On-Write），在生成快照的同时，依然可以正常处理写命令。简单来说，bgsave子进程是由主进程fork生成的，可以共享主线程的所有内存数据。

bgsave子进程运行后，开始读取主线程的内存数据，并把它们写入RDB文件。此时，如果主线程对于这些数据也都是读操作，那么主线程和bgsave子进程相互不影响。

但是，如果主线程要修改一块数据，那么，这块数据就会被复制一份，生成改数据的副本。然后bgsave子进程会把这个副本数据写入RDB文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

AOF重新

AOF会记录每个写命令到aof文件，随着时间越来越长，aof文件会变得越来越大。如果不加以控制，会对Redis服务器，甚至操作系统造成影响，而且aof文件越大，数据恢复也越慢。为了解决aof文件体积膨胀的问题，Redis提供AOF重新机制来对aof文件进行“瘦身”。

RDB vs AOF

命令	RDB	AOF
启动优先级	低	高
体积	小	大
恢复速度	快	慢
数据安全性	容易丢失数据	依据策略决定

save vs bgsave

命令	save	bgsave
IO类型	同步	异步
是否阻塞redis其它命令	是	否（在生成子进程执行调用fork函数时会有短暂的阻塞）
复杂度	O(n)	O(n)
优点	不会消耗额外内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork子进程，消耗内存

14、说说你对Redis事务的理解

什么是 Redis 事务？

Redis 中的事务是一组命令的集合，是 Redis 的最小执行单位。它可以保证一次执行多个命令，每个事务是一个单独的隔离操作，事务中的所有命令都会序列化、按顺序地执行。服务端在执行事务的过程中，不会被其他客户端发送来的命令请求打断。

原理是什么？

将属于一个事务的命令发送给 Redis，然后依次执行这些命令。

Redis 事务的注意点有哪些？

Redis 事务是不支持回滚的，不像 MySQL 的事务一样，要么都执行要么都不执行；
Redis 服务端在执行事务的过程中，不会被其他客户端发送来的命令请求打断。直到事务命令全部执行完毕才会执行其他客户端的命令。

Redis 事务为什么不支持回滚？

Redis 的事务不支持回滚，但是执行的命令有语法错误，Redis 会执行失败，这些问题可以从程序层面捕获并解决。但是如果出现其他问题，则依然会继续执行余下的命令。这样做的原因是因为回滚需要增加很多工作，而不支持回滚则可以保持简单、快速的特性。

15、缓存雪崩

现象：

由于原有缓存失效，新缓存未到期间 (例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

解决方案：

大多数系统设计者考虑用加锁（最多的解决方案）或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。
还有一个简单方案就时将缓存失效时间分散开。

16、缓存穿透

现象：

用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

解决方案：

布隆过滤器：将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
缓存空结果，并设置短暂过期时间：如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。通过这个直接设置的默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库，这种办法最简单粗暴。

17、缓存击穿

现象：

对于一些设置了过期时间的key，如果这个key在某个时间段被超高并发访问（热点数据），或者这个key在大量并发请求进来前正好失效，所有访问都会落到数据库，造成系统崩溃。

解决方案：

加锁：大量并发只让一个请求去查，其它请求等待，查到以后放入缓存，这样其它请求获取到锁，先查询缓存，不用去查数据库。

18、缓存预热

现象：

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

解决方案：

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

19、缓存降级

现象：

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

以参考日志级别设置预案：

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

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

20、缓存和数据库谁先更新？

写请求过来，将写请求缓存到缓存队列中，并且开始执行写请求的具体操作（删除缓存中的数据，更新数据库，更新缓存）。
如果在更新数据库过程中，又来了个读请求，将读请求再次存入到缓存队列（可以搞n个队列，采用key的hash值进行队列个数取模hash%n，落到对应的队列中，队列需要保证顺序性）中，顺序性保证等待队列前的写请求执行完成，才会执行读请求之前的写请求删除缓存失败，直接返回，此时数据库中的数据是旧值，并且与缓存中的数据是一致的，不会出现缓存一致性的问题。
写请求删除缓存成功，则更新数据库，如果更新数据库失败，则直接返回，写请求结束，此时数据库中的值依旧是旧值，读请求过来后，发现缓存中没有数据，则会直接向数据库中请求，同时将数据写入到缓存中，此时也不会出现数据一致性的问题。
更新数据成功之后，再更新缓存，如果此时更新缓存失败，则缓存中没有数据，数据库中是新值，写请求结束，此时读请求还是一样，发现缓存中没有数据，同样会从数据库中读取数据，并且存入到缓存中，其实这里不管更新缓存成功还是失败，都不会出现数据一致性的问题。

这方案解决了数据不一致的问题，主要是使用了串行化，每次操作进来必须按照顺序进行。如果某个队列元素积压太多，可以针对读请求进行过滤，提示用户刷新页面，重新请求。

潜在的问题：

请求时间过长，大量的写请求堆压在队列中，一个读请求来得等写完了才可以获取到据。
读请求并发高。
热点数据路由问题，导致请求倾斜。

21、怎么提高缓存命中率？

提前加载数据到缓存中；
增加缓存的存储空间，提高缓存的数据；
调整缓存的存储数据类型；
提升缓存的更新频率。

22、Redis 如何解决 key 冲突？

Redis 如果 key 相同，后一个 key 会覆盖前一个 key。如果要解决 key 冲突，最好给 key 取好名区分开，可以按业务名和参数区分开取名，避免重复 key 导致的冲突。

23、Redis 报内存不足怎么处理？

修改配置文件 redis.conf 的 maxmemory 参数，增加 Redis 可用内存。
设置缓存淘汰策略，提高内存的使用效率。
使用 Redis 集群模式，提高存储量。

24、什么是 bigkey？会存在什么影响？

bigkey 是指键值占用内存空间非常大的 key。例如一个字符串 a 存储了 200M 的数据。

bigkey 的主要影响有：

网络阻塞：获取 bigkey 时，传输的数据量比较大，会增加带宽的压力。
超时阻塞：因为 bigkey 占用的空间比较大，所以操作起来效率会比较低，导致出现阻塞的可能性增加。
导致内存空间不平衡：一个 bigkey 存储数据量比较大，同一个 key 在同一个节点或服务器中存储，会造成一定影响。

25、什么情况下可能会导致 Redis 阻塞？

内部原因：

如果 Redis 主机的 CPU 负载过高，也会导致系统崩溃；
数据持久化占用资源过多；
对 Redis 的 API 或指令使用不合理，导致 Redis 出现问题。

外部原因：

外部原因主要是服务器的原因，例如服务器的 CPU 线程在切换过程中竞争过大，内存出现问题、网络问题等。

26、怎么使用 Redis 实现消息队列？

一般使用 list 结构作为队列， rpush 生产消息， lpop 消费消息。当 lpop 没有消息的时候，要适当 sleep 一会再重试。
可不可以不用 sleep 呢？list 还有个指令叫 blpop ，在没有消息的时候，它会阻塞住直到消息到来。
能不能生产一次消费多次呢？使用 pub / sub 主题订阅者模式，可以实现 1:N的消息队列。
pub / sub 有什么缺点？在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如 rabbitmq 等。
Redis 如何实现延时队列？使用 sortedset ，拿时间戳作为 score ，消息内容作为 key 调用 zadd 来生产消息，消费者用 zrangebyscore 指令获取 N 秒之前的数据轮询进行处理。

27、Redis 数据结构及应用场景

Redis数据结构及应用场景

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

使用 keys 命令：直接使用 keys 命令查询，但是如果是在生产环境下使用会出现一个问题，keys 命令是遍历查询的，查询的时间复杂度为 O(n)，数据量越大查询时间越长。而且 Redis 是单线程，keys 指令会导致线程阻塞一段时间，会导致线上 Redis 停顿一段时间，直到 keys 执行完毕才能恢复。这在生产环境是不允许的。除此之外，需要注意的是，这个命令没有分页功能，会一次性查询出所有符合条件的 key 值，会发现查询结果非常大，输出的信息非常多。所以不推荐使用这个命令。
使用 scan 命令：scan 命令可以实现和 keys 一样的匹配功能，但是 scan 命令在执行的过程不会阻塞线程，并且查找的数据可能存在重复，需要客户端操作去重。因为 scan 是通过游标方式查询的，所以不会导致Redis 出现假死的问题。Redis 查询过程中会把游标返回给客户端，单次返回空值且游标不为 0，则说明遍历还没结束，客户端继续遍历查询。scan 在检索的过程中，被删除的元素是不会被查询出来的，但是如果在迭代过程中有元素被修改，scan 不能保证查询出对应元素。相对来说，scan 指令查找花费的时间会比 keys 指令长。

29、熟悉哪些 Redis 集群模式？

Redis Sentinel：体量较小时，选择 Redis Sentinel ，单主 Redis 足以支撑业务。
Redis Cluster：Redis 官方提供的集群化方案，体量较大时，选择 Redis Cluster ，通过分片，使用更多内存。
Twemprox：是 Twtter 开源的一个 Redis 和 Memcached 代理服务器，主要用于管理 Redis 和 Memcached 集群，减少与Cache 服务器直接连接的数量。
Codis：是一个代理中间件，当客户端向 Codis 发送指令时， Codis 负责将指令转发到后面的Redis 来执行，并将结果返回给客户端。一个 Codis 实例可以连接多个 Redis 实例，也可以启动多个 Codis 实例来支撑，每个 Codis 节点都是对等的，这样可以增加整体的 QPS 需求，还能起到容灾功能。
客户端分片：在 Redis Cluster 还没出现之前使用较多，现在基本很少热你使用了，在业务代码层实现，起几个毫无关联的 Redis 实例，在代码层，对 Key 进行 hash 计算，然后去对应的 Redis 实例操作数据。这种方式对 hash 层代码要求比较高，考虑部分包括，节点失效后的替代算法方案，数据震荡后的自动脚本恢复，实例的监控，等等。

30、Redis Cluster 集群的原理是什么？

所有的节点相互连接。
集群消息通信通过集群总线通信，集群总线端口大小为客户端服务端口 + 10000（固定值）。
节点与节点之间通过二进制协议进行通信。
客户端和集群节点之间通信和通常一样，通过文本协议进行。
集群节点不会代理查询。
数据按照 Slot 存储分布在多个 Redis 实例上。
集群节点挂掉会自动故障转移。
可以相对平滑扩/缩容节点。

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

31、说说 Redis 哈希槽的概念？

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

32、Redis Cluster 什么情况下会导致整个集群不可用？

Redis 没有使用哈希一致性算法，而是使用哈希槽。Redis 中的哈希槽一共有 16384 个，计算给定
密钥的哈希槽，我们只需要对密钥的 CRC16 取摸 16384。假设集群中有 A、B、C 三个集群节点，不存在复制模式下，每个集群的节点包含的哈希槽如下：

节点 A 包含从 0 到 5500 的哈希槽。
节点 B 包含从 5501 到 11000 的哈希槽。
节点 C 包含从 11001 到 16383 的哈希槽。

这时，如果节点 B 出现故障，整个集群就会出现缺少 5501 到 11000 的哈希槽范围而不可用。

33、Redis 常见性能问题和解决方案有哪些？

Master 最好不要做任何持久化工作，如 RDB 内存快照和 AOF 日志文件。
如果数据比较重要，某个 Slave 开启 AOF 备份数据，策略设置为每秒同步一次。
为了主从复制的速度和连接的稳定性，Master 和 Slave 最好在同一个局域网内。
尽量避免在压力很大的主库上增加从库。
主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <-Slave3….；这样的结构方便解决单点故障问题，实现 Slave 对 Master 的替换。如果 Master 挂了，可以立刻启用 Slave1 做 Master，其他不变。