Cassandra gossip介绍系列之一

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
云数据库 Tair(兼容Redis),内存型 2GB
简介: 介绍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

目录
相关文章
|
2月前
|
存储 负载均衡 Dubbo
分布式-Zookeeper(一)
分布式-Zookeeper(一)
|
2月前
|
监控
分布式-Zookeeper-Zab协议
分布式-Zookeeper-Zab协议
|
2月前
|
存储 NoSQL Redis
分布式-Zookeeper(二)
分布式-Zookeeper(二)
|
6月前
|
消息中间件 存储 算法
Kafka Raft集群搭建
Kafka Raft集群搭建
201 0
|
6月前
|
消息中间件
【ZooKeeper系列】那ZooKeeper为什么还采用ZAB协议
ZooKeeper的流程是这样的,针对客户端的事务请求,Leader服务器会为其生成对应的事务Proposal,并发送给集群中其余机器,然后再分别收集各自的选票。因为ZAB协议将二阶段提交中的事务中断逻辑移除,所以只需要收集过半Follower服务器的反馈Ack后即可,最后就是进行事务提交。
【ZooKeeper系列】那ZooKeeper为什么还采用ZAB协议
|
6月前
|
存储 负载均衡 算法
TiKV简介
【2月更文挑战第27天】本章节旨在为读者提供一个关于TiKV存储引擎的初步认识,包括其基本概念、产生背景、主要特性以及在分布式存储领域中的应用。通过本章节的介绍,读者将能够对TiKV有一个整体的了解,为后续深入学习其存储原理和数据模型奠定基础。
|
存储 机器学习/深度学习 NoSQL
深入理解 Redis cluster GOSSIP 协议
深入理解 Redis cluster GOSSIP 协议
505 0
|
算法
ZooKeeper-集群-ZAB协议与数据同步
前言 在前面两篇文章中,我们认识了什么是ZooKeeper,ZooKeeper有哪些功能,ZooKeeper集群,以及ZooKeeper集群中的选举机制。那么在ZooKeeper集群中,数据是如何在节点间同步的呢?数据同步过程中又会产生哪些问题又是如何解决的呢? 在下面这篇文章中,将为大家讲解
199 0
|
存储 Java Linux
Zookeeper分布式集群搭建(六)
Zookeeper分布式集群搭建(六)
110 0
Zookeeper分布式集群搭建(六)
|
消息中间件 存储 NoSQL
ActiveMQ系列:基于LevelDB和 Zookeeper 的数据复制集群
LeveDB 5.6版本之后推出了 LevelDB 的持久化引擎,它使用了自定义的索引代替常用的 BTree 索引,其持久化性能高于KahaDB,虽然默认的持久化方式还是 KahaDB,但是 LevelDB 可能会是趋势。在5.9版本还提供了基于 LevelDB 和 Zookeeper 的数据复制方式,作为 Master-Slave 方式的首选数据复制方案。
283 0
ActiveMQ系列:基于LevelDB和 Zookeeper 的数据复制集群