对标Eureka的AP一致性

aft 适用于一个管理日志一致性的协议，相比于 Paxos 协议 Raft 更易于理解和去实现它。为了提高理解性，Raft 将一致性算法分为了几个部分，包括领导选取(leader selection)、日志复制(log replication)、安全(safety)，并且使用了更强的一致性来减少了必须需要考虑的状态。

相比Paxos，Raft算法理解起来更加直观。

Raft算法将Server划分为3种状态，或者也可以称作角色：

• Leader：负责Client交互和log复制，同一时刻系统中最多存在1个。
• Follower：被动响应请求RPC，从不主动发起请求RPC。
• Candidate：一种临时的角色，只存在于leader的选举阶段，某个节点想要变成leader，那么就发起投票请求，同时自己变成candidate。如果选举成功，则变为candidate，否则退回为follow

aft中，问题分解为：领导选取、日志复制、安全和成员变化。

复制状态机通过复制日志来实现：

• 日志：每台机器保存一份日志，日志来自于客户端的请求，包含一系列的命令
• 状态机：状态机会按顺序执行这些命令
• 一致性模型：分布式环境下，保证多机的日志是一致的，这样回放到状态机中的状态是一致的

1. Raft算法选主流程

Raft中有Term的概念，Term类比中国历史上的朝代更替，Raft 算法将时间划分成为任意不同长度的任期(term)。

（编辑：平顶山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!