--- tags: [test/review, redis, cluster-sentinel, sharding, gossip, failover] create time: 2026-08-09 12:00 --- # 集群与哨兵机制_测试题 ## 概述 本测试覆盖 Redis Sentinel 的高可用故障转移机制和 Redis Cluster 的槽位分片架构。共 10 道题：6 道选择题、3 道填空题、1 道简答题，考察对 CAP 权衡、Gossip 协议、选举流程和槽位迁移的理解。 --- ## 一、选择题（6道，由浅入深） > **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景 ### Q1（基础）— 考察定义层面 Redis Sentinel 判定 master 节点进入"客观下线"（ODOWN）状态的最低条件是： A. 单个 Sentinel 节点 PING 超时 B. quorum（n/2+1）个 Sentinel 认为 master SDOWN C. 所有 Sentinel 节点一致同意 D. master 连续 5 次 PING 无响应 ### Q2（基础）— 考察行为判断 关于 Redis Cluster 的哈希槽分配，以下哪项计算方式是正确的？ A. MD5(key) % 16384 B. CRC16(key) % 16384 C. SHA1(key) % 16384 D. Hash(key) % 1024 ### Q3（进阶）— 考察核心原理 Sentinel 进行故障转移时，选择 slave 升为主节点的优先依据是： A. priority 参数最低的那个 slave B. replication offset 最大的那个 slave C. 运行时间最长的 slave D. 最近收到 PING 回复最快的 slave ### Q4（进阶）— 考察对比辨析 Redis Sentinel 和 Redis Cluster 在设计上做出了不同的取舍，以下对比错误的是： A. Sentinel 支持 DB0~DB15 多库，Cluster 仅支持 DB0 B. Sentinel 不支持水平分片，Cluster 通过 16384 槽位分片实现扩展 C. Sentinel 倾向 AP 可用性优先，Cluster 倾向 CP 一致性优先 D. Sentinel 扩容需要手动迁移或重新搭建，Cluster 可在线增量迁移 ### Q5（深入）— 考察场景推理 某服务部署了 3 个 Sentinel 节点来保护一个 Master-Slave 集群。如果其中 1 个 Sentinel 因网络隔离不可达，会发生什么？ A. 剩余的 2 个 Sentinel 仍然能够达成 quorum（n/2+1=2），继续执行故障检测和转移 B. 由于无法达到 quorum，故障检测完全停止 C. 剩余的 Sentinel 会自动新增第 4 个 Sentinel 来补足票数 D. Master 进入只读模式等待失联的 Sentinel 恢复 ### Q6（深入）— 考察源码级别细节 Redis Cluster 在执行在线槽位迁移时，源节点和目标节点通过什么标志位协作完成过渡？ A. MIGRATING 和 IMPORTING B. TRANSFER 和 RECEIVE C. SOURCE 和 TARGET D. PREPARING 和 COMMITTING --- ## 二、填空题（3道） ### F1 — 填空 Sentinel 故障转移的第一步是将 master 标记为 SDOWN（主观下线），需要至少 ______ 个 Sentinel 确认才会升级为 ODOWN（客观下线）。 > **提示**: 如果有 3 个 Sentinel，quorum = n/2 + 1 = 3/2 + 1 = ? ### F2 — 填空 Redis Cluster 将数据划分为 ______ 个 hash slot，Key 的定位通过 CRC16(key) % 16384 计算得到对应的槽位。 > **提示**: 这个数字是一个质数附近的数值。 ### F3 — 填空 当客户端向错误的 Cluster 节点发送请求时，RabbitMQ（应为 Redis Cluster）会返回 ______ 重定向消息，告知客户端前往正确的节点查找。 > **提示**: 有两种重定向类型，ASK 用于迁移中的过渡期。 --- ## 三、简答题（1道） ### S1 你正在为一个需要高可用的金融交易系统设计 Redis 基础设施。该系统的读写比例约为 3:7，对数据一致性要求极高但不支持多 DB（即只用 DB0）。已知有以下约束条件： - 不能容忍脑裂现象导致的双主问题 - 需要在故障发生时自动完成故障转移 - 客户端连接地址需要保持相对稳定 请选择合适的架构方案（Sentinel 或 Cluster），列出你的配置建议，并说明如何将脑裂风险降到最低。 > **答题框架提示**: > 1. 架构方案的选择理由（CP vs AP 权衡） > 2. Sentinel 的部署数量和位置 > 3. 关键的参数配置 > 4. 脑裂防护机制（min-replicas-to-write 等） --- ## 参考答案与解析 ### 选择题答案 | 题号 | 正确答案 | 解析 | |------|---------|------| | Q1 | B | quorum = n/2 + 1，其中 n 是配置的 Sentinel 总数。3 个 Sentinel 时需要 2 个认为 master SDOWN 才会触发 ODOWN。A 只是单个节点的 SDOWN（主观下线）。C 过于严格不利于故障快速发现。D 不是判定标准。 | | Q2 | B | Redis Cluster 使用 CRC16(key) % 16384 计算 Key 所属的槽位。MD5/SHA1 不是 Cluster 使用的算法。 | | Q3 | B | Sentinel 选择 replication offset 最大的 slave 升级为主，因为这代表它与 master 同步的最新、最完整的数据。priority 可作为辅助排序条件。 | | Q4 | C | 反了！Sentinel 倾向 CP（主从切换期间短暂不可用但保证一致），Cluster 倾向 AP（分片后允许不同分区有不同视角）。A、B、D 均为正确描述。 | | Q5 | A | 3 个 Sentinel 的 quorum = 3/2 + 1 = 2。剩余 2 个可达的 Sentinel 刚好达到 quorum，可以继续执行故障检测。少数派宕机不影响多数派的正常工作。 | | Q6 | A | 迁移时源节点 setslot MIGRATING ，目标节点 setslot IMPORTING 。迁移完成后双方取消标志位设为 NODE。 | ### 填空题答案 | 题号 | 答案 | 解析 | |------|------|------| | F1 | 2 | 3 个 Sentinel 的 quorum = 3/2 + 1 = 2。只要 2 个及以上 Sentinel 认为 master SDOWN，就会将其标记为 ODOWN 并触发后续故障转移流程。 | | F2 | 16384 | Redis Cluster 固定使用 16384 个槽位（0-16383），Key 通过 CRC16(key) % 16384 分配到对应槽位所在的节点。 | | F3 | MOVED / ASK | 向错误节点发请求时，若 slot 已迁移到目标节点，目标节点返回 MOVED（迁移完成）或 ASK（迁移中过渡）重定向，让客户端重试正确节点。 | ### 简答题参考答案 S1：**参考答案要点**： 1. 选择 Redis Sentinel 而非 Cluster。原因：数据一致性要求高（CP 倾向）、读写比 3:7 且不需要水平扩展、只用单 DB（Cluster 仅支持 DB0 但这里正好满足）。 2. Sentinel 部署至少 3 个奇数节点，跨机房/机架部署避免单点故障。quorum 设为 n/2 + 1。 3. 关键参数：down-after-milliseconds 合理设置（如 30000ms）、failover-timeout 控制超时、parallel-syncs 控制同步并发数。 4. 脑裂防护：设置 min-replicas-to-write（如 ≥1）和 min-replicas-max-lag（如 10s）。当 master 连接的合法从节点数低于阈值或延迟超过限制时，master 拒绝写操作，防止脑裂时双主写入。 **评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖架构选择理由、部署方案、关键参数和脑裂防护四个维度。 ## 关联笔记 - [[03.Redis/core/Redis 五大核心数据结构]] - [[03.Redis/core/RDB 与 AOF 持久化]] - [[03.Redis/strategies/多级缓存架构设计]]