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

Posted 2022-07-15 walt

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

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