Redis 常见问题

什么是Reids

Redis是一个使用C语言写的开源的高性能key-value非关系型数据库.

Redis中包含string, list ,set, zset, hash 等数据类型.

Redis的数据都基于缓存的, 每秒可以处理10万次读写, 是已知最快的key-value 数据库.

Redis可以实现写入磁盘, 保证数据安全.

Redis的操作是原子性的.

Redis为什么快

完全基于内存.
数据结构简单
采用单线程, 避免了不必要的上下文切换和竞争条件.
使用多路I/O复用模型, 非阻塞IO
底层通信协议不同.

Redis的持久化机制是什么

Reids提供了2中持久化机制: RDB(默认) 和 AOF机制.

RDB: 是Redis DataBase缩写快照.

RDB是Redis默认持久化方式, 按照一定时间将内存的数据以快照的形式保存到硬盘中, 对应产生的数据文件为dump.rdb

通过配置文件中的save参数定义快照周期.

优点:

只有一个文件dump.rdb, 方便持久化
容灾性好.
性能最大化
相对于数据集大时, 比AOF的启动效率更高.

缺点:

数据安全性低: RDB是间隔一段时间进行持久化, 可能丢失间隙数据.

AOF持久化(Append Only File)

将Redis执行的每次写命令记录到单独的日志文件中, 当重启Redis会重新回复数据.

两种方式都开启时, 优先选择AOF.

优点:

数据安全, AOF持久化可以配置appendfsync数据，有always 保证每次都记录.

缺点:

AOF 文件比RDB文件大

Redis过期键的删除策略

Redis 提供了多种过期键删除策略，包括:

定时删除：在设置键的过期时间的同时，创建一个定时器，当键的过期时间来临时，立即执行对键的删除操作。
惰性删除：放任过期键不管，每次从键空间中获取键时，检查该键是否过期，如果过期，就删除该键，如果没有过期，就返回该键。
定期删除：每隔一段时间，程序对数据库进行一次检查，删除里面的过期键，至于要删除哪些数据库的哪些过期键，则由算法决定。
随机删除：随机选择一部分过期键并对其进行删除

Redis 服务器实际使用的是定时删除、惰性删除和定期删除。这些策略可以在 Redis 的配置文件中进行设置，也可以通过 Redis 命令进行动态配置。

以下是一些常见的配置和使用删除策略的方法：

配置文件设置 ：可以在 Redis 的配置文件（通常是redis.conf）中设置删除策略的相关参数。例如，可以设置maxmemory-policy参数来指定使用的删除策略，如volatile-lru、allkeys-lru、volatile-random等。
Redis 命令设置 ：可以使用 Redis 命令来动态设置删除策略。例如，可以使用CONFIG SET命令来设置maxmemory-policy参数。
选择合适的删除策略：根据实际应用的需求和场景，选择合适的删除策略。例如，如果对内存限制较为严格，可以选择定时删除或定期删除策略；如果对 CPU 资源较为敏感，可以选择惰性删除策略。
监控和调整：在使用删除策略时，需要监控 Redis 的内存使用情况和性能指标，并根据实际情况进行调整。如果发现内存占用过高或性能下降，可以考虑调整删除策略或其他相关参数。

需要注意的是，不同的删除策略在内存占用和 CPU 资源消耗方面存在差异，因此需要根据具体情况进行选择和优化。此外，Redis 还提供了一些其他的配置参数，如maxmemory、maxmemory-samples等，可以进一步调整删除策略的行为.

Redids内存淘汰策略

Redis 提供了多种内存淘汰策略，用于在内存使用达到上限时，决定清理哪些数据以释放内存空间。以下是一些常见的 Redis 内存淘汰策略：

noeviction：不会继续服务写请求（DEL 请求可以继续服务），读请求可以继续进行。这样可以保证不会丢失数据，但是会让线上的业务不能持续进行。
allkeys-lru：从数据集（server.db(i).dict）中挑选最近最少使用的数据淘汰，该策略要淘汰的 key 面向的是全体 key 集合，而非过期的 key 集合。
allkeys-random：从数据集（server.db(i).dict）中选择任意数据淘汰。
volatile-lru：从设置过期时间的数据集（server.db(i).expires）中挑选出最近最少使用的数据淘汰。没有设置过期时间的 key 不会被淘汰，这样就可以在增加内存空间的同时保证需要持久化的数据不会丢失。
volatile-ttl：除了淘汰机制采用 LRU，策略基本上与 volatile-lru 相似，从设置过期时间的数据集（server.db(i).expires）中挑选将要过期的数据淘汰，ttl 值越大越优先被淘汰。
volatile-random：从已设置过期时间的数据集（server.db(i).expires）中任意选择数据淘汰。当内存达到限制无法写入非过期时间的数据集时，可以通过该淘汰策略在主键空间中随机移除某个 key。

这些策略可以根据具体的应用需求进行选择和配置。例如，如果希望保留最近使用过的数据，可以选择 allkeys-lru 策略；如果希望优先删除即将过期的数据，可以选择 volatile-ttl 策略。同时，还可以通过调整相关参数来进一步优化内存淘汰的行为。

什么是Reids事务

Redis 事务是一组命令的集合，可以将多个命令打包一次性执行，保证这些命令执行的原子性。

在一个 Redis 事务中，所有命令都会被序列化并按顺序执行。要么所有命令都成功执行，要么都不执行。

在执行事务时，通常的步骤如下：

使用 **MULTI**命令开启事务。
依次发送要执行的命令。
使用 **EXEC**命令执行事务中的所有命令。

如果在事务执行过程中出现错误，有以下情况：

如果是在执行命令时发生错误（比如语法错误等），则整个事务会失败，所有命令都不会执行。
如果是命令执行后返回错误结果（比如对一个不存在的键进行操作等），其他命令仍然会执行，只是出错的命令会有相应错误结果。

Redis 事务可以保证一定程度上的一致性和隔离性，但它并不像传统关系型数据库的事务那样严格。例如，它不能保证回滚到事务开始前的状态。

Redis事务相关命令

Redis 中与事务相关的命令主要包括以下几种：

MULTI：标记事务的开始。当你调用 MULTI 命令后，Redis 会进入事务状态，之后发送的所有命令都不会立即执行，而是被放入一个队列中等待执行；
EXEC：执行事务。当所有要执行的命令都已通过 MULTI 收集完毕后，调用 EXEC 命令会使 Redis 服务器顺序执行队列中的所有命令。这些命令作为一个整体被提交，实现了事务的原子性，尽管这种原子性是有限的，不包括失败回滚；
DISCARD：取消事务。如果你在 MULTI 后、EXEC 前决定不执行事务中的命令，可以使用 DISCARD 来清空命令队列并退出事务状态；
WATCH：为事务提供乐观锁机制。使用 WATCH 命令可以监视一个或多个键，如果在 WATCH 后、EXEC 前这段时间内，被监视的键被其他客户端修改了，那么当执行 EXEC 时，事务会失败并返回一个错误，从而可以实现基于条件的事务执行；

Redis哨兵模式

Redis 哨兵模式是一种高可用解决方案，用于监控 Redis 主节点的状态，并在主节点发生故障时自动进行故障转移。以下是关于 Redis 哨兵模式的一些关键信息：

功能：
- 监控：持续监控 Redis 主节点和从节点的运行状态。
- 通知：在主节点发生故障时，通过 API 通知监控系统或其他应用程序。
- 自动故障恢复：当主节点发生故障时，自动将从节点提升为主节点，并通知客户端使用新的主节点。
- 配置中心：为客户端提供 Redis 主节点的地址信息。
工作原理：
- 每个 Sentinel 实例会以每秒一次的频率向主节点、从节点和其他 sentinel 实例发送 PING 命令，以检查它们的状态。
- 如果一个实例在指定的时间内（down-after-milliseconds）没有响应 PING 命令，或者返回错误，sentinel 会将该实例标记为主观下线。
- 如果多个 sentinel 实例都认为主节点主观下线，并且达到了 quorum 数量的 sentinel 实例达成共识，那么主节点将被标记为客观下线。
- 一旦主节点被标记为客观下线，sentinel 会开始进行故障转移。它会从从节点中选择一个合适的节点作为新的主节点，并通知其他从节点切换到新的主节点进行复制。
- 客户端可以通过连接 sentinel 实例来获取当前主节点的地址信息。
搭建哨兵模式：
- 准备多个 Redis 实例，包括主节点和从节点。
- 为每个 sentinel 实例创建配置文件，指定监控的主节点信息和其他 sentinel 实例的地址。
- 启动 Redis 实例和 sentinel 实例。

通过使用 Redis 哨兵模式，可以提高 Redis 系统的可用性和可靠性，减少人工干预和故障恢复时间。但需要注意的是，哨兵模式仍然存在一些局限性，例如在网络分区等情况下可能会出现误判。在实际应用中，需要根据具体需求和场景进行评估和选择。

Redis 哨兵模式的工作原理主要包括以下几个方面：

监控：哨兵节点会定期向主节点、从节点和其他哨兵节点发送 PING 命令，以检查它们的状态。如果一个节点在指定的时间内没有响应 PING 命令，或者返回错误，哨兵会将该节点标记为主观下线。
通知：当一个节点被标记为主观下线时，哨兵会向其他哨兵节点发送通知，询问它们是否也认为该节点下线。如果多个哨兵节点都认为该节点下线，那么该节点将被标记为客观下线。
选举 Leader Sentinel：当主节点被标记为客观下线时，哨兵节点会进行选举，选出一个 Leader sentinel。Leader sentinel 负责进行故障转移操作，将从节点提升为主节点。
故障转移：一旦选举出 Leader sentinel，它会开始进行故障转移。首先，它会从从节点中选择一个合适的节点作为新的主节点。选择的标准通常包括节点的健康状况、数据完整性等。然后，Leader sentinel 会向其他从节点发送命令，让它们切换到新的主节点进行复制。
通知客户端：故障转移完成后，Leader sentinel 会通知客户端新的主节点的地址，以便客户端能够重新连接到 Redis 集群。

通过以上工作原理，Redis 哨兵模式可以实现自动故障检测和转移，提高了 Redis 集群的可用性和可靠性。同时，哨兵模式还可以实现对 Redis 集群的监控和管理，方便管理员进行维护和管理。

Redis主从架构

实现 Redis 主从架构的一般步骤：

配置主节点：
- 在主节点的 Redis 配置文件（通常是 redis.conf）中，无需特殊配置来明确其为主节点。
配置从节点：
- 在从节点的配置文件中添加以下配置：
  - slaveof <主节点 IP> <主节点端口> ，指定主节点的地址和端口。
启动主从节点：分别启动主节点和从节点的 Redis 服务。
验证：
- 可以在从节点上使用 INFO replication 命令查看复制状态，确认从节点是否成功连接到主节点并开始同步数据。

另外，也可以通过命令行动态地设置从节点：在从节点上执行 SLAVEOF <主节点 IP> <主节点端口> 命令来建立主从关系。

Redis实现分布式锁

Reids缓存穿透, 缓存雪崩

Redis缓存降级

在 Redis 中进行缓存降级可以通过以下一些方式来实现：

基于策略的降级：

可以设置一些规则，例如当缓存命中率低于一定阈值时，采取降级措施。比如不再从缓存中获取数据，直接从数据源（如数据库）获取并返回。

手动触发降级：

在某些特定场景下，比如系统面临高并发压力或缓存出现故障时，手动将系统切换到从数据源获取数据的模式。

数据分层降级：

可以将缓存数据分为不同的重要级别。当出现问题时，先放弃不太重要数据的缓存，保证关键数据的缓存正常服务。

失效时间调整：

临时调整某些缓存数据的失效时间，加快数据的更新频率，以适应特殊情况。