Redis（1）：对Redis必须知道的7个技术问题

本文链接：https://blog.youkuaiyun.com/code52/article/details/147993112

一、Redis为什么选择单线程架构？

1、规避锁竞争与上下文切换的底层逻辑

在多线程编程中，锁竞争（如互斥锁、读写锁）和线程上下文切换是性能损耗的主要来源。Redis 采用单线程模型，确保所有命令串行原子执行，从根本上避免了多线程环境下的锁冲突和 CPU 调度开销。例如，在实现哈希表、跳表等数据结构时，无需额外添加线程安全逻辑，代码复杂度降低 50% 以上，且操作延迟稳定在微秒级。

2、内存操作的极致性能优势

Redis 作为内存型数据库，数据完全存储于内存中，内存访问速度可达纳秒级，单线程的 CPU 单核处理能力足以支撑每秒数十万次操作（QPS）。实测数据显示，单线程 Redis 在纯内存场景下的 QPS 可达 10 万 +，而引入多线程后，由于线程调度和同步机制的开销，性能反而可能下降 15%-20%。单线程模型让 Redis 能够将更多资源聚焦于命令处理，而非线程管理。

3、简化架构与原子性保障

单线程模型天然保证了操作的原子性 —— 所有客户端请求按顺序执行，无需担心并发安全问题。例如，执行INCR命令时，无需考虑其他线程的干扰，确保计数操作准确无误。这种特性简化了开发者对并发场景的处理逻辑，尤其适合缓存、计数器等高频原子操作场景。

二、Redis 核心应用场景：不止于缓存

Redis 作为高性能内存数据库，其应用场景覆盖互联网业务的多个维度，核心场景包括：

1、高性能缓存场景：存储高频访问的信息，如用户信息、商品详情、API 接口结果等，降低数据库负载。

实现：通过SET key value EX 3600设置缓存过期时间，配合GET/MGET实现毫秒级响应，缓存命中率通常可达 95% 以上。

2、分布式锁场景：解决分布式环境下的资源互斥问题，如库存扣减、分布式任务调度。

实现：使用SET key value NX PX timeout原子指令创建锁，结合 Lua 脚本确保安全释放，避免死锁。

3、实时统计与排行榜场景：统计点赞数、页面访问量（PV），或生成商品销量、用户积分实时排行榜。

实现：INCRBY命令实现计数器（如INCRBY post:1001:pv 1）；Sorted Set 实现排行榜，ZREVRANGE可毫秒级返回 TOP 100 结果。

4、消息队列场景：异步处理订单通知、日志采集等任务，或实现削峰填谷的流量控制。

实现：基于 List 的LPUSH+BRPOP实现阻塞队列，或通过 Stream 数据结构支持持久化消息流。

5、发布/订阅（Pub/Sub）场景：实时推送系统通知、即时消息（IM），或实现微服务间的事件驱动通信。

实现：客户端通过SUBSCRIBE channel订阅频道，其他客户端通过PUBLISH channel msg发布消息。

三、什么是IO 多路复用？单线程如何支撑高并发？

1、多路复用的核心逻辑

传统阻塞 IO 模型中，每个连接对应一个线程，线程会因等待数据而阻塞，导致资源浪费。IO 多路复用通过单线程监听多个文件描述符（FD），仅在 FD 就绪（可读 / 可写）时触发处理。

类比场景：

阻塞模型：餐厅服务员逐桌服务，一桌未完成则无法接待下一桌。
多路复用模型：服务员记录所有桌的需求后，通过 “叫号系统” 实时响应已备餐的桌位，期间可自由处理点单、结账等操作。

2、Epoll 为何成为 Redis 首选？

在 Linux 环境中，Redis 优先采用 Epoll 机制，因其具备三大优势：

红黑树高效管理：通过红黑树存储 FD，添加、删除、查询复杂度为 O (logN)，比 Select/Poll 的 O (N) 数组操作快 10 倍以上。
仅返回就绪 FD：内核通过链表直接返回就绪的 FD 列表，用户态无需遍历全量 FD，在 10 万级连接下，Epoll 的 CPU 利用率比 Select 低 50%。
灵活触发模式：支持水平触发（LT，适合流式处理）和边缘触发（ET，适合高性能场景），适配不同业务需求。

四、Redis实现一个分布式锁

基本实现方式

在使用 Redis 实现分布式锁时，一般先通过 SETNX 命令尝试获取锁。由于 SETNX 命令只有在 key 不存在时才会设置成功，因此可以保证同一时间只有一个客户端能抢到锁。抢到锁后，使用 EXPIRE 命令为锁设置过期时间，以防止因程序异常导致锁未释放，进而产生死锁。

异常情况及应对策略

然而，这种实现方式存在潜在风险。如果在执行 SETNX 后、执行 EXPIRE 之前，进程意外崩溃或需要重启维护，那么这个锁就会一直处于锁定状态，其他客户端无法获取。为解决这一问题，可以将 SETNX 和 EXPIRE 合成一条指令执行。

五、查找大量特定前缀的 Key

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

Keys 命令会阻塞 Redis 服务器，尤其是在 key 数量庞大时，可能导致服务器短暂停顿，影响其他命令的正常执行。此时，应选用 Scan 命令。

Scan 命令采用增量式遍历，可分批次获取部分 key，有效避免一次性获取所有 key 带来的性能问题。而且 Scan 命令提供了 limit 参数，开发者能控制每次返回结果的最大条数，灵活调整获取策略。

六、如果有大量key需要设置同一时间过期，需要注意什么？

当大量 key 被设置在同一时间过期时，我们必须格外小心谨慎。因为在过期的瞬间，Redis 会集中处理这些过期的 key，这可能导致 Redis 出现短暂卡顿。想象一下，Redis 就像是一个忙碌的服务员，平时有条不紊地处理着各种请求，但突然在某一时刻，大量过期 key 的处理任务如潮水般涌来，即便 Redis 性能再强大，也难免会手忙脚乱，出现短暂的 “卡顿” 现象。

为了有效避免这种情况，一个简单而有效的方法是在设置过期时间时加上一个随机值。这样一来，原本集中在同一时刻过期的大量 key，其过期时间就会分散开来。

七、Redis 大 key 和热 key 问题剖析

1、热 key 问题及解决方案

热key指的是被频繁访问（读 / 写）的 key，这种 key 会导致访问集中，使 Redis 某个实例的 CPU 使用率异常升高。常见的解决方案如下：

1）增加本地缓存：将热 key 的数据缓存到本地，减少对 Redis 的直接访问，避免大量请求都集中在 Redis 上。

2）增加 slave 分片并配置读写分离：通过增加从节点并配置读写分离，将读请求分散到多个从节点，降低主节点的压力。

3）拆分 key：把热 key 拆分成多个子 key，如 key_1, key_2 等，分摊访问压力。

4）请求合并：将多个对热 key 的请求合并为一次查询，减少对 Redis 的请求次数，降低分片压力。

2、大 key 问题及解决方案

大 key 指的是 value 值过大的 key，例如一个 Hash 结构包含几百万个 field，或者一个 List 有 10 万项以上，又或者字符串体积超大（如 1MB 以上）。虽然在某些特定场景下，如通过异步定时任务加载到本地缓存作为索引，只要不是极端大，大 key 可能不会引发严重问题。但在一般情况下，可采用以下方法解决：

1）拆分数据结构：比如将大 Hash 拆分成多个小 Hash（按 ID 等方式拆分），减小单个数据结构的规模。

2）控制最大 field 数 / 元素数：限制单个结构体内成员数量，例如控制在≤10K，防止数据过度膨胀。

3）限制最大 value 大小：对于字符串类型，避免其超过几 KB，防止超过 MTU（最大传输单元），影响网络传输性能。

4）对大 Value 进行 Gzip 压缩，减少内存占用和网络传输流量