开发者社区> 中国Cassandra技术社区> 正文

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

版权声明:本文中所有内容均属于阿里云开发者社区所有,任何媒体、网站或个人未经阿里云开发者社区协议授权不得转载、链接、转贴或以其他方式复制发布/发表。申请授权请邮件developerteam@list.alibaba-inc.com,已获得阿里云开发者社区协议授权的媒体、网站,在转载使用时必须注明"稿件来源:阿里云开发者社区,原文作者姓名",违者本社区将依法追究责任。 如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:developer2020@service.aliyun.com 进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
上一篇:Cassandra监控运维介绍 下一篇:5个选择Apache Cassandra 而非DynamoDB的原因

Cassandra已有10年+的沉淀,基于Amazon DynamoDB的分布式设计和 Google Bigtable 的数据模型。具备诸多优异特性:采用分布式架构、无中心、支持多活、弹性可扩展、高可用、容错、一致性可调、提供类SQL查询语言CQL等。Cassandra为互联网业务而生,已在全球广大互联网公司有成熟应用,是目前最流行的宽表数据库。阿里云在2019年8月份全球首发云Cassandra服务。

官方博客
相关链接