手撸golang etcd raft协议之1

ioly · · 358 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

手撸golang etcd raft协议之1

缘起

最近阅读 [云原生分布式存储基石:etcd深入解析] (杜军 , 2019.1)
本系列笔记拟采用golang练习之
gitee: https://gitee.com/ioly/learning.gooop

raft分布式一致性算法

分布式存储系统通常会通过维护多个副本来进行容错,
以提高系统的可用性。
这就引出了分布式存储系统的核心问题——如何保证多个副本的一致性?

Raft算法把问题分解成了领袖选举(leader election)、
日志复制(log replication)、安全性(safety)
和成员关系变化(membership changes)这几个子问题。

Raft算法的基本操作只需2种RPC即可完成。
RequestVote RPC是在选举过程中通过旧的Leader触发的,
AppendEntries RPC是领导人触发的,目的是向其他节点复制日志条目和发送心跳(heartbeat)。

raft节点的有限状态机

image

流程梳理

  • 默认以Follower状态启动,租期号term=1
  • 启动参数静态配置了集群的节点数和各节点地址
  • Follower和Candidate节点不响应客户端请求
  • 等待Leader心跳超时, 进入Candidate状态
  • 向其他集群节点发起RequestVote RPC请求
  • 一个任期内,一个Raft节点最多只能为一个候选人投票,先到先得
  • 如果获得N/2+1(含自己那票)票,则进入Leader状态
  • Leader开始响应客户端请求,每条写请求都将生成操作日志,并复制给其他节点
  • 大多数Follower响应日志复制指令后, 回复客户端OK
  • Follower提交操作日志到本地状态机
  • Leader租期结束,重新进入Candidate状态

(未完待续)


有疑问加站长微信联系(非本文作者)

本文来自:Segmentfault

感谢作者:ioly

查看原文:手撸golang etcd raft协议之1

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

358 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传