redis 常见面试题

清瞳清

已于 2023-05-10 09:15:59 修改

阅读量317

点赞数 1

分类专栏： redis 文章标签： redis 缓存 java

于 2023-01-31 13:20:32 首次发布

本文链接：https://blog.csdn.net/m0_51277041/article/details/128812239

版权

redis 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

Redis 做什么的，即在哪些场景下使用?

Redis 是一种内存数据结构存储，用作数据库、缓存和消息代理。它通常用于以下场景：

缓存：将经常访问的数据存储在内存中以便快速检索。
会话管理：在 Web 应用程序中存储用户会话数据。
实时分析：实时处理和分析高速数据。
排行榜：维护和更新游戏应用程序中的分数。
发布/订阅消息传递：在微服务之间实现消息代理。
作业队列：管理 Web 应用程序中的后台作业处理。

这些是一些常见的用例，但 Redis 也可以用于广泛的其他应用程序。

如何监控 Redis 是否出现故障？

健康检查：实现一个简单的健康检查脚本，向 Redis 发送 ping 命令并检查响应是否成功。该脚本可以定期运行，并在 Redis 无响应时提醒管理员。
监控工具：使用 Nagios、Zabbix 或 Datadog 等监控工具来监控 Redis 性能，并在发生故障时向管理员发出警报。这些工具可以监控各种 Redis 指标，例如内存使用情况、连接的客户端数量和
Redis Sentinel：Redis Sentinel 是一种内置的高可用性解决方案，可用于监控 Redis 实例，并在发生故障时自动故障转移到备份实例。
日志记录：监视 Redis 日志中指示潜在故障的错误和警告消息。

Redis客户端timeout报错突然增加，排查思路是怎样的？

检查网络连接：确保 Redis 客户端和服务器之间的网络正常运行，并且没有连接问题。
监控资源利用率：检查 Redis 服务器资源的利用率，例如 CPU、内存和磁盘。如果利用率很高，这可能表示服务器不堪重负，无法及时处理请求。
监控 Redis 延迟：使用 redis-cli 或 Redis 监控 API 等工具监控 Redis 命令的延迟。如果延迟较高，则可能表示服务器上存在资源限制。
检查日志：检查 Redis 服务器日志中是否有错误或警告消息，这些错误或警告消息可能会提供有关超时原因的其他信息。
检查客户端配置：确保客户端配置正确，并且对其操作使用适当的超时值。
负载测试：运行负载测试以查看超时的增加是否与流量或使用量峰值有关。

请简单描述pipeline功能，为什么pipeline功能会提升redis性能？

管道是 Redis 中的一项功能，它允许在单个请求中将多个命令发送到服务器，从而减少单个请求的开销。

在管道中，命令在客户端缓冲，并批量发送到服务器。然后，服务器处理命令并在单个响应中返回响应。这减少了每个命令的单独网络往返开销，从而提高了性能。
通过使用管道，可以减少完成一组命令的总时间，因为消除了为每个命令建立和拆除连接的开销。此外，管道还可以减少网络延迟，因为通过网络发送的数据总量减少了。

本地redis-client访问远程Redis服务出错，说出几种常见的错误?

网络连接问题：由于网络问题（如防火墙限制、DNS 解析问题或不正确的 IP 地址和端口），本地客户端可能无法连接到远程服务器。
身份验证失败：如果远程 Redis 服务器需要身份验证，则本地客户端可能没有正确的凭据，从而导致身份验证失败。
配置不匹配：本地客户端可能配置了不正确的值，例如远程服务器的 IP 地址或端口不正确，从而导致连接失败。
服务器关闭或无响应：远程 Redis 服务器可能已关闭或无响应，从而导致本地客户端收到连接错误。
数据不匹配：本地客户端可能正在尝试访问远程服务器上不存在的数据，从而导致数据不匹配错误。

key-value的大小超大或单key的qps超高，会对Redis本身造成什么样的影响、会对访问Redis的其他客户端造成什么样的影响?

Redis 性能影响：大密钥或高 qps 可能会导致 Redis 变慢或无响应，因为它可能无法处理增加的负载。这可能会导致延迟增加、超时和整体性能下降。
资源利用率影响：大密钥或高 qps 会导致 Redis 消耗更多资源，例如 CPU、内存和磁盘，从而导致同一系统上运行的其他进程的资源可用性降低。
网络影响：如果 Redis 在单独的系统上运行并通过网络访问，则大密钥或高 qps 可能会导致网络流量增加，从而导致网络拥塞和网络性能降低。
其他客户端影响：访问 Redis 的其他客户端也可能会遇到性能下降，因为它们可能需要等待更长的时间才能收到响应，或者由于 Redis 上的负载增加而遇到超时。

为了减轻这些影响，建议监控键值大小和 qps，并实施分片或分区技术以在多个 Redis 实例之间分配负载。此外，可能需要实施缓存或卸载技术来减少 Redis 上的负载，或者考虑为大密钥或高 qps 用例使用替代数据存储解决方案。

Zabbix 监控 Redis 哪些监控项？

连接数：与 Redis 服务器的活动连接数，包括客户机和发布/订阅连接。
内存使用情况：Redis 使用的内存量，包括驻留集大小（RSS）和虚拟内存（VM）大小。
命令执行时间：执行 Redis 命令所花费的时间，包括平均、最小和最大所花费的时间。
密钥计数：Redis 中存储的密钥数，包括密钥总数和按数据库列出的密钥数。
延迟：Redis 的延迟，包括响应客户端请求所花费的时间。
正常运行时间：Redis 不间断运行的时间量。
发布/订阅消息：通过 Redis 发布/订阅的消息数。
从站同步：Redis 从站实例的同步状态，包括延迟和挂起写入次数。

RDB和AOF持久化区别？

RDB（Redis DataBase）：RDB 是 Redis 数据库的时间点快照。Redis 会定期将 RDB 文件保存到磁盘，无论是基于计时器还是在对数据库进行了一定数量的更改时。RDB文件是紧凑的，可用于快速恢复整个数据库，但它们可能不像内存中的实时数据那样最新
AOF（仅追加文件）：AOF 是在 Redis 数据库上执行的所有写入命令的日志。与 RDB 不同，AOF 是连续写入磁盘的持续日志，这使其成为实时数据库的更准确表示形式。在发生崩溃或重新启动时，Redis 使用 AOF 日志通过重播写入命令来重建数据库。AOF文件比RDB文件大，但它们提供了更完整的数据库记录，可用于更准确地恢复数据。

总之，RDB 最适合备份和恢复方案，而 AOF 更适合持久性和持久性，尤其是在数据丢失不可接受的情况下。也可以同时使用 RDB 和 AOF，以平衡速度和耐用性。

docker拉取一个Redis如何实现数据持久化保存？

要在 Redis Docker 容器中持久保存数据，您可以使用卷映射将 Redis 数据存储在主机文件系统上。方法如下：
1、启动 Redis 容器：

docker run --name my-redis -d redis

2、在主机上创建一个目录来存储 Redis 数据：

mkdir ~/redis-data

3、停止 Redis 容器：

docker stop my-redis

4、使用卷映射再次启动 Redis 容器：

docker run --name my-redis -d -v ~/redis-data:/data redis redis-server --appendonly yes

这将映射主机目录 '~/redis-data–appendonly yes标志启用 AOF 持久性，以便 Redis 将所有写入操作写入磁盘。

注意：Redis 数据将在重新启动 Redis 容器后保留，但如果重新启动主机或删除 Docker 容器，数据将丢失。为了防止数据丢失，您还可以使用数据卷容器来存储 Redis 数据。

Redis 支持哪些数据类型？

字符串：Redis 字符串是二进制安全的，这意味着它们可以存储任何类型的数据，包括图像、序列化对象等
哈希：Redis 哈希是键值对的映射，类似于 Python 中的字典或 PHP 中的关联数组。
列表：Redis 列表是链表，可以存储多个元素并支持推送、弹出和修剪等操作。
集合：Redis 集是唯一元素的无序集合，可用于存储成员、执行集合操作（如并集和交集等）。
排序集：Redis 排序集是按分数排序的集，因此可以执行范围查询和其他操作。
位图：Redis 位图是可用于存储二进制数据（如标志或标志）并执行按位操作的位数组。
HyperLogLogs：Redis HyperLogLogs 是概率数据结构，用于计算具有少量内存的大型数据集中的唯一元素。
地理空间索引：Redis 地理空间索引（GEO）用于存储和检索位置数据，并执行基于位置的查询和距离计算等操作。

Redis 如何实现消息队列？

Redis 可以通过使用其 List 数据类型来实现简单队列，从而用作消息队列。方法如下：

将消息推送到队列：使用 LPUSH（左推）或 RPUSH（右推）命令分别将消息添加到队列的开头或结尾。例如：LPUSH myqueue "message1"
从队列中弹出消息：使用 LPOP（左弹出）或 RPOP（右弹出）命令分别从队列中删除并返回第一条或最后一条消息。例如：LPOP myqueue
阻止直到消息可用：使用 BLPOP（阻止左弹出）或 BRPOP（阻止右弹出）命令等待消息在队列中可用并返回它。例如：BLPOP myqueue 0

通过使用这些命令，Redis 可以用作简单的消息队列，可用于实现工作队列、任务队列和其他类型的队列。
注意：Redis 并非设计为功能齐全的消息代理，其性能特征和功能可能不适用于所有用例。如果您需要更高级的消息队列，请考虑使用专用的消息代理，例如 RabbitMQ 或 Apache Kafka。

描述下常见的redis集群架构有哪些，他们之间的优缺点对比?

主从架构：在此设置中，一个 Redis 实例（主实例）接收所有写入，而其他几个实例（从实例）接收所有读取请求。主站将其数据复制到从站，提供读取可扩展性和高可用性。如果主站发生故障，则可以提升其中一个从站来代替它。这种体系结构的主要缺点是主节点可能会成为写入密集型应用程序中的瓶颈。
分片架构：在此设置中，数据分布在多个 Redis 实例中，每个实例负责一部分数据。请求将根据要访问的密钥自动路由到相应的实例。分片提供写入和读取可扩展性以及高可用性，因为每个实例都可以独立运行。但是，分片在路由请求和管理密钥分发方面引入了一些复杂性。
Sentinel 架构：在此设置中，一个或多个 Redis 实例被指定为 Sentinel，用于监控其他实例的运行状况。如果主实例发生故障，哨兵会自动提升其中一个从实例取代它的位置。此体系结构提供高可用性，但在故障转移时可能会引入一些延迟，因为需要选择新的主服务器。

主从复制工作原理?

一个 Redis 实例被指定为主实例，而一个或多个其他实例被指定为从实例。
主服务器接收所有写入请求，并在自己的数据集上执行这些写入。
主站还实时将其数据集复制到其从站，并在发生时发送所有写入操作。
从属服务器接收来自主站的更新，并将其应用于自己的数据集，使其与主站保持同步。
从站可用于为读取请求提供服务，这有助于分配读取负载并提高整体性能。
如果主站发生故障，可以提升其中一个从站来取代它，从而确保高可用性。新的主站将继续接收写入请求并将其数据复制到任何剩余的从站。

Redis 如何实现高可用?

主从复制：如上所述，这涉及让一个或多个从站从主站接收实时更新，确保数据在发生故障时始终可用。
Redis Sentinel：这是一项特定于 Redis 的服务，可在主服务器发生故障时提供自动故障转移。它监控主站的运行状况，并在发生故障时自动提升其中一个从站取代其位置。
Redis 集群：这是一种分布式 Redis 部署，可跨多个节点自动分片数据，并在节点发生故障时提供自动故障转移。Redis 集群还提供内置的数据分区和分发机制，从而实现高性能和高可用性部署。
负载均衡：Redis 可以部署在负载均衡器后面，将传入请求分发到多个 Redis 实例，从而提高性能和可靠性。

哨兵工作原理

Redis Sentinel 是 Redis 的监控和故障转移服务。它通过监控一个或多个 Redis 实例（称为“主实例”）以及一个或多个从属实例来工作。Sentinel 服务维护群集状态的视图，并可以自动检测和响应群集中的故障。

以下是它的工作原理：

监控：Sentinel 通过发送 PING 命令和监控响应时间来定期检查主站和从站的运行状况。如果主服务器无响应，Sentinel 会将其标记为“关闭”并开始故障转移过程。
选举：如果主设备被标记为关闭，Sentinel 将启动选举过程，以确定应将哪个从设备提升为新主服务器。这是通过考虑诸如主站和从站的最后已知状态，以及连接的客户端数量和每个从站上存储的数据量等因素来完成的。
提升：一旦选出了新的主节点，Sentinel 将通过执行 SLAVEOF 命令将其提升为主角色。然后，新的主服务器将接管为客户端请求提供服务。
通知：Sentinel 将通知客户端和其他哨兵新的主服务器，并更新其内部状态以反映新的集群配置。

Redis 集群的工作原理

Redis 集群是一项 Redis 功能，可在多个 Redis 节点之间提供数据自动分片，并在节点发生故障时自动故障转移和重新平衡。

以下是它的工作原理：

分片：Redis 集群将密钥空间划分为多个哈希槽，并将每个槽分配给集群中的特定节点。当客户端写入键值对时，Redis 集群会确定该键的哈希槽，并将写入路由到相应的节点。
复制：群集中的每个节点都维护其分配的哈希槽的副本，确保数据以冗余方式存储，并在节点发生故障时高度可用。
负载均衡：Redis 集群自动平衡节点间哈希槽的负载，确保集群始终高效运行。如果节点过载，Redis 集群会自动将哈希槽重新平衡到集群中的其他节点。
故障处理：Redis 集群可以自动检测和响应节点故障，提升其中一个副本作为新的主节点接管，并确保数据始终可用。即使在节点发生故障时，客户端也可以继续正常运行。

Redis 集群如何避免脑裂?

仲裁：Redis 集群使用基于仲裁的共识算法，其中大多数节点必须在进行更改之前就集群的状态达成一致。这可确保在少数节点脱机或遇到网络问题时不会发生脑裂情况。
主节点选择：如果主节点发生故障，Redis 集群将自动从剩余副本中选择新的主节点。这可确保群集中始终存在单一权威事实来源，避免出现裂脑情况。
网络分区处理：如果出现网络分区，Redis 集群将继续在分区的两端正常运行，但不允许发生冲突写入。解析分区后，Redis 集群会自动协调冲突数据，确保始终存储正确的数据。

Redis 集群最少几个节点为什么?

Redis 集群至少需要 3 个主节点才能正常运行和高可用性。这是因为 Redis 集群使用基于仲裁的共识算法，其中大多数节点必须在进行更改之前就集群的状态达成一致。对于 3 个主节点，即使在单个节点发生故障的情况下，也始终有大多数节点可供决策。

Redis的集群槽位多少个？

Redis 集群中的插槽数量由集群配置决定，默认为 16384 个插槽。槽是映射到集群中特定 Redis 实例的哈希值范围，集群中的每个 Redis 实例负责存储和提供部分哈希槽的数据。

通过在集群中的所有实例之间均匀分布哈希槽，Redis 集群能够确保数据均匀分布，并且每个实例的负载大致相等。这有助于避免热点，并确保群集可以水平缩放。

Redis集群中某个节点缺少一个槽位是否能使用？

当节点缺少插槽时，群集将自动启动插槽重新平衡过程，以将缺少的插槽重新分配到群集中的另一个节点。这有助于确保群集保持可用，并且可以继续为数据请求提供服务，即使群集中的某个节点遇到问题也是如此。

但是，在重新平衡过程完成之前，存储在缺失插槽中的数据将不可用。这可能会导致尝试访问存储在该槽中的数据的客户端出错或超时。为了最大程度地减少插槽重新平衡的影响，必须为群集配置适当数量的节点，并监视群集中的问题并及时解决这些问题。

Redis数据写入的时候是怎么在各个节点槽位分配数据的？

在 Redis 集群中，每个密钥都分配给一个特定的插槽，然后映射到集群中的一个节点。将数据写入 Redis 时，客户端对密钥进行哈希处理以确定相应的槽，然后将写入操作转发到负责该槽的节点。这样，Redis 集群可以在集群中的所有节点上均匀分布数据，从而确保高性能和可扩展性。

Redis的数据存储是以什么样的方式存储？

Redis 将数据作为键值对存储在内存中，并可选择持久化到磁盘。Redis 支持的数据结构类型包括字符串、哈希、列表、集合、排序集和位图。数据结构存储在哈希表中，其中对键进行哈希处理以确定其值的内存位置。Redis 还可以使用内存映射文件在磁盘上存储大量数据。这允许快速访问内存中的数据，即使对于较大的数据集也能提供快速性能。