• 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集群了。

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

  • 相关阅读:
    程序化量化
    净资产收益率大于10%的选股公式
    转json工具网址https://www.bejson.com/devtools/sql2csharppojo/
    PR 和 MR 的关联
    npm 和 pip 介绍
    QA(测试) 工作准则建议
    2021 年终总结 和 2022 年 flag
    测试排期估时多长合理?
    看完《许三观卖血记》有感
    怎么确定自己的测试准备工作已经做好了?
  • 原文地址:https://www.cnblogs.com/walt/p/11359714.html
Copyright © 2020-2023  润新知