前言
方式一:
在一个技术团队内假设角色都是 均等的,会导致什么情况呢?产品提出一个需求,就可以随便去找团队中的任意一个人去发起需求。如果这个人因为请假走了,但是他没有把需求及时同步给团队其他人,因此会导致该需求存在很大的延迟。
方式二:
在技术团队中选举一个 ** Leader角色**,产品提出的需求必须优先提给 Leader,找 Leader 先沟通。Leader 自己消化完后,在将需求传达给团队其他成员。如果 Leader 请假了,会指定某一个人充当 Leader 角色负责接收产品需求,并将需求同步给其他成员。
上述很简单的案例,可以对应理解分布式系统中的数据一致性算法。
分布式系统数据一致性算法一般都应用在中间件项目中,平时你写的业务代码,一般根本不会接触到的。
SpringCloud 家族中集成了大名鼎鼎的注册中心 Eureka 就使用的上面的 方式一 的思路来完成节点之间数据同步的,称为 **Peer To Peer **集群架构。
Eureka 当中的每个节点的地位都是均等的,每个节点都可以接收写入请求,每个节点接收请求之后,进行请求打包处理,异步化延迟一点时间,将数据同步给 Eureka 集群当中的其他节点。任何一台节点宕机之后,理论上应该是不影响集群运行的,都可以从其他节点获取注册表信息。
另外的一些开源项目,比如 Etcd、Consul,Zookeeper,还有未来会流行的国产技术阿里开源的 Nacos 项目,其中的 CP 模式也是基于 Raft 协议 来实现分布式一致性算法的。当然 Zookeeper 在 Raft 协议基础上做了一些改良,使用的 ZAB 分布式一致性协议来实现的。
在 Raft 协议出现之前,广泛使用的一致性算法是 Paxos。Paxos 算法解决的是如何保障单一客户端操作的一致性,完成每个操作都需要至少两轮的消息交换。和 Paxos 算法不同,Raft 里有 Leader 的概念,Raft 在处理任何客户端操作之前必须要选举出来一个 leader 角色,选举一个 Leader 经过至少一轮的消息交换,但是选举了 Leader 之后,处理每个客户端的操作只需要一轮消息交换。
详解 Raft 协议
接下来,围绕如下几点展开:
1)Leader选举流程
2)节点心跳检测
3)选主超时操作
4)日志复制流程
5)日志条目结构
6)Leader崩溃恢复操作
1)Leader选举流程
如果系统中只有唯一一个节点,读写操作都由这一个节点来负责,不会存在数据不一致的问题。
<