Zeebe服务学习3-Raft算法与集群部署
Posted DotNet那些事
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了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该文件夹，然后输入
|
1
以上是关于Zeebe服务学习3-Raft算法与集群部署的主要内容，如果未能解决你的问题，请参考以下文章 |