Cassandra的一致性哈希(Consistent Hashing)和虚拟节点(Virtual Nodes)的关系

本文探讨了一致性哈希算法及其在Cassandra中的应用,特别是在引入虚拟节点后的变化。虚拟节点增强了系统的高可用性和负载均衡能力。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

推荐:博主历时三年倾注大量心血创作的《大数据平台架构与原型实现:数据中台建设实战》一书已由知名IT图书品牌电子工业出版社博文视点出版发行,真诚推荐给每一位读者!点击《重磅推荐:建大数据平台太难了!给我发个工程原型吧!》了解图书详情,扫码进入京东手机购书页面!

在这里插入图片描述

 

 

本文原文出处: http://blog.csdn.net/bluishglc/article/details/52847591 严禁任何形式的转载,否则将委托CSDN官方维护权益!


#一致性哈希所要解决的问题

一般的哈希算法存在的问题是:当“模”发生变化时,所有的值都需要重新哈希,而一致性哈希算法的特别之处就是它能把这种变化带来的影响降低到最小。关于这一点不再赘述,可以参考http://www.cnblogs.com/haippy/archive/2011/12/10/2282943.html,讲的非常明白。简单地说,就是在添加和删除节点的时候,只有失效节点上的数据会受影响,需要重新哈希,所有其他的节点的数据的都不受影响。

#一致性哈希和虚拟节点的关系

为了理清现两者之间的关系,让我们先分开考虑。下图是Cassandra官方文档中提供的一致性哈希和虚拟节点的对比图,上半部分是单纯使用一致性哈希的情形,下图是一致性哈希+虚拟节点的情形。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-44fsNVgm-1592548056224)(https://docs.datastax.com/en/cassandra/2.1/cassandra/images/arc_vnodes_compare.png)]

关于上半部分,首先每个节点只对应一个分区,1->A,2->B,…,然后,你可以看到,数据的副本都是连续存储的,就是说A的三份副本一定是放在结点1,2,3上,B的三份副本一定是放在结点2,3,4上,依次类推, 这样做的目的也是适应一致性哈希算法的需要,因为当某一节点失效时,比如Node 1, A区间会并入B区间,算法会引导客户去紧邻的下一个节点也就是Node 2上去读写数据,所以在一开始,我们就让Node 2来冗余Node 1的数据,就是为这个场景做准备。

再来看下半部分,让我们先忽略虚拟节点的存在,假定整个区间就被切分成了16个区间,对应16个物理节点,需要强调的是这时的区间(虚拟节点)依然是连续排列的),一致性哈希算法依然工作如初。现在,假定我们用6台高性能的物理机替换现有的16台物理机,原有的16个分区(也包括它们的副本)将分配或者映射到这6台机器上。需要特别注明的是,根据官方文档的表述,这种分配或者映射的过程是随机的,且不像单纯使用一致性哈希时那样是把副本分配到本连续的节点上的(randomly selected and non-contiguous),基于这种新情形,让我们重新分析一下数据的读写过程:如果一条数据属于虚拟节点A,则写入时会同步写入虚拟节点B和虚拟节点C(这里我们假定replia的数量是3),当虚拟节点A失效(其实是虚拟节点A对应的物理节点失效)时,系统会去下一个临近节点B去读写冗余数据,应该说到目前为止,都来还是按照一致性哈希的逻辑在进行,与未引入虚拟node之前没有任何差异,接下来不同的就是:B只是一个虚拟节点,系统需要从虚拟节点<->物理节点的映射关系中找到B对应的物理节点之后,再进行读写,这是引入虚拟节点之后的不同之处,也就是多了一步二次映射的计算过程。

那么引入虚拟节点之后到底带来了什么收益呢?总的来说,引入VNode的主要收益是在系统的拓扑结构发生变化和重建节点时可以保证整个系统的高可用性。关于一点,《Cassandra 3.x High Availability, 2nd Edition》一书有一幅插图形象地说明了问题。

下图是重建Node 2节点的示意图,Node 2存储的3份数据副本F,B,A分别从Node 1,4,3上获取,也就是说只有1,4,3节点参与了Node 2的重建,整体上看这带给1,4,3节点比较大的负载,如果5,6两个节点可以参与的话无疑会分摊一些压力。同样地,我们也可以用这个图来考虑一下Node 2失效时的情形,那就所以对B的请求会转嫁到Node 3上,这会使Node 3的负载增加一倍。

我们再来对比地看一下采用虚拟节点之后的情形:同样考虑Node 2重建的过程,它上面的8个数据分区将来自全部已存在的节点,也就是说所有节点都参与了Node 2的重建,最而最大限度地分摊了系统负载。一样的,当Node 2失效时,存放在上面的两个(或三个)分区会由另外的两个(或三个)节点接管,这和前面由单一节点接管相比也分摊了系统的负载。

#小结

无论是否引入虚拟节点,一致性哈希一直工作于Canssandra上,它解决的主要问题是避免节点(模)失效时导致所有已存在的hash映射关系失效。

虚拟节点的作用在于:让物理节点host更多个分区(即多个虚拟节点),由于每一个分区都有另外多份副本放在另外多个物理节点上,这带来的实际效果是密切了各个物理节点之间的关联性,从互为主被的角度来看,就如同将每一个节点和所有其他节点连上线,形成了N*N的关联关系,每一个物理节点都可能包含所有其他节点的某一小部分数据副本,所以每个节点都有可能参与到任意节点的重建工作中去,而当某一节点失效,所有其他节点都有可能来分摊失效节点的负载。总结起来,引入虚拟节点的收益是:

  • 无需为每个节点计算、分配token
  • 添加移除节点后无需重新平衡集群负载
  • 重建死掉的节点更快
  • 允许在同一集群使用不同性能的机器
<think>嗯,用户之前问过关于HAProxy的source算法,现在又问一致性哈希是做什么的。看起来他们可能是在配置负载均衡时遇到了问题,或者想优化现有的设置。用户可能已经了解source算法的一些缺点,比如服务器增减导致的问题,所以想找更好的解决方案。 一致性哈希source算法中的哈希有关联,用户可能想了解如何解决服务器动态扩容或缩容时的会话中断问题。他们可能是在管理一个需要高可用性或动态扩展的后端服务,比如云环境中的微服务架构,或者需要处理频繁的服务器变动。 需要解释一致性哈希的基本概念,传统哈希的区别,以及它的优势,比如减少重新哈希带来的影响。还要提到它在分布式系统中的应用场景,比如缓存、负载均衡,以及如何帮助解决服务器增减时的数据分布问题。 另外,用户可能对技术细节感兴趣,比如虚拟节点的作用,如何提高均衡性。需要用简单的例子说明,比如添加或移除服务器时,只有部分请求被影响,而不是全部重新分配。 可能还需要提到HAProxy中如何使用一致性哈希,结合之前的配置示例,让用户知道如何实际应用这个知识。最后总结一下适用场景,帮助用户判断是否适合他们的用例。</think>好的,我来逐步解释一致性哈希Consistent Hashing)的核心作用工作原理。 --- ### 一、要解决的问题 在传统哈希算法(如HAProxy的`source`算法)中: - 若后端服务器数量变化($N$ 改变),哈希结果会**完全重新分布**,导致大量请求被重新路由到不同服务器。 - 例如:原本 $N=3$,新增一台服务器后 $N=4$,几乎所有请求的哈希计算结果都会改变,引发**会话中断、缓存失效**等问题。 --- ### 二、一致性哈希的核心目标 **在服务器数量变化时,最小化受影响请求的比例**。 - 例如:新增/移除一台服务器时,仅该服务器邻近的部分请求需要迁移,其余请求保持原有路由。 --- ### 三、工作原理 #### 1. 环形哈希空间(Hash Ring) - 将哈希值范围视为一个环形空间(例如 $0 \sim 2^{32}-1$)。 - 服务器请求的哈希值均映射到环上: $$ \text{hash\_server} = \text{hash}(\text{服务器标识}) $$ $$ \text{hash\_request} = \text{hash}(\text{请求特征}) $$ #### 2. 请求路由规则 每个请求按**顺时针方向**找到最近的服务器节点,例如: ![](https://upload.wikimedia.org/wikipedia/commons/thumb/9/9a/Hash_ring_4.png/800px-Hash_ring_4.png) (假设图中节点S1~S4为服务器,K1~K4为请求) #### 3. 服务器增减的影响 - **新增服务器**:仅接管环上相邻区间的部分请求。 - **移除服务器**:仅释放其原本负责的区间,相邻服务器接管。 - **关键特性**:其他区间的请求路由**不受影响**。 --- ### 四、虚拟节点Virtual Nodes)优化 #### 问题 若服务器数量少,哈希环分布可能不均衡(某些服务器负载过高)。 #### 解决方案 - 每个物理服务器映射为多个虚拟节点(如1000个),分散在环上。 - 公式: $$ \text{virtual\_node\_hash} = \text{hash}(\text{物理服务器ID} + \text{虚拟节点序号}) $$ - 效果: - 提高负载均衡性 - 降低服务器故障对局部请求的集中影响 --- ### 五、实际应用场景 1. **分布式缓存系统**(如Redis、Memcached集群) - 避免缓存大规模失效 2. **负载均衡**(如HAProxy、Nginx) - 支持动态扩缩容服务器池 3. **分布式数据库**(如Cassandra) - 数据分片(Sharding)时保持稳定性 --- ### 六、HAProxy中的一致性哈希配置示例 ```haproxy backend web_servers balance source hash-type consistent # 启用一致性哈希 server s1 192.168.1.10:80 check server s2 192.168.1.11:80 check ``` --- ### 七、总结对比 | 特性 | 传统哈希 | 一致性哈希 | |--------------------|-----------------------|----------------------------| | 服务器增减影响范围 | 全局(几乎全部请求) | 局部(仅邻近区间请求) | | 负载均衡性 | 依赖哈希均匀性 | 通过虚拟节点优化 | | 适用场景 | 服务器固定、变化少 | 动态扩缩容、高可用性要求高 | 一致性哈希通过环形哈希空间虚拟节点,实现了**动态环境下的稳定请求路由**,是分布式系统设计的核心基础技术之一。
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Laurence 

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值