Redis基础核心、数据结构、过期策略&内存淘汰、持久化机制、高可用机制面试题

一、Redis基础核心（必问，基础岗重点）

1. 请详细说说Redis是什么？它的核心特性有哪些？为什么单线程还能这么快？

核心答案：Redis（Remote Dictionary Server）是一款基于内存的开源key-value型NoSQL数据库，支持多种数据结构，主打高性能、高可用、可扩展，广泛用于缓存、计数器、分布式锁、消息队列等场景。

原理解析：

1. 核心特性：

• 基于内存：所有操作均在内存中完成，读写延迟极低（微秒级），远超磁盘数据库（毫秒级）；

• 多数据结构支持：除了基础的String，还支持Hash、List、Set、ZSet等多种高级结构，满足不同业务场景；

• 持久化：支持RDB和AOF两种持久化机制，避免内存数据丢失；

• 高可用：支持主从复制、哨兵模式、集群模式，保证服务不宕机；

• 非阻塞IO：采用IO多路复用模型，高效处理大量并发连接；

• 单线程命令执行：避免多线程切换和锁竞争的开销。

2. 单线程快的核心原因（重中之重）：

• 纯内存操作：内存读写速度远快于磁盘，这是Redis快的最根本原因，CPU几乎不会成为瓶颈；

• 单线程模型：Redis的命令执行是单线程的，无需处理多线程切换的上下文开销，也无需担心死锁、锁竞争问题，简化实现的同时提升效率；

• IO多路复用：采用epoll（Linux）、kqueue（BSD）等IO多路复用技术，一个单线程可以同时监听多个客户端连接，实现“一个线程处理多个请求”，避免阻塞在单个IO操作上；

• 高效的数据结构：底层自定义了SDS（字符串）、跳表、压缩列表等数据结构，优化了读写性能（比如SDS的O(1)获取长度、跳表的O(logN)查找）；

• C语言实现：C语言接近操作系统底层，指令执行效率高，无虚拟机开销。

扩展补充：

• Redis 6.0+ 引入了多线程IO，但命令执行依然是单线程：多线程仅用于处理网络读写（接收客户端请求、返回响应结果），目的是解决高并发场景下网络IO的瓶颈，进一步提升吞吐量；

• 单线程的局限性：无法利用多核CPU，因此生产环境中通常会部署多个Redis实例，充分利用多核资源；

• 误区：“单线程=并发差”，Redis单线程通过IO多路复用，能轻松支撑10万+ QPS（每秒查询数），远超普通数据库。

---

2. Redis为什么选择单线程？后期引入多线程IO的原因是什么？

核心答案：Redis初期选择单线程，是为了规避多线程的开销；后期引入多线程IO，是为了解决高并发场景下网络IO的瓶颈，进一步提升吞吐量。

原理解析：

1. 选择单线程的原因：

• 内存操作的CPU开销极低：Redis的核心操作是内存读写，耗时极短（微秒级），CPU不是性能瓶颈，多线程带来的“切换开销”远大于“并行收益”；

• 简化实现：单线程无需处理线程切换、死锁、锁竞争（如惊群效应）等问题，开发和维护成本低，代码逻辑更清晰；

• 无锁设计：单线程天然避免了多线程下的锁竞争，减少了资源消耗，提升了并发安全性。

2. Redis 6.0+ 引入多线程IO的原因：

• 瓶颈转移：随着并发量提升，网络IO（接收请求、返回响应）成为新的瓶颈——单线程处理网络IO时，会出现“读取请求耗时久”“返回响应阻塞”的问题，导致CPU空闲但吞吐量上不去；

• 多线程IO的设计：仅将“网络读写、协议解析”交给多线程处理，“命令执行、内存操作”依然保持单线程，既解决了网络IO瓶颈，又保留了单线程无锁的优势；

• 线程数量：默认开启4个IO线程（可通过配置调整），数量不宜过多（一般不超过CPU核心数），避免线程切换开销抵消收益。

扩展补充：

• 多线程IO的工作流程：客户端连接请求先被IO线程接收、解析，然后将命令交给主线程执行，执行完成后，再由IO线程将响应结果返回给客户端；

• 对比其他数据库：MySQL、MongoDB等采用多线程模型，是因为它们存在大量磁盘IO，CPU会成为瓶颈，多线程能提升CPU利用率；而Redis的核心是内存操作，无需多线程来提升CPU利用率。

---

3. Redis和Memcached的区别？生产中如何选择？

核心答案：两者都是基于内存的缓存工具，但Redis功能更强大、支持持久化和多数据结构，Memcached更轻量、专注于简单缓存场景；生产中优先选Redis，仅在极简单的字符串缓存场景可考虑Memcached。

原理解析（核心区别） ：

对比维度	Redis	Memcached
数据结构	支持String、Hash、List、Set、ZSet等9种数据结构	仅支持String（需手动序列化复杂数据）
持久化	支持RDB、AOF两种持久化，可避免数据丢失	不支持持久化，重启后数据全部丢失
高可用	支持主从复制、哨兵、集群，可实现高可用	不支持原生高可用，需依赖第三方工具（如Keepalived）
并发能力	单线程命令执行+多线程IO，支持10万+ QPS	多线程模型，支持高并发，但性能略低于Redis
数据大小限制	单个String最大512MB，其他结构无明确限制（受内存影响）	单个key-value最大1MB，适合小数据缓存
适用场景	缓存、计数器、分布式锁、消息队列、排行榜等复杂场景	简单的字符串缓存（如页面缓存、接口结果缓存）

扩展补充：

• 生产选择建议：90%以上的场景优先选Redis，因为其功能强大、可扩展、支持持久化，能满足大多数业务需求；

• 特殊场景选Memcached：如果业务仅需要简单的字符串缓存，且对性能要求极高（无持久化需求），可考虑Memcached，其轻量性带来的 overhead 更低；

• 误区：“Memcached多线程比Redis单线程快”——在高频小数据读写场景，Redis的单线程模型避免了锁竞争，性能反而优于Memcached。

---

二、Redis数据结构（核心重点，所有岗必问）

4. Redis支持哪些数据类型？每种类型的底层实现是什么？使用场景有哪些？（扩展：每种结构的常见命令）

核心答案：Redis支持9种核心数据类型，分别是String、Hash、List、Set、ZSet、Bitmap、HyperLogLog、GEO、Stream；每种类型的底层实现会根据数据量动态切换，以平衡内存和性能。

原理解析（分类型详解） ：

1. String（字符串）

• 底层实现：默认是SDS（简单动态字符串），当字符串是纯数字且长度≤20时，会转为int类型存储（节省内存）；

• 核心原理：SDS是Redis自定义的字符串结构，替代了C语言字符串，解决了C字符串的痛点（如O(1)获取长度、杜绝缓冲区溢出）；

• 使用场景：缓存（如用户信息、接口结果）、计数器（如文章阅读量、点赞数）、分布式锁（SET NX PX）、Session共享、限流（incrby）；

• 常见命令：set、get、incr、decr、append、strlen、setnx、setex。

2. Hash（哈希）

• 底层实现：数据量小时（字段数≤512且单个字段值≤64字节）用压缩列表（ziplist），数据量大时转为哈希表（dict）；

• 核心原理：压缩列表是一种紧凑的内存结构，将多个键值对紧凑存储在连续内存中，节省空间；哈希表采用“数组+链表”结构，解决哈希冲突；

• 使用场景：存储对象（如用户信息、商品详情），无需序列化整个对象，可单独操作某个字段（如修改用户昵称）；

• 常见命令：hset、hget、hmset、hmget、hdel、hlen、hkeys、hvals、hexists。

3. List（列表）

• 底层实现：数据量小时用压缩列表（ziplist），数据量大时转为双向链表（linkedlist）；Redis 3.2+ 后统一用quicklist（双向链表+压缩列表的结合体），兼顾性能和空间；

• 核心原理：quicklist将双向链表的每个节点替换为压缩列表，既减少了链表的内存开销，又保留了链表的高效插入/删除性能；

• 使用场景：消息队列（简单FIFO队列）、关注列表、最新消息列表、栈（lpush+lpop）、队列（lpush+rpop）；

• 常见命令：lpush、rpush、lpop、rpop、lrange、llen、lrem、lindex。

4. Set（无序集合）

• 底层实现：数据量小时用压缩列表（ziplist），数据量大时转为哈希表（dict）；

• 核心原理：基于哈希表实现，key是集合元素，value是null，保证元素唯一（哈希表的key不可重复）；支持交集、并集、差集操作；

• 使用场景：去重（如用户签到记录）、共同好友、点赞/收藏、标签（如文章标签）；

• 常见命令：sadd、srem、smembers、sismember、scard、sinter（交集）、sunion（并集）、sdiff（差集）。

5. ZSet（有序集合）

• 底层实现：数据量小时用压缩列表（ziplist），数据量大时转为跳表（skiplist）+ 哈希表（dict）；

• 核心原理：跳表是一种有序数据结构，通过“多层索引”实现O(logN)的查找、插入、删除；哈希表用于快速查询元素的分数（score），跳表用于根据分数排序和范围查询；

• 使用场景：排行榜（如游戏积分、文章阅读量）、延时任务（根据score设置过期时间）、权重队列（根据score分配优先级）；

• 常见命令：zadd、zrem、zscore、zrank、zrange、zrevrange、zcount、zincrby。

6. 其他扩展类型（高频补充）

• Bitmap（位图）：底层是字符串（SDS），用bit位存储数据（0/1），节省内存；场景：签到、活跃用户统计、布隆过滤器；命令：setbit、getbit、bitcount、bitop。

• HyperLogLog（基数统计）：底层是字符串，基于概率算法，用于估算集合的基数（不重复元素个数），误差率约0.81%；场景：UV统计、独立访客估算；命令：pfadd、pfcount、pfmerge。

• GEO（地理信息）：底层是ZSet（将经纬度转为score），支持地理坐标存储和距离计算；场景：附近的人、附近门店、地理围栏；命令：geoadd、geodist、georadius、geohash。

• Stream（消息队列）：底层是链表，支持持久化、消费组、消息确认，解决了List作为消息队列的痛点（无确认机制、无消费组）；场景：可靠消息队列、异步通信；命令：xadd、xread、xgroup、xack。

扩展补充：

• 底层切换阈值：Redis会根据“数据量大小”“元素个数”动态切换底层实现，核心目的是“节省内存+提升性能”；例如Hash的压缩列表切换阈值（hash-max-ziplist-entries=512，hash-max-ziplist-value=64）可通过配置修改；

• 注意事项：避免使用List作为高可靠消息队列（无消息确认、易丢失），优先用Stream或专业消息队列（RocketMQ、Kafka）；HyperLogLog仅用于估算，不适合精确统计场景。

---

5. SDS（简单动态字符串）是什么？和C语言字符串相比，有哪些优势？底层结构是怎样的？

核心答案：SDS是Redis自定义的字符串结构，用于替代C语言字符串，解决了C字符串的诸多痛点，是Redis所有字符串操作的底层基础。

原理解析：

1. C语言字符串的痛点（为什么Redis不用C字符串）：

• 无法O(1)获取长度：C字符串以“\0”作为结束标志，获取长度需遍历整个字符串，时间复杂度O(N)；

• 缓冲区溢出：当修改字符串时（如append），若未提前分配足够内存，会导致数据溢出，覆盖相邻内存；

• 内存重分配频繁：修改字符串长度时，需频繁分配/释放内存（如append短字符串，每次都要扩容），开销大；

• 不支持二进制安全：C字符串以“\0”结束，无法存储包含“\0”的二进制数据（如图片、视频）；

• 功能单一：仅支持简单的字符串操作，无法满足Redis的复杂需求。

2. SDS的底层结构（Redis 3.2+ 版本，分3种类型，适配不同长度）：

核心结构（简化版）：

struct sdshdr {
    int len;      // 已使用的字节数（字符串长度），O(1)获取
    int free;     // 未使用的字节数（剩余空间）
    char buf[];   // 存储字符串的字节数组，末尾自动添加\0（兼容C函数）
};

• 不同长度的SDS类型：

• sdshdr8：len和free用8位（1字节）存储，适合长度≤255的字符串；

• sdshdr16：len和free用16位（2字节）存储，适合长度≤65535的字符串；

• sdshdr32：len和free用32位（4字节）存储，适合长度较大的字符串；

目的：根据字符串长度选择合适的结构，节省内存（短字符串用更少的字节存储len和free）。

3. SDS的核心优势（对比C字符串）：

• O(1)获取长度：通过len字段直接获取，无需遍历；

• 杜绝缓冲区溢出：修改字符串时，会先检查free空间，不足则自动扩容，再执行修改；

• 减少内存重分配：采用“空间预分配”和“惰性释放”策略；

• 空间预分配：append操作时，若free不足，会分配比实际需要更多的空间（如len≤1MB时，扩容到len*2；len>1MB时，扩容到len+1MB），减少后续append的扩容次数；

• 惰性释放：删除字符串时，不立即释放内存，而是将free字段增加，后续可直接复用，避免频繁分配/释放；

• 二进制安全：buf数组存储的是字节流，不依赖“\0”结束，可存储任意二进制数据（如图片、视频）；

• 兼容C函数：末尾自动添加“\0”，可直接调用C语言的字符串函数（如strlen、strcpy），无需额外适配。

扩展补充：

• SDS的内存开销：比C字符串多了len和free两个字段，属于“空间换时间”，但Redis通过动态类型（sdshdr8/16/32）将开销降到最低；

• 应用场景：Redis中所有字符串相关的操作（String类型、Hash的字段值、List的元素等），底层都是SDS实现。

---

6. ZSet底层为什么用跳表（SkipList），而不用红黑树？跳表的原理是什么？

核心答案：ZSet底层选择跳表，是因为跳表的实现更简单、区间查询效率更高，且能满足ZSet“有序+快速插入/删除/查询”的核心需求；红黑树虽然查询效率相当，但实现复杂、区间查询性能不如跳表。

原理解析：

1. 跳表（SkipList）的核心原理：

• 跳表是一种“有序链表+多层索引”的结构，底层是一个有序的双向链表，每个节点除了存储数据和指针，还会随机生成一个“层数”（1~maxLevel），层数越高，节点越少；

• 索引层级：最底层（第1层）是完整的有序链表，第2层索引是第1层的子集（每隔1个节点取一个），第3层索引是第2层的子集，以此类推，最高层索引只有少数几个节点；

• 查找过程：从最高层索引开始，依次比较节点，若当前节点小于目标值，则向右移动；若大于目标值，则向下移动，直到找到目标节点（或底层链表遍历结束）；时间复杂度平均O(logN)，最坏O(N)；

• 插入/删除过程：先找到插入/删除位置，然后创建/删除节点，调整索引层级（随机生成层数），维护链表的有序性；时间复杂度平均O(logN)。

2. ZSet中跳表的应用：

• ZSet需要同时支持“根据元素查询分数”和“根据分数范围查询元素”，因此采用“跳表+哈希表”的组合；

• 跳表：存储元素和分数，保证有序，支持范围查询（如zrange、zrevrange）和根据分数排序；

• 哈希表：key是元素，value是分数，支持O(1)的元素查询（如zscore）；

• 两者数据同步：插入/删除元素时，同时更新跳表和哈希表，保证数据一致性。

3. 选择跳表而非红黑树的原因（核心对比）：

• 实现难度：跳表的实现比红黑树简单得多，红黑树需要维护“红黑规则”（平衡操作），代码复杂，易出错；Redis追求简洁高效，跳表更符合需求；

• 区间查询效率：跳表支持更高效的区间查询（如查询分数在[100,200]之间的元素），只需找到区间的起始节点，然后遍历底层链表即可；红黑树的区间查询需要中序遍历，效率更低；

• 并发性能：跳表的插入/删除操作仅影响局部节点和索引，锁粒度小，适合高并发场景；红黑树的平衡操作会影响多个节点，锁粒度大；

• 性能相当：跳表和红黑树的平均查询、插入、删除时间复杂度都是O(logN)，能满足ZSet的性能需求。

扩展补充：

• 跳表的随机性：跳表的节点层数是随机生成的（默认maxLevel=32），通过随机层数保证跳表的平衡性，避免出现“索引失效”的情况；

• 其他应用场景：跳表除了用于Redis的ZSet，还用于LevelDB、RocksDB等数据库的底层索引；

• 误区：“跳表的性能不如红黑树”——在实际应用中，跳表的性能和红黑树相当，且实现更简单，更适合Redis的场景。

---

三、Redis过期策略 & 内存淘汰（高频必问，中级岗重点）

7. Redis的过期键删除策略有哪些？为什么要采用“三种策略组合”？

核心答案：Redis采用“惰性删除+定期删除+内存淘汰机制”三种策略组合，目的是平衡CPU开销和内存开销，既避免过期键占用过多内存，又避免删除操作消耗过多CPU资源。

原理解析（分策略详解） ：

1. 惰性删除（Lazy Eviction）

• 核心逻辑：不主动删除过期键，只有当客户端访问该键时，才检查该键是否过期；若过期，则删除该键，返回nil；若未过期，则正常返回值；

• 优点：CPU开销极低，只在访问时才执行删除操作，不浪费CPU资源；

• 缺点：内存开销大，过期键如果长期不被访问，会一直占用内存，导致“内存泄漏”（比如大量过期的缓存key堆积）；

• 适用场景：所有过期键的基础删除策略，避免CPU无效消耗。

2. 定期删除（Periodic Eviction）

• 核心逻辑：Redis每隔一段时间（默认每秒10次，可通过配置修改），随机抽取一批过期键进行检查，若过期则删除；

• 具体实现：

• 每次随机抽取100个过期键，删除其中已过期的；

• 若删除的过期键占比超过25%，则继续抽取下一批，直到删除占比≤25%或抽取次数达到上限；

• 频率控制：每秒执行10次，每次执行时间不超过1毫秒，避免阻塞主线程；

• 优点：平衡CPU和内存开销，定期清理一部分过期键，减少内存堆积；

• 缺点：无法保证所有过期键都被及时删除（随机抽取，可能有漏网之鱼），仍可能存在部分过期键占用内存；

• 扩展：定期删除的频率（hz配置）和每次抽取的数量，可根据业务场景调整（如高内存压力场景，可提高hz）。

3. 内存淘汰机制（Memory Eviction）

• 核心逻辑：当Redis的内存使用量达到“maxmemory”（最大内存限制）时，触发内存淘汰机制，删除部分键（无论是否过期），释放内存；

• 触发条件：内存使用量 ≥ maxmemory，且有新的写命令请求；

• 作用：解决“惰性删除+定期删除”无法彻底清理内存的问题，避免Redis因内存满而报错；

• 注意：若内存满且无符合条件的淘汰键（如配置为noeviction），Redis会拒绝所有写命令，返回OOM错误。

4. 三种策略组合的原因：

• 单独使用惰性删除：内存会持续堆积，最终导致OOM；

• 单独使用定期删除：若频率过高，消耗过多CPU；若频率过低，内存堆积严重；

• 单独使用内存淘汰：无需删除过期键，但会误删未过期的有用键，影响业务；

• 组合使用：惰性删除负责“访问时清理”，定期删除负责“主动清理一部分”，内存淘汰负责“内存满时兜底”，三者结合，既保证CPU高效，又保证内存不堆积。

扩展补充：

• 过期键的存储：Redis会将所有设置了过期时间的键，单独存储在一个“过期字典”中，定期删除时，从这个字典中随机抽取键进行检查；

• 过期键的删除顺序：惰性删除和定期删除，都是删除“已过期”的键；内存淘汰机制，会根据配置的策略，删除“符合条件”的键（可能过期，也可能未过期）。

---

8. Redis的内存淘汰策略有哪些？每种策略的适用场景是什么？生产中如何选择？

核心答案：Redis共有8种内存淘汰策略，分为“不淘汰”“淘汰过期键”“淘汰所有键”三大类；生产中需根据业务场景（是否有过期键、缓存命中率、数据重要性）选择合适的策略。

原理解析（8种策略详解） ：

先明确两个分类维度：

• 按淘汰范围：volatile（仅淘汰设置了过期时间的键）、allkeys（淘汰所有键，无论是否设置过期时间）；

• 按淘汰规则：lru（最近最少使用）、lfu（最不经常使用）、random（随机）、ttl（即将过期）。

8种策略具体说明：

1. noeviction（默认策略）

• 核心：不淘汰任何键，当内存满时，拒绝所有写命令（读命令正常执行），返回OOM错误；

• 适用场景：数据极其重要，不允许丢失任何数据，且内存足够（如缓存不可丢失的核心配置）；

• 注意：生产中很少用，除非能保证内存永远不会满。

2. volatile-lru（常用）

• 核心：仅淘汰“设置了过期时间”的键中，最近最少使用（LRU）的键；

• 适用场景：有过期时间的缓存场景（如用户会话、临时数据），希望保留最近使用的缓存，淘汰长期未使用的过期缓存；

• 优点：避免淘汰未过期的有用键，仅清理过期的冷数据。

3. allkeys-lru（常用）

• 核心：淘汰所有键（无论是否设置过期时间）中，最近最少使用（LRU）的键；

• 适用场景：无过期时间的缓存场景（如商品详情缓存），缓存命中率优先，希望保留最近使用的缓存，淘汰冷数据；

• 优点：缓存命中率最高，适合大多数缓存场景。

4. volatile-lfu（Redis 4.0+ 新增）

• 核心：仅淘汰“设置了过期时间”的键中，最不经常使用（LFU）的键；

• 适用场景：有过期时间，且希望淘汰“访问频率低”的缓存（如冷门商品缓存），避免LRU误淘汰“访问一次但长期有用”的键；

• 优势：解决LRU的弊端（如一个键只访问一次，但很久没被访问，LRU会保留，而LFU会淘汰）。

5. allkeys-lfu（Redis 4.0+ 新增）

• 核心：淘汰所有键中，最不经常使用（LFU）的键；

• 适用场景：无过期时间，且缓存访问频率差异大（如热门商品和冷门商品），希望淘汰访问频率最低的冷数据；

• 适用场景：高并发、高访问量的缓存场景，提升缓存利用率。

6. volatile-random

• 核心：随机淘汰“设置了过期时间”的键；

• 适用场景：对缓存命中率要求不高，且希望简单高效（如临时缓存，数据无重要性）；

• 缺点：缓存命中率低，可能淘汰有用的缓存。

7. allkeys-random

• 核心：随机淘汰所有键中的任意一个；

• 适用场景：数据无重要性，且对缓存命中率无要求（如临时存储的无关数据）；

• 缺点：缓存命中率极低，生产中几乎不用。

8. volatile-ttl

• 核心：淘汰“设置了过期时间”的键中，剩余过期时间（TTL）最短的键（即将过期的键）；

• 适用场景：希望优先淘汰即将过期的缓存，保留过期时间较长的缓存（如限时活动缓存）；

• 注意：仅适用于“过期时间差异明显”的场景。

生产选择建议（重点） ：

1. 大多数缓存场景（如商品详情、接口缓存）：优先选 allkeys-lru，缓存命中率最高，适配大多数业务；

2. 有过期时间的缓存（如用户会话、临时数据）：优先选 volatile-lru，避免淘汰未过期的有用键；

3. 高并发、访问频率差异大的场景（如热门商品缓存）：选 allkeys-lfu，淘汰访问频率最低的冷数据，提升缓存利用率；

4. 数据极其重要，不允许丢失：选 noeviction，同时保证内存足够，或配合持久化和集群；

5. 临时缓存、无重要性数据：选 volatile-random，简单高效。

扩展补充：

• LRU和LFU的实现：Redis中的LRU/LFU并非“严格实现”（严格实现需维护有序链表，开销大），而是采用“近似LRU/LFU”（通过随机采样，选择最近最少/最不经常使用的键），平衡性能和准确性；

• 配置方式：通过“maxmemory-policy”配置内存淘汰策略，如config set maxmemory-policy allkeys-lru；

• 注意：若Redis中没有“设置过期时间”的键，volatile-* 系列策略会失效，此时Redis会拒绝写命令（等同于noeviction）。

---

9. LRU和LFU的区别是什么？各自的适用场景？Redis中如何实现近似LRU/LFU？

核心答案：LRU（最近最少使用）基于“时间”维度，淘汰最近一段时间内使用最少的键；LFU（最不经常使用）基于“频率”维度，淘汰一段时间内访问次数最少的键；两者适用场景不同，Redis采用近似实现以平衡性能。

原理解析：

1. LRU和LFU的核心区别（重点）：

对比维度	LRU（Least Recently Used）	LFU（Least Frequently Used）
核心依据	访问时间（最近是否使用）	访问频率（一段时间内访问次数）
核心逻辑	认为“最近没使用的键，未来也不会使用”	认为“访问频率低的键，未来也不会频繁使用”
解决的问题	淘汰长期未使用的冷数据	淘汰访问次数少的冷数据，解决LRU的弊端
弊端	可能误淘汰“访问一次但长期有用”的键（如每月访问一次的核心数据）	可能淘汰“过去访问频繁但现在不常用”的键（需结合时间衰减）
适用场景	访问频率相对均匀，无明显冷热差异（如普通接口缓存）	访问频率差异大，有明显热门/冷门数据（如商品缓存）

2. 举例说明（直观理解）：

• LRU场景：有3个键A、B、C，访问顺序为A→B→C→A→B，此时内存满，需淘汰一个键；LRU会淘汰C（最近最少使用）；

• LFU场景：有3个键A、B、C，访问次数分别为A:10次、B:5次、C:1次，此时内存满，LFU会淘汰C（访问频率最低）；若A过去访问频繁，最近1个月未访问，LFU会逐渐降低其频率，最终可能淘汰A。

3. Redis中近似LRU的实现：

• 严格LRU：需维护一个有序链表，每次访问键时，将其移到链表头部，淘汰时删除链表尾部；但维护有序链表的开销大（插入/删除O(N)），不适合高并发场景；

• 近似LRU：Redis在每个键的元数据中，记录一个“最后访问时间戳（lru）”；

• 当触发内存淘汰时，随机抽取N个键（默认5个，可通过配置修改）；

• 从这N个键中，淘汰“最后访问时间戳最早”的键；

• 抽取的数量越多，越接近严格LRU，但CPU开销越大；Redis默认抽取5个，平衡性能和准确性。

4. Redis中近似LFU的实现（Redis 4.0+）：

• 每个键的元数据中，记录一个“频率计数器（lfu）”和“最后访问时间戳”；

• 频率计数器：访问一次，计数器加1，但会随时间衰减（长时间未访问，计数器减少）；

• 衰减机制：每次访问时，若距离上一次访问时间过久，计数器会按比例减少，避免“过去频繁访问但现在不常用”的键被保留；

• 淘汰逻辑：触发内存淘汰时，随机抽取N个键，淘汰“频率计数器最小”的键；若计数器相同，淘汰最后访问时间最早的键。

扩展补充：

• LFU的参数配置：可通过“lfu-log-factor”（频率增长因子）和“lfu-decay-time”（衰减时间）调整LFU的行为；

• 生产建议：若业务中存在“访问频率差异大”的场景，优先选LFU；若访问频率均匀，选LRU即可；

• 误区：“LFU一定比LRU好”——LFU的优势在于解决LRU的弊端，但实现更复杂，且在访问频率均匀的场景下，性能和LRU无差异。

四、Redis持久化机制（高频必问，中级/高级岗重点）

1. Redis的持久化机制有哪些？RDB和AOF的原理、区别、优缺点分别是什么？生产中如何选择？

核心答案：Redis支持两种持久化机制——RDB（快照持久化）和AOF（日志持久化）；RDB是定时生成内存快照，AOF是记录每一条写命令，两者各有优缺点，生产中通常结合使用（RDB做全量备份，AOF做增量备份），兼顾恢复速度和数据安全性。

原理解析（分机制详解） ：

1. RDB（Redis Database Backup，快照持久化）

• 核心原理：在指定的时间间隔内，将Redis当前的内存数据以“二进制快照”的形式写入磁盘（生成.rdb文件），Redis重启时，加载.rdb文件，将二进制数据直接写入内存，快速恢复数据。

• 触发方式（三种，重点掌握）：

• 手动触发：执行save命令（同步执行，会阻塞主线程，不推荐生产使用，可能导致Redis无法响应客户端请求）、bgsave命令（异步执行，fork子进程负责生成快照，主进程继续处理客户端请求，推荐生产使用）；

• 自动触发：通过配置文件设置“save 时间窗口 改动次数”，核心是“在指定时间内，数据改动达到指定次数，自动执行bgsave”，例如：

• save 900 1：900秒（15分钟）内有1次数据改动，自动执行bgsave；

• save 300 10：300秒（5分钟）内有10次数据改动，自动执行bgsave；

• save 60 10000：60秒内有10000次数据改动，自动执行bgsave；

• 被动触发：主从复制时，主节点会自动执行bgsave，生成RDB文件发送给从节点，用于从节点初始化数据；Redis正常shutdown时，若未开启AOF，会执行save命令生成RDB文件，避免数据丢失。

• 执行流程（bgsave，重点）：

1. 主进程执行bgsave命令，调用fork()函数创建一个子进程（此时主进程会阻塞一瞬间，阻塞时间取决于内存大小，内存越大，页表复制耗时越长）；

2. 主进程fork完成后，立即恢复处理客户端请求，不阻塞；

3. 子进程遍历主进程的内存数据，将数据以二进制形式写入临时RDB文件；

4. 子进程写入完成后，用临时RDB文件替换旧的RDB文件（原子操作，避免文件损坏）；

5. 子进程退出，主进程记录快照完成日志。

• 优点：

• 文件体积小：二进制压缩存储，占用磁盘空间远小于AOF文件，便于备份、传输（如跨机房备份、异地容灾）；

• 恢复速度快：加载RDB文件是直接将二进制数据写入内存，无需执行任何命令，恢复速度比AOF的“命令重放”快10倍以上；

• 性能影响小：bgsave是异步执行，主进程不阻塞，仅fork子进程时会有短暂阻塞，对Redis正常服务影响极小。

• 缺点：

• 数据丢失风险高：只能恢复到上一次快照的时间点，若Redis宕机（如断电、崩溃），会丢失“上一次快照到宕机前”的所有数据；例如配置save 60 10000，若60秒内有5000次改动，宕机后这5000次数据全部丢失；

• fork子进程开销：fork子进程时，会复制主进程的内存页表（并非复制整个内存，采用写时复制技术），但内存越大，fork耗时越长，可能导致主进程短暂阻塞（毫秒级到秒级），高并发场景下可能影响服务稳定性；

• 不适合实时持久化：快照是定时生成，无法实现“每一条数据都持久化”，不适合对数据一致性要求极高的场景。

2. AOF（Append Only File，日志持久化）

• 核心原理：Redis每执行一条写命令（如set、hset、incr等），都会将该命令以“文本格式”追加到AOF文件末尾，Redis重启时，会逐行执行AOF文件中的所有写命令，重建内存数据，实现数据恢复。

• 触发方式（重点）：

• 开启AOF：需在Redis配置文件中设置appendonly yes（默认no），开启后，所有写命令都会被记录到AOF文件；

• 命令追加：每执行一条写命令，Redis会先将命令写入AOF缓冲区（避免频繁写入磁盘，提升性能），再由缓冲区同步到磁盘（同步策略可配置）。

• AOF同步策略（三种，核心考点）：

• appendfsync always：每执行一条写命令，立即将缓冲区的数据同步到磁盘（同步写入）；优点是数据安全性最高，几乎不丢失数据；缺点是IO开销极大，频繁写入磁盘会导致Redis性能下降，适合对数据一致性要求极高的场景（如金融场景）；

• appendfsync everysec（默认策略）：每秒将AOF缓冲区的数据同步到磁盘；优点是平衡性能和数据安全性，最多丢失1秒内的数据；缺点是极端情况下（如每秒内Redis宕机），会丢失1秒数据，适合大多数生产场景；

• appendfsync no：Redis不主动同步，由操作系统负责将缓冲区的数据同步到磁盘（操作系统默认每隔30秒同步一次）；优点是IO开销最小，性能最好；缺点是数据丢失风险极高，可能丢失30秒内的数据，不推荐生产使用。

• AOF文件重写（重点，解决AOF文件过大问题）：

• 核心原因：AOF文件会记录每一条写命令，长期运行后，文件会变得极大（如几十GB、上百GB），导致加载速度慢、占用磁盘空间多，因此需要定期重写AOF文件，压缩文件体积；

• 重写原理：并非对原有AOF文件进行压缩，而是遍历当前Redis内存中的所有数据，将其转化为“一条命令对应一个数据”的格式，写入新的AOF文件，替换旧的AOF文件；例如：多次执行incr key，会被重写为set key 最终值，减少大量冗余命令；

• 触发方式：

• 手动触发：执行bgrewriteaof命令（异步执行，fork子进程，不阻塞主进程）；

• 自动触发：通过配置文件设置重写阈值，例如：

• auto-aof-rewrite-percentage 100：当AOF文件大小达到上次重写后大小的2倍（100%）时，自动触发重写；

• auto-aof-rewrite-min-size 64mb：当AOF文件大小达到64MB以上时，才会触发自动重写（避免小文件频繁重写）。

• 优点：

• 数据安全性高：可配置同步策略，最多丢失1秒内的数据（默认策略），极端情况下可实现无数据丢失（always策略），远优于RDB；

• 可恢复性强：AOF文件是文本格式，可直接编辑，若误操作（如执行flushall），可通过编辑AOF文件，删除误操作命令，实现数据恢复；

• 无fork子进程开销（重写除外）：日常命令追加仅写入缓冲区，同步到磁盘的开销较小，无需fork子进程，对主进程影响小。

• 缺点：

• 文件体积大：文本格式存储，相同数据量下，AOF文件体积是RDB文件的2-5倍，占用更多磁盘空间；

• 恢复速度慢：重启时需逐行执行AOF文件中的所有命令，数据量越大，恢复速度越慢，远不如RDB；

• 重写开销：bgrewriteaof命令会fork子进程，内存越大，fork耗时越长，可能导致主进程短暂阻塞；且重写过程中，Redis会将新的写命令写入临时缓冲区，重写完成后同步到新的AOF文件，有一定的性能开销。

3. RDB和AOF的核心区别（表格对比，面试必背）

对比维度	RDB	AOF
核心原理	定时生成内存快照（二进制）	记录每一条写命令（文本）
文件体积	小（二进制压缩）	大（文本格式，冗余命令多）
恢复速度	快（直接加载二进制数据）	慢（逐行执行命令）
数据丢失风险	高（丢失上次快照到宕机前的数据）	低（最多丢失1秒，可配置无丢失）
性能影响（日常）	小（仅fork子进程时短暂阻塞）	中（同步磁盘有IO开销）
适用场景	灾难恢复、全量备份	实时持久化、数据一致性要求高的场景

4. 生产选择建议（重点，面试高频提问）

• 场景1：对数据一致性要求极高（如金融、支付）：开启AOF，配置appendfsync always，同时开启RDB，每天凌晨执行bgsave做全量备份，兼顾数据安全和灾难恢复；

• 场景2：大多数生产场景（如电商、接口缓存）：开启AOF（默认everysec策略）+ RDB，AOF保证数据少丢失，RDB用于快速恢复和全量备份，避免AOF文件过大导致恢复缓慢；

• 场景3：对性能要求极高，数据可容忍一定丢失（如临时缓存）：仅开启RDB，配置合理的save策略，减少持久化对性能的影响；

• 场景4：禁止使用：仅开启AOF（无RDB），避免AOF文件过大，恢复速度极慢；不开启任何持久化，除非数据完全可丢失（几乎无此类场景）。

扩展补充：

• 持久化文件存储：RDB文件默认名为dump.rdb，AOF文件默认名为appendonly.aof，可通过配置文件修改存储路径和文件名；

• 恢复优先级：Redis重启时，若同时开启RDB和AOF，会优先加载AOF文件（因为AOF数据更完整），只有AOF关闭或AOF文件损坏时，才会加载RDB文件；

• AOF文件损坏修复：若AOF文件因宕机等原因损坏，可使用Redis自带的redis-check-aof工具修复，命令：redis-check-aof --fix appendonly.aof；

• 写时复制技术：fork子进程时，主进程和子进程共享内存页表，当主进程修改数据时，会复制该内存页，避免子进程读取到修改后的数据，保证快照的一致性。

---

2. Redis持久化过程中，fork子进程会带来哪些问题？如何解决？

核心答案：Redis持久化（bgsave、bgrewriteaof）时，fork子进程会带来“主进程短暂阻塞”“内存占用增加”“IO压力增大”三个核心问题；可通过优化fork时机、调整内存配置、优化IO等方式解决，避免影响Redis服务稳定性。

原理解析：

1. 核心问题及产生原因

• 问题1：主进程短暂阻塞（最核心问题）

• 原因：fork子进程时，操作系统需要复制主进程的内存页表（记录内存地址映射关系），而非复制整个内存；内存越大，页表越多，复制耗时越长，主进程会被阻塞，无法处理客户端请求；

• 影响：高并发场景下，阻塞时间过长（如超过1秒），会导致客户端请求超时，影响用户体验；

• 举例：Redis内存为10GB，fork子进程可能阻塞10-100毫秒；内存为100GB，可能阻塞1-10秒，严重影响服务。

• 问题2：内存占用增加

• 原因：fork子进程后，主进程和子进程共享内存，但当主进程修改数据时，会触发“写时复制（Copy On Write）”，复制被修改的内存页，导致内存占用临时增加；极端情况下，内存占用可能翻倍（如主进程修改所有数据）；

• 影响：若Redis内存已接近maxmemory（最大内存限制），fork后内存占用增加，可能触发内存淘汰机制，误删有用数据，甚至导致OOM错误。

• 问题3：IO压力增大

• 原因：bgsave需要将内存数据写入RDB文件，bgrewriteaof需要将内存数据写入新的AOF文件，两个操作都会产生大量磁盘IO；同时，主进程正常处理客户端请求，也会产生IO操作，多重IO叠加，导致磁盘IO压力增大；

• 影响：IO瓶颈会导致Redis写命令响应变慢，甚至出现命令阻塞，降低服务吞吐量。

2. 解决方案（生产实战重点）

• 解决“主进程短暂阻塞”：

1. 优化fork时机：选择Redis低峰期（如凌晨2-4点）执行bgsave和bgrewriteaof，避免高并发时阻塞；可通过定时任务（如crontab）执行手动触发命令；

2. 控制Redis内存大小：建议Redis内存不超过10GB，若内存过大，可拆分多个Redis实例（如按业务拆分），减少fork时的页表复制耗时；

3. 优化操作系统配置：关闭内存大页（transparent huge pages，THP），因为大页会增加fork时的复制耗时，命令：echo never > /sys/kernel/mm/transparent_hugepage/enabled（永久生效需修改配置文件）；

4. 使用Redis 6.0+ 版本：Redis 6.0+ 优化了fork机制，引入了“copy-on-write”优化，减少fork时的阻塞时间。

• 解决“内存占用增加”：

1. 合理设置maxmemory：预留足够的内存空间（如Redis内存设置为物理内存的50%-70%），避免fork后内存溢出；

2. 优化持久化策略：避免频繁触发bgsave和bgrewriteaof，调整save策略和AOF重写阈值（如提高auto-aof-rewrite-min-size）；

3. 开启内存淘汰机制：配置合适的内存淘汰策略（如allkeys-lru），当内存不足时，淘汰冷数据，避免OOM。

• 解决“IO压力增大”：

1. 分离持久化文件存储：将RDB和AOF文件存储在独立的磁盘（如SSD），避免和Redis数据目录、系统目录共用磁盘，减少IO竞争；

2. 优化磁盘IO：使用SSD（固态硬盘）替代HDD（机械硬盘），SSD的IO读写速度是HDD的10-100倍，可大幅降低IO耗时；

3. 限制持久化IO速度：Redis 6.0+ 支持配置aof-rewrite-incremental-fsync yes，开启后，重写AOF时会每32MB同步一次磁盘，避免一次性大量IO写入，减轻IO压力；

4. 避免同时执行bgsave和bgrewriteaof：两个操作都会fork子进程，且都会产生大量IO，同时执行会导致内存和IO压力翻倍，可通过脚本控制，避免两者同时执行。

扩展补充：

• 阻塞监控：可通过Redis的info stats命令，查看latest_fork_usec字段，该字段表示最近一次fork子进程的耗时（微秒），若耗时过长（如超过100000微秒，即100毫秒），需优化；

• 写时复制的影响：fork后，主进程修改的数据越多，内存占用增加越多，因此在持久化期间，应尽量减少大量写操作（如批量更新数据），避免内存溢出；

• 云环境优化：若使用云服务器（如阿里云、腾讯云），可选择IO优化型实例，同时将持久化文件存储在云磁盘（如阿里云ESSD），进一步提升IO性能。

---

3. Redis重启时，如何选择加载RDB还是AOF？如果AOF文件损坏，如何恢复数据？

核心答案：Redis重启时，优先加载AOF文件（数据更完整）；若AOF关闭、AOF文件不存在或损坏且无法修复，则加载RDB文件；AOF文件损坏后，可通过Redis自带工具修复，若修复失败，可加载RDB文件恢复数据（会丢失部分数据）。

原理解析：

1. 重启时加载顺序（核心流程，面试必背）

2. Redis启动后，首先检查是否开启AOF（appendonly yes）；

3. 若开启AOF，检查AOF文件是否存在且完整：

• 若AOF文件完整，优先加载AOF文件，执行文件中的所有写命令，重建内存数据；

• 若AOF文件不存在，或存在但损坏且无法修复，则加载RDB文件；

3. 若未开启AOF，检查RDB文件是否存在：

• 若RDB文件存在，加载RDB文件，恢复数据；

• 若RDB文件也不存在，Redis启动后内存为空，无任何数据。

• 核心原因：AOF文件记录每一条写命令，数据完整性优于RDB，因此优先加载AOF；只有AOF无法使用时，才选择RDB，避免数据丢失过多。

2. AOF文件损坏的原因及修复方法（生产实战重点）

• 损坏原因：

• Redis宕机（如断电、崩溃）时，AOF缓冲区的数据未及时同步到磁盘，导致文件末尾缺失命令，文件损坏；

• 磁盘故障（如磁盘损坏、磁盘满），导致AOF文件写入中断，文件损坏；

• 人为误操作（如手动编辑AOF文件，格式错误）。

• 修复步骤（分情况处理）：

情况1：文件轻微损坏（末尾缺失命令）

1. 备份AOF文件（重要，避免修复失败导致数据彻底丢失），命令：cp appendonly.aof appendonly.aof.bak；

2. 使用Redis自带的redis-check-aof工具修复，命令：redis-check-aof --fix appendonly.aof；

3. 修复完成后，启动Redis，Redis会加载修复后的AOF文件，恢复数据（丢失末尾缺失的命令）。

情况2：文件严重损坏（修复失败）

1. 停止Redis服务，备份AOF文件和RDB文件；

2. 尝试用redis-check-aof工具修复，若提示“无法修复”，则放弃AOF文件；

3. 删除损坏的AOF文件（或重命名），确保Redis启动时无法加载AOF；

4. 启动Redis，Redis会加载RDB文件，恢复数据（丢失“上一次RDB快照到AOF损坏前”的所有数据）；

5. 启动后，重新开启AOF（appendonly yes），Redis会重新生成新的AOF文件，后续写命令会正常记录。

6. 数据恢复的注意事项

• 备份优先：无论修复AOF还是加载RDB，都要先备份原有文件，避免操作失误导致数据彻底丢失；

• 数据校验：恢复数据后，需校验核心数据是否完整（如查询关键key、统计数据量），确保恢复成功；

• 预防措施：开启AOF的everysec同步策略，定期备份RDB文件，避免AOF损坏后无法恢复数据；同时定期检查AOF文件完整性，可通过redis-check-aof工具定期校验。

扩展补充：

• AOF文件完整性校验：可通过redis-check-aof工具校验AOF文件是否完整，命令：redis-check-aof appendonly.aof，若文件完整，会提示“OK”；若损坏，会提示损坏位置；

• 混合持久化（Redis 4.0+ 新增）：开启混合持久化（aof-use-rdb-preamble yes），AOF文件的开头会包含RDB格式的快照数据，后续是AOF命令；重启时，先加载RDB部分（快速），再执行AOF命令（补全数据），兼顾恢复速度和数据完整性；

• 混合持久化的优势：解决了AOF恢复慢、RDB数据不完整的问题，是生产中推荐的持久化配置（需Redis 4.0+ 版本）。

---

五、Redis高可用机制（高频必问，高级岗重点）

4. Redis的高可用方案有哪些？主从复制、哨兵模式、集群模式的区别是什么？生产中如何选择？

核心答案：Redis的高可用方案主要有三种——主从复制、哨兵模式、集群模式；主从复制解决“数据备份和读负载均衡”，哨兵模式解决“主节点故障自动切换”，集群模式解决“高并发、高可用、水平扩展”；生产中，中小规模用“主从+哨兵”，大规模用集群模式。

原理解析（分方案详解） ：

1. 主从复制（Master-Slave Replication）

• 核心定义：将一个Redis节点（主节点，Master）的数据，复制到其他多个Redis节点（从节点，Slave），主节点负责写操作，从节点负责读操作，实现“读写分离”和“数据备份”。

• 核心原理（复制流程，面试必背）：

1. 从节点启动时，执行slaveof 主节点IP 主节点端口，向主节点发送同步请求；

2. 主节点收到请求后，执行bgsave命令，生成RDB文件，同时将后续的写命令记录到复制缓冲区（repl buffer）；

3. 主节点将生成的RDB文件发送给从节点，从节点接收后，清空自身内存，加载RDB文件，完成初始化同步；

4. 主节点将复制缓冲区中的写命令，依次发送给从节点，从节点执行这些命令，实现“增量同步”，确保主从数据一致；

5. 后续主节点执行的每一条写命令，都会实时发送给从节点，从节点同步执行，保持主从数据实时一致。

• 核心特点：

• 读写分离：主节点写，从节点读，可提升读吞吐量（如主节点1个，从节点3个，读请求分散到3个从节点）；

• 数据备份：从节点是主节点的副本，主节点故障时，可手动将从节点切换为主节点，避免数据丢失；

• 无自动故障切换：主节点故障后，无法自动切换到从节点，需手动操作，无法实现高可用（这是主从复制的最大弊端）；

• 主节点压力：所有写命令都由主节点处理，主节点成为瓶颈，无法水平扩展写能力。

• 适用场景：中小规模场景，需要数据备份和读负载均衡，且能接受主节点故障后手动切换（如小型项目、测试环境）。

2. 哨兵模式（Sentinel）

• 核心定义：在主从复制的基础上，引入“哨兵节点（Sentinel）”，哨兵节点负责监控主节点和从节点的状态，当主节点故障时，自动将一个从节点切换为主节点，实现“自动故障切换”，解决主从复制的高可用问题。

• 核心组件：

• 主节点（Master）：负责写操作，和主从复制中的主节点一致；

• 从节点（Slave）：负责读操作和数据备份，和主从复制中的从节点一致；

• 哨兵节点（Sentinel）：独立的Redis节点，不存储数据，仅负责监控、故障检测、自动切换；通常部署3个哨兵节点（避免单点故障），哨兵节点之间相互通信，确认主节点状态。

• 核心功能（重点）：

• 监控（Monitoring）：哨兵节点实时监控主节点和从节点的运行状态（如是否在线、是否正常响应）；

• 故障检测（Notification）：当主节点故障时，哨兵节点会检测到故障，并通知其他哨兵节点和应用程序（通过发布订阅机制）；

• 自动故障切换（Failover）：当主节点故障且超过指定时间（默认30秒），哨兵节点会投票选举一个从节点，将其切换为主节点，同时更新其他从节点的配置，让它们成为新主节点的从节点，实现高可用；

• 配置同步（Configuration Provider）：应用程序通过哨兵节点获取主节点的地址，当主节点切换后，哨兵节点会将新主节点的地址同步给应用程序，无需手动修改配置。

• 故障切换流程（面试必背）：

1. 哨兵节点定期向主节点发送PING命令，若主节点连续多次（默认3次）未响应，哨兵节点标记主节点为“主观下线”；

2. 其他哨兵节点也会检测该主节点，若超过半数哨兵节点标记主节点为“主观下线”，则主节点被标记为“客观下线”；

3. 哨兵节点之间投票，选举一个从节点作为新主节点（优先选择复制进度最快、配置最优的从节点）；

4. 哨兵节点向被选举的从节点发送slaveof no one命令，将其切换为主节点；

5. 哨兵节点向其他从节点发送slaveof 新主节点IP 新主节点端口命令，让它们同步新主节点的数据；

6. 故障切换完成，哨兵节点更新配置，通知应用程序新主节点的地址。

• 核心特点：

• 自动故障切换：主节点故障后，无需手动操作，哨兵自动完成切换，实现高可用（RTO≤30秒）；

• 读写分离：继承主从复制的读写分离特性，提升读吞吐量；

• 哨兵高可用：部署多个哨兵节点（推荐3个），避免哨兵节点单点故障；

• 无水平扩展：主节点依然是写操作的瓶颈，无法水平扩展写能力，适合写请求量适中的场景。

• 适用场景：中小规模场景，需要高可用、读写分离，写请求量适中（如电商订单、用户中心），无需水平扩展写能力。

3. 集群模式（Redis Cluster）

• 核心定义：Redis 3.0+ 引入的分布式集群方案，将数据分片存储在多个节点（主节点）上，每个主节点负责一部分数据（槽位），同时每个主节点配备从节点，实现“高可用+水平扩展”，解决主从复制和哨兵模式的写瓶颈问题。

• 核心概念（重点）：

• 槽位（Slot）：Redis集群将所有数据分为16384个槽位（0-16383），每个主节点负责一部分槽位（如3个主节点，每个负责5461个槽位）；

• 主节点（Master）：负责槽位的管理、数据的读写操作，每个主节点至少有一个从节点；

• 从节点（Slave）：负责备份主节点的数据，主节点故障时，自动切换为新主节点，实现高可用；

• 集群通信：节点之间通过Gossip协议通信，交换节点状态、槽位分配等信息，确保集群一致性。

• 核心原理（数据分片+高可用）：

1. 数据分片：客户端写入数据时，Redis会根据key的哈希值（CRC16(key) mod 16384），计算出该key所属的槽位，将数据存储到负责该槽位的主节点；

2. 读写路由：客户端请求会先发送到任意一个节点，该节点根据槽位分配信息，将请求路由到负责该槽位的主节点（读请求可路由到主节点或其从节点，写请求只能路由到主节点）；

3. 高可用：每个主节点配备从节点，当主节点故障时，其从节点会自动切换为新主节点，接管该主节点的所有槽位，确保数据不丢失、服务不中断；

4. 水平扩展：当集群容量不足时，可新增主节点，将原有主节点的部分槽位迁移到新主节点，实现写能力和存储容量的水平扩展。

• 核心特点：

• 水平扩展：支持新增主节点，分散写压力和存储压力，解决主从、哨兵模式的写瓶颈；

• 高可用：每个主节点有从节点，故障自动切换，RTO短，适合高并发场景；

• 数据分片：16384个槽位，可灵活分配，支持大规模数据存储；

• 复杂度高：集群部署、配置、维护难度高于主从和哨兵，需要专业的运维能力；

• 不支持跨槽位操作：如多key的事务、批量操作（如mget、mset），若key分布在不同槽位，会报错，需手动处理。

• 适用场景：大规模场景，高并发、高写入、大数据量，需要水平扩展写能力和存储容量（如电商首页缓存、短视频平台、游戏排行榜）。

4. 三种方案核心区别（表格对比，面试必背）

对比维度	主从复制	哨兵模式	集群模式
核心功能	数据备份、读负载均衡	自动故障切换、高可用、读负载均衡	水平扩展、高可用、数据分片、读写负载均衡
故障切换	手动切换	自动切换	自动切换
写能力扩展	不支持（主节点瓶颈）	不支持（主节点瓶颈）	支持（新增主节点，分片存储）
部署复杂度	低	中	高
适用场景	中小规模、测试环境、无需自动切换	中小规模、需要高可用、写请求适中	大规模、高并发、高写入、大数据量

5. 生产选择建议（重点）

• 小型项目/测试环境：主从复制（简单易部署，满足数据备份和读负载均衡）；

• 中小规模生产环境（写请求适中，需高可用）：主从复制+哨兵模式（推荐3个哨兵节点，1主2从），兼顾高可用和读写分离；

• 大规模生产环境（高并发、高写入、大数据量）：Redis集群（推荐3主3从，或更多主从节点），实现水平扩展和高可用；

• 特殊场景：若写请求极少，仅需数据备份和读负载均衡，可使用主从复制；若需极高可用性（RTO<10秒），可部署更多哨兵节点和从节点。

扩展补充：

• 集群槽位分配：16384个槽位的设计原因：槽位数量适中，既能满足分片需求，又能减少节点之间的通信开销（槽位分配信息较少）；

• 集群容错：Redis集群的容错能力取决于“主节点的从节点数量”，若主节点有1个从节点，主节点故障后，从节点自动切换；若主节点无从节点，主节点故障后，该主节点负责的槽位无法访问，集群不可用；

• 客户端适配：Redis集群需要客户端支持（如Java的JedisCluster、Spring Data Redis），客户端需能识别集群的槽位分配信息，实现请求路由；

• 云Redis：生产中可优先使用云厂商提供的Redis服务（如阿里云Redis、腾讯云Redis），云厂商已封装好主从、哨兵、集群模式，无需手动部署和维护，降低运维成本。