go任务调度3(etcd协调服务、raft协议)

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

etcd是将数据存储在集群中的高可用k-v存储。
允许应用实时监听存储中的k-v变化。
能容忍单点故障,能够应对网络分区。

go任务调度3(etcd协调服务、raft协议)
go任务调度3(etcd协调服务、raft协议)
go任务调度3(etcd协调服务、raft协议)
(raft是一个分布式协议,管理的是日志;etcd管理的是k-v,把k-v放到日志里,kv就编程分布式集群了)
go任务调度3(etcd协调服务、raft协议)
(调用者写入请求发给leader请求写入k-v,leader会将日志实时向follower们复制,leader不会立即返回给调用者,会马上往集群follower做日志拷贝。当日志被复制给N+1个节点后(即大多数),本地提交(也就是告诉客户端提交成功),返回给调用者(客户端),为什么复制给N+1,而不是2N+1后就告诉客户端成功了呢?这就是大多数协议,也就是抽屉理论的重要表现)
go任务调度3(etcd协调服务、raft协议)
(一旦完成提交,leader会周期性把自己的提交信息告诉所有follower,这样,其他follower也会完成它们的本地提交(这是异步行为,不需要同步,只需要确保日志复制给大多数了就可以)。官方给出的写入性能是:1000次每秒)
go任务调度3(etcd协调服务、raft协议)
(raft协议本身就是在写日志。第1行是leader节点的日志,后面是4个是follower,也就是总共5个节点。日志是随着请求顺序追加,这里5个节点的大多数是3个节点。其中1-7已经被复制给了3个节点(大多数),这些是一定可以被提交不会丢失的,因为已经复制给大多数了。8总共只有两个节点有,8后面其他的更夸张。有的连3,4,5都没有,这一般是leader和follower之间产生了网络延迟,然而,没关系,只要复制给大多数就不会丢了。所以真个日志的提交已经到了第7个日志)
go任务调度3(etcd协调服务、raft协议)


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

本文来自:51CTO博客

感谢作者:梁十八

查看原文:go任务调度3(etcd协调服务、raft协议)

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

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