如何解决一致性哈希（consistent hashing）负载均衡的热分区问题

一致性哈希的热分区本质是哈希空间里某段区间对应的访问量远高于其他区间，导致负责这段区间的物理节点负载超出阈值，可通过以下方案解决：

• 热点Key拆分复制
  先通过流量统计识别出访问量远超平均值的热点Key，给这些Key加上不同的随机/序列后缀，重新映射到不同的虚拟节点上，将热点Key的流量分散到多个物理节点承担。请求侧收到热Key的查询需求时，随机选择一个后缀对应的节点发起请求即可。该方案适合可提前识别、或者持久存在的热点场景，是目前生产环境使用最广泛的方案。
• 动态虚拟节点重映射
  实时监控每个虚拟节点对应的流量负载，当某段哈希区间的负载持续超过设定阈值时，临时将这段区间对应的虚拟节点拆分，重新映射到多个空闲的物理节点上，等热点流量消退后再恢复原有映射规则。该方案适合不可提前预判的突发热点场景，不需要修改业务侧的请求逻辑。
• 带权重的虚拟节点分配
  初始部署时根据物理节点的硬件性能分配对应数量的虚拟节点，性能越高的节点分配的虚拟节点越多，从初始分布层面降低单节点过载概率。后续运行过程中如果监测到某节点长期负载偏高/偏低，就动态调整该节点的权重，增减其对应的虚拟节点数量，实现全局负载的长期均衡。
• 流量削峰兜底
  对于突发的超预期热分区流量，在负载均衡层先做临时限流或者排队处理，避免单节点被直接打垮，同时触发上述的热Key拆分或者虚拟节点重映射流程，等流量打散规则生效后再恢复正常转发，作为极端场景的兜底保护机制。

生产实践参考 #

我之前在100+节点的分布式缓存集群场景下落地过热分区优化方案，核心逻辑是每10秒统计一次所有Key的访问QPS，将超过平均QPS10倍的Key判定为热Key，自动生成5~10个带序列后缀的副本，将数据同步到不同的物理节点，负载均衡层收到热Key请求时随机选一个副本节点转发，峰值场景下可以把热Key对应节点的负载降到原来的1/10，上线后全年没有出现过热分区导致的节点故障。
实际落地时需要注意副本数量不要设置过高，避免不必要的存储资源浪费，常规场景下3~15个副本就足够覆盖绝大多数热点流量的打散需求。

内容的提问来源于stack exchange，提问作者Bishnu