Cassandra gossip介绍系列之一

简介: 介绍cassandra的gossip系列之一

Gossip 是一种去中心化,点对点的数据交互协议,Cassandra 的元信息 交互是依赖于gossip,当然Cassandra的节点状态检测也有依赖gossip的交互带来的信息;所以gossip是集群状态的一个基石,这里我们从最基本的Gossip算法出发,到Cassandra具体实现,大概的介绍下这个模块;当然我们也会顺带介绍下集群的状态检测;

说到gossip,以及Cassandra的集群状态检测,我们优先推荐2篇论文,这是这个工业产品的理论基石:《Efficient Reconciliation and Flow Control for Anti-Entropy Protocols》 以及《The Phi Accrual Failure Detector》,分别是基本的Gossip交互状态的流程以及理论分析,论文中也说明了推/拉在一个理论周期内可以让2个节点的状态一致,且收敛速度最快,后一篇论文则是节点状态检测的理论依据,接下来我们介绍cassandra的gossip流程;

我们假设集群2个节点,X,Y,与gossip相关的有一些seed节点,这些是需要你在cassandra.yaml的seed_provider这个选项下的seeds里面进行配置一下。这个seed节点在后续我们会用到。

当我们的cassandra节点启动以后,在服务进行到节点init的状态也就是storageservice服务启动到initserver的这个地方就会每隔一秒钟启动gossip的一个服务,服务的主要的宗旨就是把本节点知道的集群状态信息与集群中的别的节点进行交互,交互的宗旨有3个:

1.随机选择一个它认为活着的节点(本节点交互的这个时候的内存列表)进行信息交互;
2.以一定概率随机选择一个它认为不可达的节点进行信息交互;
3.如果上面操作没有选择seed节点交互,那么执行一次;

交互的流程实际上按照上面的论文说的推/拉这种模式是最高效的,所以实际上的代码实现也是类似的,大概的流程就是一个3次握手的类似流程,假设有2个节点X与Y,那么如下图所以,X节点会与Y节点先发送一个SYN的digest的信息,Y收到这个信息以后在本地进行处理,处理以后给X 发送一个ACK的digest的信息,同样,X收到这个信息以后本地进行处理以后会给Y发送一个ACK2的digest信息给Y进行后续处理,这样一波来回,可以保证X与Y在这次交互信息过程中可以双方达到信息一致的状态,那么如果集群种有很多个节点,如此进行交互,最终在一个O(log(n))的收敛时间范围内就可以达到集群状态一致(n是集群的节点),当然增加seed节点规模是可以降低这个收敛时间。

_2019_09_15_6_17_05

上述介绍的就是大概的gossip在2个节点间交互的一次来回。我们接下来详细介绍下这波“三次握手”过程中节点双方都发生了什么吧。

要了解发生了什么就需要知道X与Y交互的时候交互的信息有哪些,我们假设X节点知道自己的信息X1,Z的节点信息Z1,Y节点的信息Y1,Y节点包含有X,Y,Z节点的信息X1,Y2,那么X节点与Y节点发生的第一轮SYN之前双方具有的信息是如下:

X节点持有节点的信息:
_2019_09_16_11_29_02
Y节点持有节点信息:
_2019_09_16_11_29_10

Y节点在收到X节点的信息以后,发现与X节点的delta的deltagossipdigest信息与deltaendpointstat信息,这里的deltagossipdigest与deltaendpointstat是取决于上图中generation 与version的数据进行赋值,在我们的case中,本地Y节点收到X节点的SYN信息以后发现本地的Y节点的generation信息与remote的X的数据一样,但是本地的version比远端的大,那么这个时候需要把本地的大于远端version的所有的endpointState信息发送给X节点作为ACK的信息发送,那么X节点收到Y节点的信息以后做一些本地处理,包括上述的endpointState的本地状态apply以及告诉notifyFailureDetector,进行节点状态计算;完成以后给Y节点发送一次ACK2,当然如果X有Y没有的信息,这个时候Y在ACK2信息接收的时候会做本地状态apply以及对于没有的这个节点进notifyFailureDetector,当然我们这里没有。

这里需要解释下上述的:generation以及version是如何更新的:每个节点在每秒执行gossip任务的时候都会原子给本节点的状态version加1,本节点的generation则是在集群发生节点remove的时候会非安全的更新;

本文大概介绍了gossip的一轮来回的信息交互,接下来会有一系列文章分析:较为复杂的gossip状态更新,以及细节分析节点FailureDetector计算以及节点更新load等信息的情况;

我们的钉钉二维码:
1b211c42d2911109ac34b9e79c33ef2992458c75_1_jpeg

我们的微信公众号:
769f0e6930ac3f1d14fcee09f1bd0a7fc178d933_jpeg

另外:阿里云cassandra服务也在公测中,欢迎大家使用。
https://www.aliyun.com/product/cds?spm=5176.12825654.h2v3icoap.65.6cb62c4aQXGFb8

目录
相关文章
|
存储 算法 编译器
【数据结构原理】稀疏矩阵 - THE SPARSE MATRIX
【数据结构原理】稀疏矩阵 - THE SPARSE MATRIX
418 0
|
开发工具 git druid
解决Git中fatal: refusing to merge unrelated histories
Git的报错 在使用Git的过程中有时会出现一些问题,那么在解决了每个问题的时候,都需要去总结记录下来,下次不再犯。 一、fatal: refusing to merge unrelated histories 今天在使用Git创建项目的时候,在两个分支合并的时候,出现了下面的这个错误。
109776 6
|
缓存 NoSQL 物联网
这些年背过的面试题——个人项目篇
本文是技术人面试系列个人项目篇,作者总结了一些自己的实战项目经验,一文带你详细了解,欢迎收藏!
|
机器学习/深度学习 TensorFlow 算法框架/工具
使用Python实现深度学习模型:智能数据隐私保护
使用Python实现深度学习模型:智能数据隐私保护 【10月更文挑战第3天】
650 0
|
NoSQL Redis 监控
redis-shake数据同步&迁移&备份导入导出工具使用介绍
redis-shake是阿里云Redis&MongoDB团队开源的用于redis数据同步的工具。
73205 4
redis-shake数据同步&迁移&备份导入导出工具使用介绍
|
Java 测试技术 数据库
Spring事务传播机制(最全示例)
在使用Spring框架进行开发时,`service`层的方法通常带有事务。本文详细探讨了Spring事务在多个方法间的传播机制,主要包括7种传播类型:`REQUIRED`、`SUPPORTS`、`MANDATORY`、`REQUIRES_NEW`、`NOT_SUPPORTED`、`NEVER` 和 `NESTED`。通过示例代码和数据库插入测试,逐一展示了每种类型的运作方式。例如,`REQUIRED`表示如果当前存在事务则加入该事务,否则创建新事务;`SUPPORTS`表示如果当前存在事务则加入,否则以非事务方式执行;`MANDATORY`表示必须在现有事务中运行,否则抛出异常;
1535 4
Spring事务传播机制(最全示例)
|
Cloud Native 关系型数据库 分布式数据库
祝贺!阿里云PolarDB斩获数据库国际顶会ICDE 2024工业赛道最佳论文
阿里云斩获国际顶会ICDE 2024最佳论文,0.5秒实现数据库跨机实例迁移。
祝贺!阿里云PolarDB斩获数据库国际顶会ICDE 2024工业赛道最佳论文
|
JavaScript UED
进一步探讨 Vue 3 渲染机制的优化策略
进一步探讨 Vue 3 渲染机制的优化策略
|
自然语言处理 Java 测试技术
序列化性能之巅:使用Fury替换Protobuf/Flatbuffers实现10倍加速
问题背景Protobuf/Flatbuffers是业界广泛使用的序列化库,服务于大量的业务场景。但随着业务场景的复杂化,Protobuf/Flatbuffers逐渐不能满足性能需求开始成为系统瓶颈,在这种情况下,用户不得不手写大量序列化逻辑来进行极致性能优化,但这带来了三个问题:大量字段手写序列化逻辑冗长易出错;手写重复序列化逻辑开发效率低下;难以处理发送端和接收端字段变更的前后兼容性问题;这里将
2765 0
|
IDE Java Linux
Java一分钟之-JavaFX:构建桌面GUI应用
JavaFX是Java用于构建桌面应用的强大力量,提供丰富的UI组件、动画、媒体播放和跨平台能力。本文简要介绍JavaFX,讨论环境配置、布局混乱和事件处理等常见问题及其解决方案。通过学习官方文档、实践和使用IDE辅助,开发者能避免这些问题。示例代码展示了一个简单的JavaFX应用,展示如何创建UI、处理事件和构建布局。
950 1