CP模型--Raft协议介绍



前言

本文对分布式系统下,强一致性模型(cp)之Raft 算法的实现进行介绍。


一、Raft 是什么:

Raft 是工程上使用较为广泛的 强一致性、去中心化、高可用 的分布式协议,用于管理副本复制(Log Replication)。相比传统的 Paxos 算法,Raft 将大量的计算问题分解成为了一些简单的相对独立的子问题,并有着和 Multi-Paxos 同样的性能。

二、Raft的工作原理:

CP协议raft 实现动画版: http://thesecretlivesofdata.com/raft/

2.1 Raft 节点的3中状态:

  • Leader:Leader 会一直工作,直到失败。Leader 节点负责处理所有客户端的请求,定期向集群中的 Follower 节点发送心跳消息,证明自己还健在。
  • Follower:Follower 只响应来自其他服务器的请求。Follower 节点不处理 Client 的请求,而是将请求重定向给集群的 Leader 节点,由 Leader 节点进行请求处理。
  • Candidate:如果 Follower 长时间没有收到任何通信,它将成为 Candidate 并发起选举。获得多数选票的 Candidate 成为新的 Leader。

2.2 集群启动 leader 节点的选举:

  • 集群中的节点一开始都是 fllower 从节点;

  • 当集群中接收不到leader 节点的心跳,在选举的超时时间过完后,触发选举,此时从节点变为候选节点
    在这里插入图片描述

  • 从节点发送选举投票给到其它的节点(自己先投给自己一票),其它节点接到请求并返回值;
    在这里插入图片描述 - - 返回选票结果:

投票限制:
1) 在任一任期内,单个节点最多只能投一票;
2) 候选人知道的信息不能比自己的少;
3) first-come-first-served 先来先得;
投票结果:
(1) 收到majority的投票(含自己的一票),则赢得选举,成为leader;
(2)被告知别人已当选,那么自行切换到follower;
(3)一段时间内没有收到majority投票,则保持candidate状态,重新发出选举;

在这里插入图片描述

  • 改从节点获取到集群内过半节点的投票返回,则晋升为leader 节点,然后发送心心跳给到从节点;

在这里插入图片描述

在这里插入图片描述

2.3 数据的同步(日志复制):

  • 将数据发送到leader节点,leader 节点将数据写入到log 日志中;
    在这里插入图片描述

  • 日志写入完成,将日志数据发送给到其它的从节点(在心跳中将数据一并传输);
    在这里插入图片描述

  • 从节点写入数据到各自 的日志中,然后返回成功的状态给到leader 节点;
    在这里插入图片描述

  • leader 接收到集群节点过半都已经成功,则将本机数据进行更新(提交),响应客户端,并发送命令到从节点,各从节点完成数据更新;
    在这里插入图片描述

  • 如果不是过半成功,则不更数据,并并发送命令到从节点,各从节点不进行数据更新;

2.4 leader 重新选举:

当出现网络故障或者leader 挂掉时,leader和follower 之间的心跳超时,触发leader的重新选举:

  • 从节点在重置自己成为候选者的时间到达后,成为候选者;
  • 然后发送选举给到集群内其它节点;
  • 获取半数投票成为leader 节点,然后发送心心跳给到从节点;
  • 从节点接收到leader 心跳,则重置自己成为候选者的时间;

2.5 网络分区故障:

当出现网络分区,A&B,C&D&E,则会出现两个leader节点;
在这里插入图片描述

此时如果客户端,发送数据给到 NodeB 不满足过半写入,则数据写入不成功;如果发送给到 NodeC ,有3个节点(5/2 +1 =3)则数据写入成功;

网络分区恢复:

  • 则通过一定的规则得到唯一的一个新leader 节点;
  • 旧的leader节点数据及旧的从节点,则回滚到没有没有提交的日志;然后接收新的leader 的日志数据;

2.6 超时时间控制:

  • 选举的超时时间:每个节点从fllower 变为 候选节点 ,每个节点的时间在150ms 和300 ms 之间;减少多个节点同时进行选举投票,产生候选者获取到投票数量相同 从而触发再次选举进入死循环;
  • 如果产生候选者获取到投票数量相同,则等待选举的超时时间之后重新进行投票选举;

总结:

raft 通过投票(过半)当选为leader 节点,只有leader 节点负责对客户端的数据写入操作;leader 在接收到数据之后,现在本地记录日志,然后将日志信息跟随心跳一起发送到集群内的从节点,从节点完成日志数据记录后,返回leader,只有过半的从节点都写入日志成功,则进行数据提交(数据真正的写入成功),否则 进行数据的回滚;当心跳超时时则会重新触发leader 的选举。

参考:

Raft协议;

### Nacos 中 Raft 协议的配置与实现 Nacos 是一个用于动态服务发现、配置管理和服务管理的开源项目。为了支持高可用性和强一致性,Nacos 在其内部实现中引入了 Raft 协议来处理集群中的 Leader 选举和 CP 数据的一致性同步[^2]。 #### 1. **Raft 协议的作用** Raft 协议是一种分布式共识算法,主要解决在分布式系统中如何达成一致的问题。它通过领导者选举、日志复制和安全性机制,确保了分布式环境下的数据一致性。在 Nacos 中,Raft 主要被应用于以下几个方面: - 集群内的 Leader 选举。 - 确保服务注册表和服务实例信息的数据一致性。 这些功能由 Nacos 借助 JRaft 库实现,JRaft 提供了一个高性能的 Java 版本 Raft 实现。 --- #### 2. **Nacos 使用 Raft 的场景** Nacos 将一致性协议的能力下沉到内核模块中,使其能够很好地服务于服务注册发现模块和配置管理模块[^3]。具体来说: - **服务注册发现**:当客户端向 Nacos 注册服务时,Nacos 需要在多个节点之间保持服务实例的状态一致性。此时,Raft 被用来保证服务注册表的信息能够在所有副本间同步并达到一致性。 - **配置管理**:对于全局共享的配置文件,Nacos 同样依赖于 Raft 来保障不同节点上的配置内容是一致的。 --- #### 3. **Raft 协议的具体实现方式** 以下是 Nacos 中 Raft 协议的主要实现细节: ##### a) **Leader 选举** 在启动阶段或者发生网络分区的情况下,Nacos 集群会触发 Leader 选举过程。每个候选者都会尝试获取多数派的支持成为新的 Leader。一旦某个节点成功当选为 Leader,则其他节点进入 Follower 或 Candidate 状态[^2]。 ##### b) **日志复制** Leader 接收到写请求后,先将其记录到本地的日志中,随后通知所有的 Followers 追加相同的条目。只有当大多数节点确认接收该命令之后,这条指令才会被认为已提交,并应用到状态机上。 ##### c) **实例信息持久化** `RaftConsistencyServiceImpl.put()` 方法负责完成实例信息的持久化操作。此方法对应的是 `consistencyService.put(key, instances)` 的调用路径[^5]。这意味着每次更新都需要经过完整的 Raft 流程才能生效。 --- #### 4. **Nacos 中 Raft 的配置方法** 如果希望启用基于 Raft 的一致性模型,可以通过修改 Nacos 的配置文件来进行设置。以下是一个典型的配置示例: ```yaml nacos: core: consistency-model: raft # 设置一致性模型Raft cluster: nodes: node1:8848,node2:8848,node3:8848 # 定义集群成员列表 ``` 在此基础上,还需要确保 JVM 参数正确加载以及相关依赖库(如 JRaft)已被引入至项目的 classpath 下。 另外需要注意的是,默认情况下 Nacos 可能采用更简单的 AP 类型协议(例如 Distro),因此显式指定上述参数非常重要。 --- #### 5. **总结** 综上所述,Nacos 对 Raft 协议的应用不仅限于理论层面,而是深入到了实际业务逻辑当中。无论是服务注册还是配置分发,都离不开这一底层支撑技术的帮助。借助成熟的第三方工具(比如 JRaft),开发者可以更加专注于构建高层次的功能特性而无需过多关心复杂的分布式协调问题。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值