跳至主要內容

Redis集群详解

JavaJuice数据库Redis约 2483 字大约 8 分钟

Redis 集群高频“学习”题 (30+)

1. Redis 常见的高可用方案有哪些？

  • 主从复制（Master-Slave）：一主多从，主写从读，数据备份。缺点是无法自动故障转移。
  • 哨兵模式（Sentinel）：在主从基础上增加了哨兵节点，负责监控、通知和自动故障转移。
  • Redis Cluster：官方提供的分布式方案，通过分片（Sharding）实现数据分布，支持自动故障转移和在线扩容。

2. 简述 Redis 主从复制的原理？

主要分为全量复制和增量复制：

  1. 全量复制：
    • Slave 发送 PSYNC 命令。
    • Master 执行 BGSAVE 生成 RDB 文件，并缓存后续写命令。
    • Master 发送 RDB 给 Slave，Slave 载入。
    • Master 发送缓冲区的写命令给 Slave。
  2. 增量复制：
    • 连接断开重连后，Slave 发送 offset。
    • Master 检查 offset 是否在复制积压缓冲区（repl_backlog_buffer）内。
    • 若在，则发送 offset 后的数据；若不在，触发全量复制。

3. 什么是复制积压缓冲区（repl_backlog_buffer）？

  • 是一个固定长度的环形队列（默认 1MB）。
  • Master 在进行写操作时，不仅写入复制缓冲区，还会写入这个积压缓冲区。
  • 用于在主从断连后，Slave 重新连接时，尝试进行增量复制而不是全量复制。

4. 哨兵（Sentinel）模式的主要功能是什么？

  1. 监控（Monitoring）：不断检查 Master 和 Slave 是否正常运行。
  2. 通知（Notification）：发现故障时，通过 API 通知管理员。
  3. 自动故障转移（Automatic Failover）：Master 宕机后，自动将一个 Slave 提升为 Master。
  4. 配置提供者（Configuration Provider）：客户端连接哨兵获取当前 Master 地址。

5. 哨兵如何判断主节点下线（主观下线 vs 客观下线）？

  • 主观下线（SDOWN）：单个哨兵节点在 down-after-milliseconds 时间内未收到 Master 的有效回复（PING），则判定其主观下线。
  • 客观下线（ODOWN）：当指定数量（quorum）的哨兵都判定 Master 主观下线时，则判定其客观下线，并开始故障转移。

6. 哨兵的 Leader 选举算法是什么？

  • 使用 Raft 算法。
  • 当发现 Master 客观下线后，哨兵之间会进行选举，选出一个 Leader 负责执行故障转移。
  • 选举原则：先到先得，且必须获得半数以上票数。

7. Redis Cluster 的工作原理是什么？

  • 数据分片：将数据分散存储在多个节点上。
  • 槽（Slot）：引入哈希槽概念，共有 16384 个槽。
  • 映射规则：CRC16(key) % 16384 计算 Key 属于哪个槽，每个节点负责维护一部分槽。
  • 去中心化：节点之间通过 Gossip 协议交换状态信息。

8. 为什么 Redis Cluster 的槽数量是 16384？

  • 消息体积：Gossip 消息的心跳包包含节点持有的槽位图（bitmap）。16384 个槽需要 16384 / 8 = 2KB。如果槽是 65536，则需要 8KB，心跳包太大浪费带宽。
  • 集群规模：Redis Cluster 官方建议最大节点数不超过 1000 个。对于 1000 个以内的节点，16384 个槽足够均匀分配。

9. Redis Cluster 客户端如何定位数据？

  1. 客户端计算 slot = CRC16(key) % 16384。
  2. 客户端可以缓存 Slot 与节点的映射关系。
  3. 如果请求发到了错误节点，节点会返回 MOVED 错误（包含正确节点地址），客户端重定向并更新缓存。

10. MOVED 和 ASK 重定向的区别？

  • MOVED：表示槽已经永久迁移到了新节点。客户端应更新本地的 Slot 映射缓存。
  • ASK：表示槽正在迁移过程中。Key 可能在源节点，也可能在目标节点。客户端收到 ASK 后，应先向目标节点发送 ASKING 命令，再发送操作命令。ASK 不会更新客户端缓存。

11. Redis Cluster 节点间通信协议是什么？

  • 使用 Gossip 协议。
  • 节点通过 Ping/Pong 消息周期性地交换信息（节点状态、槽信息等）。
  • 优点是去中心化，缺点是集群规模大时网络负担重。

12. 什么是 Gossip 协议的消息类型？

  • MEET：通知新节点加入集群。
  • PING：节点每秒向其他节点发送 PING，包含自身状态和已知节点信息。
  • PONG：回复 PING 或 MEET，确认消息。
  • FAIL：广播某个节点已下线。

13. 什么是脑裂（Split-Brain）？如何解决？

  • 现象：网络分区导致出现两个 Master，客户端可能向旧 Master 写入数据，分区恢复后旧 Master 降级为 Slave，新数据被覆盖丢失。
  • 解决：配置 min-replicas-to-write（最小从节点写入数）。如果 Master 连接的正常 Slave 少于该值，拒绝写请求，从而减少数据丢失。

14. Redis Cluster 支持事务吗？

  • 有限支持。
  • 仅支持涉及同一个节点的 Key 的事务。
  • 如果事务中的 Key 分散在不同节点，Redis Cluster 不支持跨节点事务。

15. Redis Cluster 如何实现扩容（Resharding）？

  1. 启动新节点。
  2. 使用 cluster meet 命令将新节点加入集群。
  3. 迁移槽和数据：从现有节点分出一部分槽，迁移到新节点。
  4. 迁移过程中，数据可能在源节点或目标节点，通过 ASK 重定向处理。

16. Codis 和 Redis Cluster 的区别？

  • 架构：Codis 是中心化架构（依赖 ZooKeeper/Etcd 存元数据，Proxy 转发）；Redis Cluster 是去中心化架构。
  • 性能：Codis 多一层 Proxy，性能略低；Redis Cluster 直连，性能更高。
  • 运维：Codis 运维工具较完善；Redis Cluster 早期运维复杂，现在已有改善。
  • 支持：Codis 对旧客户端兼容性好；Redis Cluster 需要客户端支持 Cluster 协议。

17. 一致性哈希算法（Consistent Hashing）原理？

  • 将哈希空间设计成一个环（0 ~ 2^32-1）。
  • 节点和 Key 都通过 Hash 算法映射到环上。
  • Key 顺时针寻找最近的节点存储。
  • 虚拟节点：为解决数据倾斜，引入虚拟节点，一个物理节点对应多个虚拟节点。

18. Redis 主从复制风暴怎么解决？

  • 现象：Master 挂载了太多的 Slave，Master 挂掉重启后，所有 Slave 同时发起全量复制，导致 Master CPU/带宽 耗尽。
  • 解决：采用级联复制结构（树状结构）。Master 只挂载少量 Slave，其他 Slave 挂载在这些 Slave 上。

19. 什么是 RunID？

  • 每个 Redis 实例启动时生成的唯一随机 ID（40位 16 进制）。
  • 用于主从复制中识别 Master 身份。如果 RunID 变了（Master 重启），Slave 往往需要触发全量复制。

20. Redis 如何保证主从数据一致性？

  • 最终一致性。
  • Redis 默认是异步复制。Master 写入后直接返回客户端，再异步发送给 Slave。
  • 可能存在短暂的数据延迟或丢失。
  • 若要求强一致性，需使用 WAIT 命令（会阻塞），或改用 CP 模型的系统（如 Zookeeper、Etcd）。

21. 哨兵模式下，Master 宕机后数据会丢失吗？

  • 会。
  • 异步复制丢失：Master 写入但未同步到 Slave 就宕机。
  • 脑裂丢失：网络分区导致旧 Master 仍在接收写入，恢复后被覆盖。

22. Redis Cluster 的 Hash Tag 是什么？

  • 作用：强制将一组 Key 映射到同一个槽（Slot）。
  • 规则：如果 Key 中包含 {}，则只对 {} 内部的字符串进行 Hash 计算。
  • 示例：user:{100}:name 和 user:{100}:age 都会根据 100 计算槽，确保在同一节点，便于支持事务或批量操作（MGET）。

23. Redis Cluster 节点握手过程？

  • 节点 A 向节点 B 发送 CLUSTER MEET。
  • B 回复 PONG。
  • A 和 B 建立连接，并通过 Gossip 协议将 B 的存在广播给集群其他节点。

24. 为什么 Redis Cluster 不支持多数据库（Select）？

  • Redis Cluster 默认且仅支持 db0。
  • 分布式环境下，多数据库会增加复杂性，且实用价值不高。

25. Redis Cluster 读写分离怎么做？

  • 默认情况下，Slave 节点会重定向请求到 Master（即使是读请求）。
  • 需要在客户端发送 READONLY 命令，告诉 Slave 节点：“我可以接受读取旧数据”。
  • 之后该连接可以进行读操作。

26. 客户端对 Redis Cluster 的连接维护？

  • 客户端通常会维护一个 Slot -> Node 的映射缓存。
  • 连接池通常会为每个节点建立连接。
  • 当收到 MOVED 错误时，更新映射缓存。

27. Redis Cluster 故障恢复时间大约多久？

  • 取决于 down-after-milliseconds 配置（判定下线时间）和故障转移流程。
  • 通常在 秒级 到 几十秒 之间。
  • 故障转移期间，涉及该分片的请求不可用。

28. 大规模集群下的 Gossip 风暴问题？

  • 节点越多，Gossip 消息包越大，通信越频繁，带宽占用越高。
  • 优化：
    • 限制集群规模（官方建议 1000 节点以内）。
    • 调整 cluster-node-timeout，减少误判和频率。

29. 什么是从节点只读模式？

  • replica-read-only yes（默认）。
  • Slave 拒绝所有写命令。
  • 防止误操作导致主从数据不一致。

30. Redis Cluster 的 failover 过程是怎样的？

  1. Slave 发现 Master 客观下线。
  2. Slave 休眠一个随机时间（避免同时发起选举）。
  3. Slave 发起拉票请求。
  4. Master 节点（持有槽的主节点）投票。
  5. 获得大多数选票的 Slave 成为新 Master。
  6. 新 Master 广播 Pong 消息，通知集群接管槽位。

31. Twemproxy 是什么？

  • Twitter 开源的 Redis/Memcached 代理。
  • 静态分片（一致性哈希）。
  • 不支持自动故障转移（需配合 Keepalived 等）。
  • 扩缩容困难（需要重启或复杂操作）。
  • 现已逐渐被 Redis Cluster 取代。