跳到主要内容

一致性哈希

简单取模为何在扩容时搬动大量数据？​

  • 普通映射: 用 hash(key) mod N 选择 N 个节点中的一个，规则简单;
  • 扩容问题: N 改变后多数键的余数也改变，缓存失效或数据库迁移会波及大量节点;
  • 目标: 节点增减时只调整较小一部分键，让弹性扩容更可预测;

哈希环如何给键选择节点？​

将键和节点映射到同一哈希空间
把首尾相接看作一个环
从键的位置顺时针找第一个节点
该节点负责保存或处理此键
  • 哈希空间: 键和节点身份经稳定规则变成环上位置，所有路由参与者需要看到一致的成员信息;
  • 节点加入: 新节点接管其负责区间，原有其他区间不需要重新映射;
  • 节点移除: 该节点的区间交给后继节点，其他区间通常保持不变;
  • 迁移估算: 理想均匀条件下，移除 N 个节点之一影响约 K/N 个键；由 N 加到 N+1 个节点影响约 K/(N+1);
  • 数量边界: K 为键数，估算是期望而非精确上界，不能保证实际字节量或流量也均匀;

虚拟节点如何改善负载均衡？​

  • 虚拟节点: 一台物理机映射到环上多个位置，把其责任分散为多个较小区间;
  • 实现: 可对“物理节点标识+序号”重复哈希，不必使用完全不同的哈希算法;
  • 收益: 减少随机位置造成的大区间，节点失效时由多个节点分担迁移负载;
  • 容量权重: 能力较强的节点可以配置更多虚拟节点，但应依据实际工作量校准;
  • 代价: 更多映射信息和迁移调度工作，虚拟节点不增加物理机的真实容量;

哈希环如何与副本放置结合？​

  • 副本放置: 可以沿环选择多个不同物理节点保存同一键，并考虑机架或地区故障域;
  • 副本因子: 指保存副本的节点数，不能把多个同属一台物理机的虚拟节点算成独立保护;
  • 职责区分: 一致性哈希决定放在哪里，复制协议决定何时同步及返回成功，哈希本身不保证一致性或持久性;
  • 原文示例: Cassandra 分区与 Dynamo 系列系统的负载分配体现这一思想，具体产品实现需独立核实;

一致性哈希仍有哪些失效风险？​

  • 热点键: 极热门的单键仍压到其负责节点，需要缓存、副本读取或业务拆分等额外机制;
  • 级联故障: 一节点失效把负载交给邻居，邻居没有余量又失效，会扩大影响;
  • 成员抖动: 临时离线反复触发迁移可能比故障本身更贵，应结合稳定成员管理和恢复策略;
  • 路由一致性: 不同客户端使用不同环视图时可能把同一键送往不同位置，需要明确切换与兼容机制;