一、Redis key没设置过期时间却被redis主动删除了

如果一个 Redis 键没有设置过期时间，那么 Redis 无法判断该键是否应该自动删除。因此，如果一个没有设置过期时间的键被 Redis 主动删除了，可能是以下原因之一：

1. 内存不足：如果 Redis 内存不足，它会删除一些键以释放内存。如果该键没有被设置过期时间，则可能会被作为“临时”键删除。
2. 数据库空间不足：如果 Redis 数据库空间不足，它会删除一些键以释放空间。在这种情况下，可能会删除没有设置过期时间的键。
3. 手动删除：可能是有人手动删除了该键。

可以通过以下方法来避免 Redis 主动删除没有设置过期时间的键：

5. 设置键的过期时间为一个较长的值，例如 230000 年。这样可以避免 Redis 在键被使用之前将其删除。
6. 在使用完键之后，手动删除它。这样 Redis 就不会在键被使用之前将其删除。如果你不再需要这个键，那么最好将其删除，以便释放内存。

需要注意的是，如果你设置了太多的键，而且这些键的过期时间很短，那么 Redis 的内存占用可能会迅速增加，从而导致性能下降或者宕机。因此，在设置键的过期时间时需要权衡好内存占用和性能之间的关系。

二、Redis有哪些淘汰key的策略

主动清理策略在Redis 4.0之前一共实现了 6 种内存淘汰策略，在 4.0 之后，又增加了 2 种策略，总共8种

a)针对设置了过期时间的key做处理:

1. volatile-tl: 在筛选时，会针对设置了过期时间的键值对，根据过期时间的先后进行删除，越早过期的越先被删除.
2. volatile-random: 就像它的名称一样，在设置了过期时间的键值对中，进行随机删除。
3. volatile-lru: 会使用 LRU 算法筛选设置了过期时间的键值对删除
4. volatile-lfu: 会使用 LFU 算法筛选设置了过期时间的键值对删除。

b) 针对所有的key做处理:

5. allkeys-random: 从所有键值对中随机选择并删除数据
6. allkeys-lru: 使用 LRU 算法在所有数据中进行筛选删除
7. allkeys-lfu: 使用 LFU 算法在所有数据中进行筛选删除

c) 不处理:

8. noeviction: 不会别除任何数据，拒绝所有写入操作并返回客户端错误信息"eror) 00M command not allowed whenused memory”，此时Redis只响应读操作。

三、Redis淘汰key策略LRU与LFU的区别

1. LRU（Least Recently Used）：最近最少使用策略。当Key空间被占满时，淘汰最近最少使用的Key。

2. LFU（Least Frequently Used）：最不经常使用策略。当Key空间被占满时，淘汰最不经常使用的Key

LRU是按时间轴来淘汰数据，即淘汰最近最少使用的数据；LFU是按使用次数来淘汰数据，即淘汰最不经常使用的数据。

当内存空间不足时，Redis会根据淘汰策略来删除部分数据，以释放内存空间。可以在Redis的配置文件中配置淘汰策略的相关参数，如最大内存、淘汰策略的阈值等。

绝太多数情况下我们使用LRU策略，当存在大量热点缓存数据时，推荐使用LFU

补充说明：

在Redis中，LRU算法是通过一个叫做“过期字典”的机制来实现的。当一个key被设置了过期时间时，Redis会在过期时间到达后将其从内存中删除。如果一个key没有被设置过期时间，但是已经很久没有被访问了，那么Redis会将其标记为“过期”，并在下一次垃圾回收时将其删除 。

四、删除Key时会阻塞Redis吗？

在Redis中，删除Key的操作通常不会阻塞其他操作。这是因为Redis使用单线程模型，并且删除Key是一个原子性操作，不需要其他线程来协助完成。

然而，在某些情况下，删除Key可能会阻塞Redis。

1. 例如，当你使用Redis作为数据库时，如果一个客户端正在读取数据库，并且另一个客户端正在删除一个Key，那么删除Key的操作可能会导致读取操作失败，因为Key已经不存在了。这种情况通常会在数据库中发生，因为数据库需要保持一致性。
2. 如果删除的是Bigkey，里面的数据比较大，删除需要比较长的时间，可能会阻塞Redis。

总的来说，删除Key的操作在Redis中是一个相对较快的操作，不会阻塞其他操作。但是，在某些情况下，它可能会对其他操作产生影响，因此需要仔细考虑在使用Redis时如何处理删除Key的操作。

五、Redis主从、哨兵、集群架构优缺点比较

1. 主从架构

主节点负责处理所有的写请求，将数据写入到内存中，并将数据异步地同步给从节点。从节点负责处理读请求，从主节点同步数据，并在主节点挂掉后，顶替主节点继续提供服务。

Redis主从架构的好处：

1. 提高数据的可用性：从节点可以处理读请求，当主节点挂掉时，可以从从节点读取数据，从而提高了数据的可用性。
2. 备份数据：从节点会将数据同步到磁盘中，从而可以备份数据，提高数据的安全性。
3. 分担负载：从节点可以分担主节点的负载，提高Redis的性能。
4. 读写分离：通过读写分离，可以将读请求和写请求分发给不同的节点，从而提高Redis的读写效率。

Redis主从架构的缺点：

1. 复制延迟：在Redis主从架构中，主节点需要将写操作复制到从节点中，这个过程需要一定的时间，可能导致数据复制延迟。这可能会影响数据的实时性和一致性。
2. 性能下降：当从节点数量增加时，Redis主从架构的性能可能会下降。因为每个从节点都需要从主1. 节点获取数据，这会增加主节点的负载，从而影响整个集群的性能。
   故障转移风险：在Redis主从架构中，如果主节点出现故障，需要手动将一个从节点提升为主节点。这会导致一定的数据丢失风险，因为提升的从节点可能没有主节点最新的数据。
3. 数据不一致性：在Redis主从架构中，如果主节点和从节点的数据存在不一致性，可能会导致数据错误。例如，当主节点和从节点的数据更新时间不同时，就可能出现这种情况。
4. 运维难度：Redis主从架构的运维难度较大，需要专业的运维团队进行管理和维护。运维人员需要熟悉Redis的运行机制和主从架构的配置方式，以便及时处理故障和调整配置。

2. 哨兵架构

Redis 哨兵架构是一种 Redis 集群管理模式，用于监控 Redis 主节点和从节点的运行状态，并自动处理节点故障。

Redis 哨兵架构包括以下几个部分：

• 哨兵进程（Sentinel）：哨兵进程是 Redis 集群的监控器，会持续监控主节点和从节点的状态，如果发现主节点或从节点出现故障，哨兵进程会触发自动故障转移操作。
• 主节点（Master）：主节点是 Redis 集群中的写节点，负责处理所有的写请求。
• 从节点（Slave）：从节点是 Redis 集群中的读节点，负责处理读请求，并在主节点故障时，进行故障转移操作。
• 故障转移（Failover）：当主节点出现故障时，哨兵进程会通过选举操作选出一个从节点作为新的主节点，并将所有的写请求发送给新的主节点。
• 重新同步（Resynchronization）：当从节点出现故障时，哨兵进程会重新同步从节点和主节点之间的数据，以确保数据的一致性。

Redis 哨兵架构的好处：

1. 监控节点状态：Redis 哨兵架构可以持续监控节点的状态，及时发现和处理节点故障。
2. 自动故障转移：当主节点出现故障时，Redis 哨兵架构可以自动选出新的主节点，并将所有的写请求发送给新的主节点，从而提高了数据的可用性和可靠性。
3. 数据备份：从节点可以将数据同步到磁盘中，从而备份数据，提高数据的安全性。
4. 分担负载：从节点可以分担主节点的负载，提高 Redis 的性能。
5. 读写分离：通过读写分离，可以将读请求和写请求分发给不同的节点，从而提高 Redis 的读写效率。

Redis 哨兵架构的缺点：

1. 监控开销：Redis 哨兵架构需要持续监控主节点和从节点的状态，这会增加一定的监控开销，导致哨兵进程可能会成为整个集群的性能瓶颈。
2. 配置复杂：Redis 哨兵架构的配置比较复杂，需要配置多个文件，并且需要保证配置的一致性。如果配置不当，可能会导致哨兵进程无法正确监控节点状态，从而导致故障转移失败。
3. 故障转移时间：当主节点出现故障时，Redis 哨兵架构需要进行故障转移操作，选择一个新的从节点作为新的主节点。这个过程需要一定的时间，可能会导致一段时间内 Redis 集群无法处理写请求。
4. 数据不一致性：当从节点出现故障时，Redis 哨兵架构需要进行重新同步操作，将主节点和从节点之间的数据同步到新的从节点上。如果重新同步操作不成功，可能会导致数据不一致性。
5. 运维难度：Redis 哨兵架构的运维难度较大，需要专业的运维团队进行管理和维护。运维人员需要熟悉 Redis 的运行机制和哨兵模式的配置方式，以便及时处理故障和调整配置。

3. Redis集群架构

Redis集群架构是为了提高Redis数据的可用性和可靠性的一种架构模式。Redis集群架构通常包括多个节点，这些节点组成了一个分布式的存储系统，可以对外提供读写服务。

Redis集群架构有两种方案：

• 带有主从结构的集群架构：这种架构包含一个主节点和多个从节点。主节点负责处理所有的写请求，并将写请求同步给从节点。从节点只负责处理读请求，并在主节点挂掉时，进行故障转移操作。
• 不带有主从结构的集群架构：这种架构中，所有节点都是平等的，都可以处理读请求和写请求。这种架构通常需要使用一些分片机制，将数据分散到不同的节点上，以实现数据的分布式存储。

在Redis集群架构中，数据的读写流程如下：

1. 客户端向集群中任意一个节点发送一个读请求。
2. 接收到请求的节点会检查自己是否拥有该数据，如果拥有，则直接返回数据；如果不拥有，则将请求转发给拥有该数据的节点。
3. 客户端向集群中任意一个节点发送一个写请求。
4. 接收到请求的节点会检查自己是否拥有该数据，如果拥有，则直接执行写操作；如果不拥有，则将请求转发给拥有该数据的节点。

Redis集群架构的好处：

1. 提高数据的可用性和可靠性：多个节点可以互相备份，当某个节点挂掉时，可以从其他节点读取数据，从而提高了数据的可用性和可靠性。
2. 分担负载：多个节点可以分担主节点的负载，提高 Redis 的性能。
3. 读写分离：通过读写分离，可以将读请求和写请求分发给不同的节点，从而提高 Redis 的读写效率。

Redis集群架构的缺点：

1. 节点故障：当集群中某个节点出现故障时，会导致该节点上的数据无法访问。虽然可以通过数据备份和故障转移等方式来减少数据丢失的风险，但是故障转移操作可能会导致一定的数据不一致性。
2. 性能限制：Redis 集群架构的性能受到节点数量和节点处理能力的限制。当集群规模较大时，性能可能会受到影响，而且大规模的集群管理也可能会变得复杂。
3. 数据分片：在带有分片机制的 Redis 集群架构中，数据需要被均匀地分配到各个节点上。但是如果数据分配不均匀，可能会导致某些节点的负载过高，从而影响整个集群的性能。
4. 运维难度：Redis 集群架构的运维难度较大，需要专业的运维团队进行管理和维护。
5. 成本增加：Redis 集群架构需要更多的节点和服务器，从而增加了硬件成本和运维成本。

总结：

Redis 的主从、哨兵、集群模式都是为了实现高可用和高并发，但它们之间有以下区别：

• 主从模式：主从模式是最简单的实现高可用的方案，核心就是主从同步。主服务器负责处理所有客户端请求，并将请求产生的数据变化发送给从服务器，从服务器负责接收主服务器的数据变化并保持与主服务器的数据一致性。主从模式可以提供读写分离、故障恢复和容错等功能，但当主服务器出现故障时，需要手动切换到从服务器，切换过程可能导致短暂的服务中断。
• 哨兵模式：哨兵模式是 Redis 的一种高可用方案，通过哨兵节点来监控主服务器和从服务器的状态，并在主服务器出现故障时自动将从服务器转换为主服务器。哨兵模式可以自动实现故障转移和恢复，以及监控和通知等功能，但由于每个哨兵节点都需要与所有 Redis 实例进行通信，因此对网络带宽和延迟要求较高。
• 集群模式：集群模式是 Redis 的一种分布式数据存储方案，可以将数据分散存储在多个 Redis 实例中，并提供数据分片、复制和故障转移等功能。集群模式可以提供高并发和海量数据存储的能力，但需要对数据进行分片和路由等处理，且需要保证数据的一致性和可靠性。

综上所述，主从模式适用于读写分离、故障恢复和容错等场景，哨兵模式适用于高可用和自动故障转移等场景，集群模式适用于分布式存储和高并发等场景。在实际应用中，可以根据具体需求选择合适的模式或组合使用