Zeebe服务学习3-Raft算法与集群部署

1.背景
Zeebe集群里面保证分布式一致性问题,是通过Raft实现的,其实这个算法用途比较广泛,比如Consul网关,也是通过Raft算法来实现分布式一致性的。

首先简单介绍一下Raft:

在学术界,解决分布式一致性最耀眼的算法是Paxos,同时,这个算法也是最晦涩。而Raft算法就是基于这个背景被提出来,相对Paxos,Raft比较容易上手。

2.Raft算法介绍

集群每个节点都有三个状态:Follower,Leader,Candidate(Leader候选人)三个状态之间是可以互换的。

集群中每个节点都会维护一个数据结构(Term,Leader):现在Term是多少,Leader是谁。

(1)正常情况下,Leader(A)正常运行,每个节点上都有一个倒计时器(Election Timeout),时间随机在150ms到300ms之间。

Leader定期会广播心跳消息(Term,LeaderA),告诉Follower自己还活着,当Follower接收到心跳信息后,

发现自己维护的Term等于发来的消息里面的Term,按下躁动的心,重置倒计时器。

(2)Leader挂了,此时Follower们都在倒计时,一旦某个Follower(B)倒计时到了,没有Leader的心跳消息镇压,

这个Follower就会率先构造消息(Term+1,LeaderB),进行广播;其他的Follower(包含LeaderA),都会接收到该心跳消息,

发现自己维护的Term小于这个新的Term,则用新的去更新旧数据,然后返回OK信息给LeaderB。

B收到大多数节点的投票后(vote > (n-1)/2),就变成下一任Leader,状态由Candidate变成Leader。

(3)如果两个Follower同时构造消息(Term+1,LeaderB),(Term+1,LeaderC);

其他Follower也是在接收到消息后去更新自己维护的数据,因为Term数值一样,其实就是看消息广播速度,

谁先占领更新其他Follower,最后以少数服从多数处理。

比如B的消息传递到D节点上,D发现自己Term小于传递来的消息,

就会更新自己的数据值,然后重置倒计时器;此时C的消息也来了,

D发现Term并不比自己维护的大,此时,D不会管C的消息了。
如果C获得的支持数少,最后失败后,状态会从Candidate变成Follower,然后接收LeaderB的心跳消息,

更新自己的数据,安安心心当小弟。

如果想了解更多的Raft算法信息

可以参考:

https://www.cnblogs.com/xybaby/p/10124083.html
https://www.cnblogs.com/cc299/p/11145889.html

3.部署Zeebe集群

部署Zeebe集群,由于测试与正式机器的差异,我经历了很多曲折,当然也是一笔财富,至少坑我都趟了一遍了。

(1)部署带有monitor的集群(win-docker环境)

这是在我本机上,我本机是win10系统,所有就搞了一个win-docker,本想着通过docker-compose.yaml文件把monitor也部署上去,

根据荣锋亮大神的博客,按照一步一步的来,最后还是失败了,最后请教了大神,他说不建议在win-docker上部署,

然后现在最新版的zeebe集成monitor需要改配置…..,最后放弃这条路。

(2)只部署集群 (win-docker环境)

既然最新版对monitor集成不友好,我们的目标是部署集群,所以我们就舍弃monitor部署,只部署zeebe集群,

通过官网github:https://github.com/zeebe-io/zeebe-docker-compose,找到cluster,进行本机部署,非常简单,只需要在cd该文件夹,然后输入

docker-compose up

命令即可。

(3)只部署集群 (k8s-aliyun环境)

本机没有问题,那就部署到阿里云上去吧,因为我们都是用阿里云的k8s,第一步就遇到困难了,因为没有找到k8s的yaml文件,

然后一顿搜,终于找到了组织:zeebe官方论坛https://forum.zeebe.io,在里面请教了jwulf关于在k8s部署zeebe cluster的问题,回复很及时。

jwulf给出一个github地址(又是github!)https://github.com/zeebe-io/zeebe-kubernetes,这里面包含了如何在k8s上部署的步骤,非常全。

但是,这些都是针对于Azure和Google Cloud的,没有Aliyun,所以有被挡住了。

接下来,给阿里云提了一个工单,上面jwulf给的yaml比较全,就是缺了03_StoreClass-*的配置文件,

阿里云的技术支持给了我一个基于阿里云的k8s的yaml,然后我把它跟上面的yaml统一打包放在github:https://github.com/walt-liuzw/zeebe-k8s-compose里面了。

这个经过验证是完全可以在阿里云k8s上部署的。

然后,应该皆大欢喜吧,其实不然,我在本机访问不通这个集群,因为我在阿里云里面配置的Ingress有问题,

访问域名报错,即使Ingress已经注解了(这个大家有解决方案可以告诉我,不胜感激)。

nginx.ingress.kubernetes.io/backend-protocol: "GRPC"

最后,我在同事的帮助下,为集群创建了一个SLB负载均衡服务,通过负载上的IP,端口号可以调用到zeebe集群了。

至此部署结束,以上如流水账一样把我的每一步写下来,如果能帮助到你,那非常荣幸。

原文地址:https://www.cnblogs.com/walt/p/11359714.html

时间: 2024-11-07 00:29:40

Zeebe服务学习3-Raft算法与集群部署的相关文章

大数据学习初体验:Linux学习+Shell基础编程+hadoop集群部署

距离上次博客时间已经9天,简单记录下这几天的学习过程 2020-02-15 10:38:47 一.Linux学习 关于Linux命令,我在之前就已经学过一部分了,所以这段时间的linux学习更多的是去学习Linux系统的安装以及相关配置多一些,命令会一些比较常用的就够了,下面记录下安装配置Linux系统时的注意事项. 这里配置的虚拟机的内存为4g 使用的 CentOS-6.5-x86_64-minimal.iso 映射文件 在进入linux系统中时,需要将虚拟机的主机名修改成自己想要的名字,还要

Hadoop学习笔记_4_实施Hadoop集群 --伪分布式安装

实施Hadoop集群 --伪分布式安装 准备与配置安装环境 安装虚拟机和linux,虚拟机推荐使用vmware,PC可以使用workstation,服务器可以使用ESXi,在管理上比较方便.ESXi还可以通过拷贝镜像文件复制虚拟机,复制后自动修改网卡号和ip,非常快捷.如果只是实验用途,硬盘大约预留20-30G空间. 以Centos为例,分区可以选择默认[如果想要手动分区,请参考博客:http://blog.csdn.net/zjf280441589/article/details/175485

【整理学习Hadoop】Hadoop学习基础之一:服务器集群技术

        服务器集群就是指将很多服务器集中起来一起进行同一种服务,在客户端看来就像是只有一个服务器.集群可以利用多个计算机进行并行计算从而获得很高的计算速度,也可以用多个计算机做备份,从而使得任何一个机器坏了整个系统还是能正常运行. 集群(cluster)技术是一种较新的技术,通过集群技术,可以在付出较低成本的情况下获得在性能.可靠性.灵活性方面的相对较高的收益,其任务调度则是集群系统中的核心技术.集群是一组相互独立的.通过高速网络互联的计算机,它们构成了一个组,并以单一系统的模式加以管理

hbase 学习(十二)集群间备份原理

集群建备份,它是master/slaves结构式的备份,由master推送,这样更容易跟踪现在备份到哪里了,况且region server是都有自己的WAL 和HLog日志,它就像mysql的主从备份结构一样,只有一个日志来跟踪.一个master集群可以向多个slave集群推送,收到推送的集群会覆盖它本地的edits日志. 这个备份操作是异步的,这意味着,有时候他们的连接可能是断开的,master的变化不会马上反应到slave当中.备份个格式在设计上是和mysql的statement-based

Heartbeat学习笔记--HA高可用集群实现

一.部署环境: 服务器版本:CentOS6.5 双主热备模式: VIP:192.168.3.30(MASTER上) VIP:192.168.3.32(BACKUP上) 主机网络参数: 接口 MASTER BACKUP 说明 eth1 192.168.3.23 192.168.3.24 内网管理IP eth2 192.168.5.23 192.168.5.24 心跳线 eth3 192.168.2.23 192.168.2.24 外网(临时下载文件用) 网络拓扑: 二.需求分析: 通过Heartb

Hadoop学习笔记_8_实施Hadoop集群 --分布式安装Hadoop

实施Hadoop集群 --分布式安装Hadoop 说明: 以Ubuntu配置为例,其中与CentOS不同之处会给出详细说明 现有三台服务器:其IP与主机名对应关系为: 192.168.139.129 master #NameNode/JobTrackerr结点 192.168.139.132 slave01 #DataNode/TaskTracker结点 192.168.139.137 slave02 #DataNode/TaskTracker结点 一.配置ssh实现Hadoop节点间用户的无密

Kubernetes集群部署DNS服务

Kubernetes集群部署DNS服务在kubernetes中每一个service都会被分配一个虚拟IP,每一个Service在正常情况下都会长时间不会改变,这个相对于pod的不定IP,对于集群中APP的使用相对是稳定的. 但是Service的信息注入到pod目前使用的是环境变量的方式,并且十分依赖于pod(rc)和service的创建顺序,这使得这个集群看起来又不那么完美,于是kubernetes以插件的方式引入了DNS系统,利用DNS对Service进行一个映射,这样我们在APP中直接使用域

大数据技术之_10_Kafka学习_Kafka概述+Kafka集群部署+Kafka工作流程分析+Kafka API实战+Kafka Producer拦截器+Kafka Streams

第1章 Kafka概述1.1 消息队列1.2 为什么需要消息队列1.3 什么是Kafka1.4 Kafka架构第2章 Kafka集群部署2.1 环境准备2.1.1 集群规划2.1.2 jar包下载2.2 Kafka集群部署2.3 Kafka命令行操作第3章 Kafka工作流程分析3.1 Kafka 生产过程分析3.1.1 写入方式3.1.2 分区(Partition)3.1.3 副本(Replication)3.1.4 写入流程3.2 Broker 保存消息3.2.1 存储方式3.2.2 存储策

HAProxy高可用负载均衡集群部署

HAProxy高可用负载均衡集群部署 基本信息: 系统平台:VMware WorkStation 系统版本: CentOS Linux release 7.2.1511 (Core) 内核版本: 3.10.0-327.el7.x86_64 集群架构: 前端:HAProxy 1.虚拟FQDN:www.simpletime.net 2.VIP:192.168.39.1:DIP:172.16.39.50 3.调度服务器:Varnish1.Varnish2 4.调度算法:URL_Hash_Consist