149 lines
6.8 KiB
Markdown
149 lines
6.8 KiB
Markdown
|
---
|
|||
|
|
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 <slot> <target-id>，目标节点 setslot IMPORTING <slot> <source-id>。迁移完成后双方取消标志位设为 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/多级缓存架构设计]]
|