一致性哈希:consistent 与 rendezvous 的对比
432 字
2 分钟
一致性哈希:consistent 与 rendezvous 的对比
一致性哈希要解决的问题:在节点集合会变化的分布式系统里,把 key 稳定地映射到节点上,使得增删节点时只影响尽量少的 key。常见实现有两类:
- Consistent Hashing(环 + 虚拟节点):把节点和 key 都哈希到一个环上,key 沿环顺时针找到第一个节点;用虚拟节点改善均匀度。
- Rendezvous Hashing(HRW,Highest Random Weight):对每个 key,计算它与所有节点的哈希分数,取分数最高的节点。没有环、没有虚拟节点,纯计算。
对比结论
参考资料:
- 16 张图解带你掌握一致性哈希算法 - 华为开发者话题
- Consistent 和 Rendezvous 两种分布式 Hash 的比较 - 知乎
- 分布式算法 - 一致性 Hash 算法 - Java 全栈知识体系
实测的两条核心结论:
- rendezvous 的均匀度更好,所有场景的均值偏差都在 10% 以内。但当集群节点数较多时,rendezvous 更耗时:100 个节点时,rendezvous 的耗时是 consistent 的一倍(因为每个 key 都要和全部节点算一遍分数,O(n))。
- consistent 随虚拟节点数量增加,均匀性越来越好,且虚拟节点数量基本不影响调度用时(哈希环 + 二分查找,O(log n))。但均匀度和 rendezvous 比始终有差距。
怎么选
- 节点数较少:直接选 rendezvous hash,简单且均匀。
- 节点数较多且时间敏感:选 consistent hash。
- 节点数较多但对均匀性要求更高、能接受耗时:依然选 rendezvous hash 来确保均匀性。
一句话:rendezvous 用计算时间换均匀度;consistent 用虚拟节点改善均匀度,查询则是哈希环上 O(log n) 的二分。
文章分享
如果这篇文章对你有帮助,欢迎分享给更多人!
一致性哈希:consistent 与 rendezvous 的对比
https://blog.81vm3.xyz/posts/consistent-hashing/相关文章智能推荐
1
微服务之间如何传递 trace
后端开发跨服务传递的是 trace 上下文而非 tracer:HTTP header、gRPC metadata 与 MQ 消息头的标准做法。
2
微服务鉴权与网关职责
后端开发Gateway 负责认证、Service 负责授权:身份上下文透传、反例风险与文件服务落地场景。
3
Kafka 的分区与副本机制
后端开发Kafka Broker/Topic/分区的关系,以及 leader-follower 副本的读写与冗余备份机制。
4
本地负缓存
后端开发把不存在/失败的查询结果缓存在本地内存中,短时间内直接返回,避免重复打到下游系统。
5
MySQL 索引与慢查询优化
后端开发慢查询 200ms 阈值、JOIN 对数据量的影响、IN 列表过大丢索引与分批查询。
随机文章随机推荐











