Redis篇

炒鸡蛋学Java

已于 2024-07-22 17:04:13 修改

阅读量760

点赞数 14

文章标签： redis 数据库缓存

于 2023-12-25 16:12:01 首次发布

本文链接：https://blog.csdn.net/qq_43580675/article/details/135191665

版权

数据类型和使用场景

字符串（String）

使用场景：适用于存储简单的键值对数据，如用户会话信息、计数器、缓存等。

实现

SET：SET key value 添加或修改键值对

GET：GET key 根据key获取String类型的value

MSET：MSET key1 value1 key2 value2 批量添加多个String键值对

MGET：MGET key1 key2 根据多个key获取多个String类型的value

INCR：INCR key1 让一个整数的key的value自增1

INCRBY：INCRBY key1 2 让一个整数的key的value自增指定步长

INCRBYFLOAT：INCRBYFLOAT key1 0.5 让一个浮点数的key的value自增指定步长

SETNX：SETNX key value (set name lili nx)添加一个键值对，前提是key不存在，否则不执行

SETEX：SETEX key 10 value (set name jack ex 10)添加一个键值对，并指定有效期

哈希表（Hash）

使用场景：适用于存储对象的字段和值，例如存储用户信息、商品信息等。

实现

HSET key field value：添加或修改hash类型的key的field的value

HGET key field：获取一个hash类型的field的value

HMSET：批量添加多个hash类型key的field的值

HMGET：批量获取多个hash类型key的field的值

HGETALL：（HGETALL key）获取一个hash类型的key的所有的field和value

HKEYS：（HKEYS key）获取一个hash类型的key中所有的field

HVALUES：（HVALUES key）获取一个hash类型的key中所有的value

HINCRBY：（HINCRBY key field 2）让一个hash类型key的field对应的value自增并指定步长

HSETNX：（HSETNX key field value）添加一个hash类型的key的field的值，前提是这个field不存在，否则不执行

列表（List）

使用场景：适用于需要保持顺序的数据，例如消息队列、最新消息列表、动态列表等。

实现

下标从0开始

LPUSH key element1 ...element5：向列表左侧插入一个或多个元素

LPOP key：(LPOP key 1)移除并返回列表左侧的第一个元素，没有则返回null

RPUSH key element：向列表右侧插入一个或多个元素

RPOP key：移除并返回列表右侧的第一个元素，没有则返回null

LRANGE key star end：返回一段角标范围内的所有元素

BLPOP和BRPOP：（BLPOP key 10）与LPOP和RPOP类似，只是如果没有元素时，等待指定时间，而不是直接返回nil

集合（SET）

使用场景：适用于存储唯一值，提供高效的集合操作，例如用户标签、共同好友、点赞用户集合等。

实现

SADD key member1 ...member5：向set中添加一个或多个元素

SREM key member：移除set中指定的元素

SCARD key：返回set中元素的个数

SISMEMBER key member：判断元素member是否在set中

SMEMBERS：(SMEMBERS key)获取set中的所有元素

SINTER key1 key2 ...：求key1和key2的交集

SDIFF key1 key2 ...：求key1和key2的差集只要key1有而key2没有的

SUNION key1 key2 ...：求key1和key2的并集

有序集合（Sorted Set）

使用场景：类似集合，但每个元素都关联一个分数，适用于需要根据分数排序的场景，例如排行榜、带权重的标签等。

实现

下标从0开始

ZADD key sort member：（ZADD student 85 jack 100 lisi）添加一个或多个元素到sorted set ，如果已经存在则更新其sort值。

ZREM key member：（ZREM student jack）删除sorted set中的一个指定元素

ZSCORE key member：（ZSCORE student jack）获取sorted set中的指定元素的score值

ZRANK key member：（ZRANK student jack）获取sorted set中的指定元素的排名（ZREVRANK student jack 求倒序）

ZCARD key：获取sorted set中的元素个数

ZCOUNT key min max：统计score值在给定范围内所有元素的个数

ZINCRBY key increment member：让sorted set中的指定元素自增，步长为指定的increment值

ZRANGE key min max：根据score排序后，获取指定范围内的元素

ZRANGRBYSCORE key min max：根据score排序后，获取指定score范围内的元素

ZDIFF、ZINTER、ZUNION：求差集，交集，并集

缓存更新策略

一、内存淘汰（低一致性需求）

内存不足的时候自动淘汰，下次查询时更新

二、超时淘汰

TTL时间到了就淘汰，下次查询时更新

三、主动更新（高一致性需求）

自己编写业务逻辑，在更新数据库的同时，更新缓存

主动更新有三个策略：

1、由缓存的调用者，在更新数据库的同时更新缓存

2、缓存与数据库合为一个服务，由服务来维护一致性。调用者调用该服务，无需关心一致性问题

3、调用者只操作缓存，由其它线程异步的将缓存数据持久化到数据库，保证一致性

我们选择第一个策略

第一个策略要考虑的三个问题

1、我们选择删缓存而不是更新缓存

如果每次更新数据库都更新缓存，无效的写操作比较多。我们通常选择更新数据库的时候使得缓存失效，等到下次查询时再将数据写入缓存

2、如何保证缓存与数据库操作的原子性

单体系统：将缓存与数据库操作放在一个事务

分布式系统：利用TCC等分布式事务方案

3、先操作缓存还是先操作数据库

答案是先操作数据库，再操作缓存

如果是先操作缓存再操作数据库，线程1是更新数据库的数据，线程2是查询数据。由于写入数据库的时间花费较长，有可能在线程1更新数据库时有新的线程进行查询，此时会导致写入缓存和写入数据库的数据不一致。

当然如果先操作数据库再操作缓存一样会存在问题

例如线程1是查询操作，线程2是更新操作。按照如下的逻辑走下去，缓存是10而数据库是20。既然如此为什么还是现在先操作数据库再操作缓存呢，首先更新数据库的耗时很长，而删除缓存，写入缓存的时间很短，再写入缓存的微秒时间内，突然来了个更新数据库的操作，可能性比较低。所以还是优先选择操作数据库再删除缓存。

当然不排除这种可能性，那么如何解决呢，可以考虑加锁。

如何设计缓存更新策略

1、低一致性需求：使用redis自带的内存淘汰机制

2、高一致性需求：主动更新，并以超时淘汰作为兜底

读操作：缓存命中直接返回

缓存未命中则查询数据库，并写入缓存，设置超时时间

写操作：先写数据库，然后删除缓存

要确保数据库和缓存操作的原子性

缓存穿透

缓存穿透是一直请求一个不存在数据库和redis中的数据，缓存永远不生效，给数据库带来压力。

解决方法

一，通过在redis中缓存空对象

优点：实现简单，维护方便
缺点：有额外的内存消耗
可能导致短期内查询这个数据的不一致（比如数据库突然存入了这个数据）

二、布隆过滤

优点：内存占用少，没有多余的key
缺点：实现复杂，存在误判可能（因为是把数据库的数据通过hash的方式给到过滤器，有可能不同的数据hash的结果一样）

缓存雪崩

同一时间大量缓存的数据同时失效，严重的redis直接宕机，导致大量的请求直接到数据库，带来巨大压力

解决方法

一、给不同的缓存的数据的TTL添加随机值

二、利用redis集群提高服务的可用性

三、给缓存业务添加降级限流策略

四、给业务添加多级缓存

缓存击穿（热点key问题）

热点key问题，一个高并发访问并且缓存重建重建业务较复杂的key突然失效了，无数的请求会在瞬间给服务器带来巨大的压力

解决方法

一、互斥锁

优点：没有额外内存消耗、保证一致性、实现简单

缺点：线程需要等待，性能受影响、可能死锁

二、逻辑过期

优点：线程无需等待，性能好

缺点：不保证一致性、有额外的内存消耗、实现复杂

Redis线程模型

Redis和Memcached的区别?

Redis和Memcached都是流行的内存缓存系统，它们都用于提高数据访问速度和减轻后端数据库的负载。然而，它们在一些方面存在显著的区别：

数据类型：Redis支持更丰富的数据类型，包括字符串、哈希、列表、集合、有序集合等，而Memcached仅支持简单的键值对存储。
数据持久化：Redis支持数据持久化，可以将数据保存到磁盘上，以便在重启后恢复数据。而Memcached没有内置的持久化机制，数据通常是临时存储在内存中的。
内存管理：Redis具有更复杂的内存管理机制，可以对内存进行优化和管理，支持更大的数据集。而Memcached的内存管理相对简单，不支持复杂的内存优化和管理。
复制和集群：Redis支持主从复制和集群模式，可以实现数据的复制和分布式存储，提高了数据的可用性和扩展性。而Memcached在复制和集群方面相对简单，通常需要依靠客户端实现复制和分片。
功能扩展：由于Redis支持更多的数据类型和功能，它可以用作缓存、消息队列、发布订阅系统等多种用途。而Memcached主要用于简单的键值对缓存。

总的来说，Redis在功能和扩展性方面更加丰富和灵活，适用于更多的应用场景；而Memcached则更加专注于简单高效的键值对缓存。

为什么用redis作为MySQL缓存？

使用 Redis 作为 MySQL 缓存有多个优势：

高性能：Redis 是基于内存的缓存系统，读取速度非常快，可以大大减少对数据库的访问次数，从而提高系统的性能和响应速度。
数据结构丰富：Redis 支持丰富的数据结构，包括字符串、哈希、列表、集合、有序集合等，可以更灵活地缓存和处理不同类型的数据。
持久化：Redis 支持数据持久化，可以将缓存数据保存到磁盘上，以便在重启后恢复数据，提高了数据的可靠性和稳定性。
缓存雪崩处理：Redis 支持设置过期时间和自动淘汰策略，能够有效地防止缓存雪崩现象的发生。
分布式缓存：Redis 支持分布式部署，可以构建高可用、高性能的分布式缓存集群，适用于大规模的系统和高并发场景。
发布订阅功能：Redis 支持发布订阅模式，可以用作消息队列系统，适用于一些异步处理和通知场景。

综上所述，Redis具有高性能、丰富的数据结构、持久化、缓存雪崩处理、分布式部署等优点，使其成为一个优秀的缓存选择，可以帮助提高系统性能、减轻数据库负担、增强系统的稳定性和可扩展性。

redis是单线程吗？

Redis 使用单线程模型来处理所有的命令请求，这意味着 Redis 在任意时刻只会执行一条命令，不会进行并行处理。这种设计带来了一些优势和挑战：

优势包括：

简化了并发控制：单线程模型避免了复杂的并发控制问题，简化了系统的设计和实现。
避免了竞态条件：单线程模型避免了多线程并发访问共享资源时可能出现的竞态条件和死锁问题。

挑战包括：

性能瓶颈：单线程模型可能成为系统的性能瓶颈，特别是在大规模并发请求的情况下。
长时间命令的阻塞：如果有一个命令需要长时间执行（比如一个复杂的计算或者大规模的数据操作），会阻塞其他命令的执行。

尽管 Redis 是单线程的，但它通过非阻塞的 I/O、事件驱动等机制来提高性能，并能够处理大量的并发请求。此外，Redis 也支持多个实例部署、集群模式等方式来提高并发处理能力。

redis单线程模式是怎么样的？

Redis 的单线程模式主要基于以下几个关键机制：

事件循环（Event Loop）：Redis 使用事件驱动的方式来处理命令请求。在单线程模式下，Redis 会维护一个事件循环，不断地从网络套接字中读取命令请求，然后执行相应的命令。这种事件驱动模式使得 Redis 能够高效地处理大量的并发请求。
非阻塞 I/O：在单线程模式下，Redis 使用非阻塞的 I/O 操作，这意味着当某个命令需要等待外部资源（如磁盘、网络）时，Redis 并不会阻塞整个线程，而是会继续处理其他可用的命令请求，从而提高了系统的并发处理能力。
内存数据结构和操作：由于 Redis 是基于内存的存储系统，它的数据结构和操作都被设计成非常高效的，这使得 Redis 能够在单线程模式下快速地处理各种数据操作，包括读取、写入、计算、过期等。

总的来说，Redis 的单线程模式通过事件循环、非阻塞 I/O 和高效的数据操作来实现高性能的并发处理能力。虽然在特定场景下可能会受到单线程的限制，但通过合理的设计和部署方式，Redis 仍然能够处理大规模的并发请求。

redis采用单线程为什么这么快？

Redis 采用单线程模型并且仍然能够获得高性能的原因主要有以下几点：

事件驱动和非阻塞 I/O：Redis 使用事件驱动的方式来处理命令请求，配合非阻塞 I/O 操作。这意味着 Redis 能够在等待外部资源时不会阻塞整个线程，而是会继续处理其他命令请求，从而提高了系统的并发处理能力。
基于内存的数据存储：Redis 是基于内存的存储系统，对于读取操作而言，内存访问速度非常快，因此 Redis 能够快速地响应读取请求。
高效的数据结构和操作：Redis 提供了丰富的数据结构（如字符串、哈希、列表、集合、有序集合等）和相应的高效操作，这些操作在单线程模式下能够快速执行。
避免线程切换和锁竞争：单线程模型避免了多线程下的线程切换和锁竞争，从而减少了系统的开销和复杂性。
优化的算法和数据结构：Redis 内部采用了许多优化的算法和数据结构，如使用哈希表来实现键值对存储，使用跳表来实现有序集合等，这些优化使得 Redis 在单线程模式下能够高效地处理各种操作。

总的来说，Redis 通过事件驱动、非阻塞 I/O、内存存储、高效的数据结构和操作等多方面的设计和优化，使得它在单线程模式下仍然能够获得出色的性能表现。当然，在大规模并发请求的情况下，也可以通过多实例部署、集群模式等方式进一步提高 Redis 的并发处理能力。

Redis持久化

redis如何实现数据不丢失？

Redis 可以通过以下方式来实现数据不丢失：

持久化：Redis 提供了两种持久化方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。
- RDB：定期将内存中的数据快照保存到磁盘上，可以通过配置定期保存快照的时间间隔来控制数据的持久化频率。
- AOF：将每条写命令追加到一个文件中，这样可以记录数据的修改操作，当 Redis 重启时可以通过重新执行 AOF 文件中的命令来恢复数据。
主从复制：通过设置 Redis 的主从复制，可以将主节点的数据复制到一个或多个从节点上，从节点可以作为主节点的备份，当主节点发生故障时可以快速切换到从节点来保证数据的可用性。
高可用集群：通过搭建 Redis 高可用集群，可以在多个节点之间分布数据，并设置主从关系，当主节点发生故障时可以自动切换到从节点来保证数据的可用性。
数据备份：定期对 Redis 数据进行备份，将备份数据保存到其他存储介质中，如磁盘、云存储等，以防止数据丢失。
数据冗余：可以通过数据冗余的方式来保证数据的安全，将数据复制到不同的节点或存储介质上，以防一处数据丢失导致数据不可用。

综合利用以上这些方式，可以有效地保证 Redis 中的数据不丢失，并且在发生故障时能够快速地恢复数据。

AOF日志如何实现？

AOF（Append Only File）日志是 Redis 持久化数据的一种方式，它记录了所有对 Redis 服务器执行的写命令，以此来实现数据的持久化。AOF 日志的实现方式如下：

写入操作记录：当客户端执行写入操作（如 SET、INCR 等）时，Redis 不仅会将命令执行在内存数据库上，同时也会将这些写入操作记录在 AOF 文件中。
文件同步：Redis 在执行写入操作后，通过调用系统的文件同步操作，将数据真正写入到 AOF 文件中。文件同步可以使用操作系统提供的文件同步接口，如 fsync()（或者 fdatasync()）来保证数据被持久化到磁盘。
重写日志：为了避免 AOF 日志文件过大，Redis 会定期进行 AOF 日志的重写。重写的过程中，Redis 会分析内存中的数据生成一份最小化的命令副本，从而减小 AOF 文件的体积。
恢复数据：当 Redis 重启时，它会通过重新执行 AOF 文件中的写入操作来恢复数据到内存数据库中，从而实现数据的持久化。

AOF 日志实现的关键在于将所有写入操作都记录在文件中，并且通过文件同步操作来保证数据的持久化。这种方式能够保证即使在发生故障时，Redis 也能够通过 AOF 文件中的记录来恢复数据。

RDB快照是如何实现的？

RDB（Redis DataBase）快照是 Redis 使用的一种持久化方式，它通过定期将内存中的数据快照保存到磁盘上，以此来实现数据的持久化。RDB 快照的实现方式如下：

生成快照：Redis 会周期性地在后台生成数据快照。管理员也可以通过发送 BGSAVE 命令来要求 Redis 立即生成一次数据快照。
创建临时文件：当进行数据快照时，Redis 会创建一个临时的 RDB 文件，并将数据写入到该文件中。
写入数据：在生成数据快照的过程中，Redis 会将内存中的数据写入到临时的 RDB 文件中。
替换原始文件：当数据快照生成完毕后，Redis 会用生成的 RDB 文件覆盖原来的 RDB 文件，这样就完成了一次数据快照的过程。

RDB 快照是通过将内存中的数据写入到磁盘上的文件来实现的。生成的 RDB 文件包含了数据库在某个时间点上的所有数据，因此当 Redis 重启时，可以通过加载 RDB 文件来恢复数据到内存数据库中，从而实现数据的持久化。

为什么有混合持久化？

混合持久化是指在 Redis 中同时使用 RDB 和 AOF 两种持久化方式的机制。这种混合持久化的方式可以充分发挥两种方式的优势，同时弥补各自的不足，从而提高数据的安全性和可靠性。

混合持久化的优势包括：

数据安全：RDB 提供了完整的数据快照，AOF 记录了所有的写命令，两者结合使用可以提供更全面的数据保护，即使其中一种方式出现问题也可以通过另一种方式进行数据恢复。
快速恢复：AOF 可以提供更精确的数据恢复，因为它记录了每一条写命令，而 RDB 则提供了更快速的恢复速度。
故障恢复：当 Redis 重启时，可以优先使用 AOF 日志来进行数据恢复，如果 AOF 文件损坏或不完整，可以使用 RDB 文件来进行恢复。
定期备份：RDB 可以用于定期备份数据，而 AOF 可以记录最近的写入操作，从而实现数据的多重备份。

综合以上优势，混合持久化可以提供更全面和可靠的数据保护机制，同时也能够在恢复数据时提供更快速和精确的恢复方式。因此，混合持久化在保障数据安全和系统可靠性方面具有明显的优势。

Redis集群

redis如何实现服务高可用？

要实现 Redis 服务的高可用性，可以采取以下策略：

主从复制：通过设置 Redis 的主从复制，可以将主节点的数据复制到一个或多个从节点上。当主节点发生故障时，可以将一个从节点提升为新的主节点，从而保证数据的持续可用性。
哨兵模式：Redis 哨兵是一个独立的进程，它可以监控 Redis 主从节点的健康状态。当主节点宕机时，哨兵可以自动将一个从节点晋升为新的主节点，从而实现自动故障转移。
Redis Cluster：Redis 提供了集群模式，可以将数据分片存储在多个节点上，每个节点负责部分数据。这样即使部分节点发生故障，集群仍然可以继续提供服务。
负载均衡：在部署多个 Redis 实例时，可以通过负载均衡器将请求分发到不同的 Redis 实例上，从而分担各个实例的压力，提高整体的可用性和性能。
数据备份与恢复：定期对 Redis 数据进行备份，并建立完善的数据恢复机制，以防止数据丢失导致的不可用情况。
监控和报警：建立完善的监控系统，及时发现并处理 Redis 节点的异常情况，以减少故障对系统的影响。

综合利用以上策略，可以有效地提高 Redis 服务的高可用性，保证系统在发生故障时能够快速地恢复并保持持续的可用性。

集群脑裂导致数据丢失怎么办？

集群脑裂是指在分布式系统中，网络分区导致集群中的不同部分无法相互通信，从而可能导致数据一致性问题和数据丢失。解决集群脑裂导致数据丢失的方法包括以下几个方面：

Quorum机制：可以通过Quorum机制来避免脑裂问题。Quorum是指集群中超过半数节点的投票，只有在得到超过半数节点的认可时，集群才会继续执行操作，否则会暂停对外服务，等待集群重新达成一致。这样可以避免脑裂情况下的数据不一致问题。
数据复制：在分布式系统中，可以使用数据复制的方式来增加数据的冗余度，当出现脑裂导致数据丢失时，可以通过复制的数据进行恢复。
一致性哈希：通过一致性哈希算法来保证在节点动态变化时数据的分布均匀性，减少脑裂的发生。
数据同步和修复：一旦脑裂发生并且恢复之后，需要进行数据同步和修复操作，确保数据的一致性。这可能涉及对数据的比对和合并，以及可能的数据修复操作。
监控和预警：建立完善的监控系统，及时发现集群状态的异常情况，并设置相应的预警机制，以便在脑裂发生时能够及时作出响应。

综合利用以上方法，可以在一定程度上减少集群脑裂导致数据丢失的风险，保障分布式系统的数据一致性和可靠性。

redis过期删除与内存淘汰

reid使用的过期删除策略是什么？

Redis 使用的过期删除策略是惰性删除和定期删除相结合的方式。

惰性删除：当客户端请求访问某个键时，Redis 会先检查这个键是否设置了过期时间，如果该键已经过期，Redis 会立即删除它，并返回 nil 或者空值给客户端。
定期删除：Redis 会创建一个定时器，每隔一段时间（默认是100ms）就随机抽取一部分设置了过期时间的键，检查它们的过期时间，并删除已过期的键。这个删除操作不会阻塞客户端请求。

这种结合了惰性删除和定期删除的策略，可以在保证数据访问速度的情况下，及时删除过期的键，释放内存空间。这种策略可以确保即使某些键未被访问，也能够在过期后被删除，从而避免内存占用过多的情况。

redis持久化时，对过期键会如何处理？

在 Redis 的持久化过程中，对于过期键的处理方式如下：

RDB 持久化：在进行 RDB 持久化时，过期键不会被保存到 RDB 文件中。只有未过期的键才会被写入到 RDB 文件中。因此，当进行数据恢复时，过期键将不会被载入内存数据库中。
AOF 持久化：在进行 AOF 持久化时，过期键的删除操作会被记录到 AOF 日志中。当进行数据恢复时，AOF 文件中的过期键删除操作将会重新执行，从而确保过期键在恢复后不会存在于内存数据库中。

总的来说，在 Redis 的持久化过程中，过期键不会被保存到 RDB 文件中，而在 AOF 日志中会记录过期键的删除操作。这样可以确保在数据恢复时，过期键不会被载入内存数据库中，从而正确地实现了对过期键的处理。

redis主从模式中，对过期键会如何处理？

在 Redis 主从复制模式中，对过期键的处理方式如下：

主节点处理过期键：当在主节点上执行写操作导致键过期时，主节点会记录这个过期键的信息，并将过期键的删除操作同步到从节点上。
从节点处理过期键：从节点会接收主节点发送的删除操作，然后在从节点上执行相同的删除操作，从而使从节点上的数据保持与主节点一致。

总的来说，在 Redis 主从复制模式中，主节点会将对过期键的操作同步到从节点上，从而保持主从节点数据的一致性。当在主节点上的键过期被删除时，相应的过期键删除操作也会被同步到从节点上，这样可以确保主从节点上的数据保持一致。

redis内存满了，会发生什么？

当 Redis 的内存空间快要或已经满了时，会发生以下情况：

写操作失败：当 Redis 的内存空间已经用完时，新的写入操作将会失败，Redis 会返回错误信息，例如 "OOM command not allowed when used memory > 'maxmemory'"。
内存淘汰：如果配置了内存淘汰策略（maxmemory-policy），Redis 会根据策略删除一些键来释放内存空间，常见的策略包括 LRU（最近最少使用）、LFU（最少使用频率）、随机删除等。
持久化失败：如果正在进行持久化操作（如 RDB 或 AOF），内存满了可能会导致持久化操作失败。
性能下降：当内存空间满了以后，Redis 可能会因为频繁的内存淘汰操作或者无法执行写操作而导致性能下降。

因此，为了避免内存满了导致的问题，需要合理设置 maxmemory 参数来限制 Redis 的内存使用，并且根据业务需求和数据特点选择合适的内存淘汰策略。

redis内存淘汰策略有哪些？

Redis 内存淘汰策略用于在内存达到上限时，决定该清除哪些键来释放内存空间。以下是 Redis 常见的内存淘汰策略：

volatile-lru：从设置了过期时间（TTL）的键中，挑选最近最少使用的键进行删除。
volatile-ttl：从设置了过期时间的键中，挑选将要过期的键进行删除，即优先删除TTL时间最小的键。
volatile-random：从设置了过期时间的键中，随机挑选键进行删除。
allkeys-lru：从所有键中，挑选最近最少使用的键进行删除。
allkeys-random：从所有键中，随机挑选键进行删除。

这些策略可以通过配置文件中的 maxmemory-policy 参数进行设置，根据业务需求和数据特点选择合适的内存淘汰策略。

LRU算法和LFU算法有什么区别？

**LRU（最近最少使用）**算法是根据键最近被访问的时间来淘汰的。当缓存空间满时，会淘汰最长时间未被访问的键。LRU算法的实现通常通过维护一个访问顺序链表或者使用有序字典来实现。
**LFU（最不经常使用）**算法是根据键被访问的频率来淘汰的。当缓存空间满时，会淘汰访问频率最低的键。LFU算法的实现通常需要记录每个键被访问的次数，并根据访问次数来进行淘汰决策。

因此，LRU算法关注的是最近的访问情况，而LFU算法关注的是访问频率。

redis如何实现延迟队列？

在 Redis 中实现延迟队列通常可以借助于有序集合（Sorted Set）和发布/订阅（Pub/Sub）功能来实现。下面是一种常见的基于 Redis 的延迟队列实现方式：

使用有序集合（Sorted Set）：将消息的到期时间作为分数，消息内容作为成员，将消息按照到期时间加入有序集合中。这样可以确保有序集合中的成员是按照到期时间进行排序的。
使用发布/订阅（Pub/Sub）：创建一个专门用于处理延迟消息的消费者，订阅延迟队列的消息通道。当有消息的到期时间到达时，发布者向通道发布消息，消费者接收到消息后进行处理。
定时检查有序集合：定时检查有序集合中的成员，如果发现有到期的消息，则将其取出并发送到相应的处理逻辑中进行处理。

通过以上方式，可以利用 Redis 的有序集合和发布/订阅功能实现延迟队列，确保消息可以按照预定的延迟时间被处理。这种方式简单高效，并且能够很好地满足延迟队列的需求。

redis的大key如何处理？

处理 Redis 中的大 key（大对象）通常需要考虑以下几个方面：

避免存储过大的对象：尽量避免在 Redis 中存储过大的对象，因为大对象会占用大量内存，可能导致 Redis 实例的性能下降或者内存消耗过高。如果需要存储大对象，可以考虑拆分成多个小对象进行存储。
使用分布式存储：对于大对象，可以考虑使用分布式存储系统（如分布式文件系统、对象存储等）进行存储，而在 Redis 中存储对象的引用或标识符，从而减轻 Redis 的内存压力。
合理设置过期时间：对于临时性的大对象，可以合理设置过期时间，确保大对象不会长时间占用 Redis 的内存。
定期清理大对象：定期检查和清理 Redis 中的大对象，确保不会长时间占用过多的内存空间。

综合考虑以上因素，可以在一定程度上避免大 key 对 Redis 造成的性能问题和内存压力。同时，根据实际需求和业务场景，合理设计数据存储方案，可以更好地处理大 key 的情况。

redis管道有什么用？

Redis 管道是一种在客户端与服务器之间进行批量操作的机制，它可以在一次网络往返中发送多个命令，并一次性接收多个命令的返回结果。使用管道可以提高批量操作的性能，减少网络延迟对性能的影响。

主要用途包括：

批量写入操作：通过管道可以将多个写入操作发送到 Redis 服务器，减少了每个操作都要进行一次网络往返的开销，提高了写入性能。
批量读取操作：通过管道可以将多个读取操作发送到 Redis 服务器，一次性接收多个命令的返回结果，减少了每个读取操作都要进行一次网络往返的开销，提高了读取性能。
事务操作：管道也可以用于事务操作，将多个命令作为一个事务一次性提交或者回滚。

总之，Redis 管道可以显著提高批量操作的性能，减少了网络延迟对性能的影响，特别适合需要进行大量批量操作的场景。

redis事务支持回滚吗？

Redis 事务支持回滚。Redis 的事务是通过 MULTI、EXEC、DISCARD 和 WATCH 等命令来实现的。在 Redis 中，当使用 MULTI 命令开启一个事务后，之后的命令将被放入队列中，直到执行 EXEC 命令将队列中的命令一次性执行。如果在事务执行过程中出现错误，可以通过使用 DISCARD 命令来取消事务，或者在事务执行后根据需要使用 EXEC 返回执行结果。

在 Redis 中，事务的回滚是通过 DISCARD 命令来实现的。如果在事务执行过程中出现错误或者需要取消事务，可以使用 DISCARD 命令来清空事务队列，从而取消事务中的所有命令。这样就实现了事务的回滚操作。