第3章 一致性哈希与负载均衡策略

--- ### 面试问答卡片 #### 卡片 1：一致性哈希算法原理 **面试问题**：请解释一致性哈希算法的基本原理，以及它如何解决传统哈希取模的问题。 **面试官考察点** - 是否理解哈希环的构建与数据映射规则 - 能否清晰表达节点增删时最小化数据迁移的优势 - 对“哈希偏斜”“虚拟节点”等进阶概念是否有储备 **回答框架** 1. 定义一致性哈希环（0~2^32-1），节点和服务都按哈希值落环 2. 数据按哈希值顺时针找到第一个节点 3. 节点增减仅影响相邻节点的数据，避免全量重新哈希 4. 引入虚拟节点解决节点分布不均导致的负载倾斜 **简短示例回答** 一致性哈希将节点哈希到环形空间，数据顺时针寻址。传统取模增减节点导致大规模迁移，而一致性哈希只影响相邻节点。通过虚拟节点让每个物理节点在环上拥有多个副本，分散负载，提高均衡性。 **可能追问** - 虚拟节点数量如何设定？ - 如果某个节点宕机，数据如何保证高可用？ - 一致性哈希在 Redis 集群或 Nginx 中如何实现？ **避坑提醒** 不要只背原理，要结合真实场景（如网关路由、缓存分片）解释；避免混淆“一致性哈希”和“哈希一致性”（CAP 中的一致性），更不要忘记提虚拟节点。 --- #### 卡片 2：负载均衡策略选型 **面试问题**：在 API 网关中，为什么需要一致性哈希作为负载均衡策略？它相比轮询、权重、最小连接数有何优势？ **面试官考察点** - 能否对比不同负载均衡策略的适用场景 - 是否理解有状态服务（如 Session 持久化、缓存）对路由一致性的要求 - 网关层如何平衡“均衡”与“客户端固定路由” **回答框架** 1. 无状态服务（如纯计算）→ 轮询/最小连接数即可 2. 有状态服务（如 Session、缓存、分库分表）→ 要求相同请求固定落在同一节点 3. 一致性哈希在节点变动时仍保持大部分客户端路由不变 4. 配合虚拟节点可解决分布不均，而普通哈希取模无法处理扩缩容 **简短示例回答** 网关后挂缓存集群，若使用轮询，扩容后所有缓存全部失效造成雪崩。一致性哈希保证同一 key 路由到固定节点，扩缩容仅影响少量 key。对于无状态服务，轮询或最小连接数更简单高效，无需引入一致性哈希。 **可能追问** - 如果网关层使用一致性哈希，后端节点权重不同怎么办？ - 什么业务场景下必须用一致性哈希？什么场景不适合？ - 如何监控一致性哈希的均衡度？ **避坑提醒** 不要过度迷恋一致性哈希；无状态服务用轮询即可。在面试中应体现“根据业务场景选择策略”的工程思维。 --- #### 卡片 3：实际应用与常见问题 **面试问题**：你在实际项目中使用过一致性哈希吗？遇到过什么问题？如何解决哈希倾斜？ **面试官考察点** - 是否有真实落地经验，还是停留在理论 - 能否描述哈希倾斜的监控手段和补偿方案 - 是否了解业界成熟实现（如 Ketama 哈希、Google Maglev） **回答框架** 1. 使用场景：网关路由到 Redis 分片或微服务有状态实例 2. 发现倾斜：监控各节点请求量/内存差异超过 20% 3. 原因：节点哈希值分布不均匀，或某些 key 数量级差异大 4. 解决：增加虚拟节点（如 100-200 个/物理节点）；改用 Ketama 算法或加权虚拟节点 **简短示例回答** 在项目中网关路由至 4 个 Redis 节点，发现节点 A 负载 40%，节点 D 仅 15%。分析后确认是节点哈希碰撞导致倾斜。将每个物理节点虚拟节点数从 50 增加到 160，负载差距降到 5% 以内，同时引入一致性哈希监控仪表盘。 **可能追问** - 虚拟节点越多越好吗？极限在哪里？ - 如果某个 key 访问量特别大（热 key），一致性哈希怎么处理？ - 你用的哈希函数是什么？为什么选择它？ **避坑提醒** 不要只说“加了虚拟节点”，要能给出定量建议（如 100-200 个）。如果实际没做过，可以说“参考了 Ketama 实现”但不要编造数据。热 key 问题需要单独说 LRU 缓存或手动迁移。 --- ### 项目案例 #### 项目名称：跨机房网关路由系统重构 **业务背景** 某金融科技公司提供实时交易查询和风控服务，网关需将同一用户请求路由到对应机房的 Redis 和风控引擎。上线初期使用简单哈希取模，机房扩缩容导致大量缓存击穿和交易超时。 **规模指标** - 网关 QPS：12 万（峰值 25 万） - 后端 Redis 集群：6 个分片×2 机房（共 12 节点） - 用户 ID 约 5000 万，每日缓存数据 8 TB **技术栈** Nginx + Lua (一致性哈希模块)、Redis Cluster、Ketama 算法、Prometheus + Grafana 监控 **核心难点** 1. 两机房节点权重不同（单机房扩容/缩容频繁） 2. 虚拟节点数量选择既要平衡内存占用（Nginx 共享字典）又要防倾斜 3. 跨机房请求回环问题：需确保一致性哈希环按机房粘性路由 **面试高频追问** | 追问 | 回答方向 | |------|----------| | 为什么选择 Nginx Lua 而不是 OpenResty 的标准一致性哈希？ | 标准模块不支持虚拟节点加权，自研 Lua 实现可动态调整虚拟节点数并监控倾斜度。 | | 如何避免机房故障时流量全部压到另一机房？ | 每机房配置一个虚拟“隔离节点”，正常时参与路由，故障时踢出环，实现熔断。 | | 虚拟节点数量如何测试确定？ | 通过模拟 5000 万 key 分布，测试不同虚拟节点数下的标准差，最终取 150 个/物理节点。 | | 如何保证扩容期间服务不中断？ | 采用“预热”方式：新节点先挂载但不参与路由，数据逐渐迁移后切换权重，再正式上线。 | **可迁移回答话术** - “一致性哈希的核心价值在于最小化节点变更的影响范围，实际落地时必须配合虚拟节点和监控。” - “虚拟节点不是越多越好，需要根据 key 数量和节点性能做实验或参考标准库的默认值。” - “碰到倾斜问题，优先排查哈希函数是否均匀，再调整虚拟节点数，最后考虑手动拆分热 key。”