etcd是什么东西？它和ZooKeeper有什么区别
etcd 集群的工作原理基于 raft 共识算法 (The Raft Consensus Algorithm)。etcd 在 0.5.0 版本中重新实现了 raft 算法，而非像之前那样依赖于第三方库 go-raft 。raft 共识算法的优点在于可以在高效的解决分布式系统中各个节点日志内容一致性问题的同时，也使得集群具备一定的容错能力。即使集群中出现部分节点故障、网络故障等问题，仍可保证其余大多数节点正确的步进。甚至当更多的节点（一般来说超过集群节点总数的一半）出现故障而导致集群不可用时，依然可以保证节点中的数据不会出现错误的结果。
巧豚豚
2024-12-24 广告
etcd
etcd作为最近很火的一个高可用性?键值对服务发现系统被Kubernetes等系统广泛使用
他相比与zookeeper来说更加简单，在面对较小集群时可能会效率更高些?，而且他的编写语言Go本身就是一种多线程编程语言，确实有很大吸引人的地方（虽然我不懂Go语言，但是在学习docker时也是一睹其风采了）
在Raft中，任何时候一个服务器可以扮演下面角色之一：
Leader: 处理所有客户端交互，日志复制等，一般一次只有一个Leader.
Follower: 类似选民，完全被动
Candidate候选人: 类似Proposer律师，可以被选为一个新的领导人。
leader选举阶段
消息同步阶段
Leader要求Followe遵从他的指令，都将这个新的日志内容追加到他们各自日志中：
大多数follower服务器将日志写入磁盘文件后，确认追加成功，发出Commited Ok:
在下一个心跳heartbeat中，Leader会通知所有Follwer更新commited 项目。对于每个新的日志记录，重复上述过程。
zookeeper：
zookeeper是基于paxos的简化版zab，我觉得确实很难理解?，以前看了好多遍《从paxos到zookeper》才感觉似懂非懂了，然而过了几个月发现又一脸蒙蔽了，在这里在整理一下（仅表示我自己的理解）
ZAB协议中存在着三种状态，每个节点都属于以下三种中的一种：
Looking ：系统刚启动时或者Leader崩溃后正处于选举状态
Following ：Follower节点所处的状态，Follower与Leader处于数据同步阶段；
Leading ：Leader所处状态，当前集群中有一个Leader为主进程；
在开始时，所有的节点都是looking状态并且每个节点都希望自己能成为leader节点，所有每个节点都会向集群中发送一个提案内容是选取自己作为leader节点，提案编号是ZXID(ZAB协议中使用ZXID作为事务编号，ZXID为64位数字，低32位为一个递增的计数器，每一个客户端的一个事务请求时Leader产生新的事务后该计数器都会加1，高32位为Leader周期epoch编号，当新选举出一个Leader节点时Leader会取出本地日志中最大事务Proposal的ZXID解析出对应的epoch把该值加1作为新的epoch，将低32位从0开始生成新的ZXID；ZAB使用epoch来区分不同的Leader周期),如果得到的提案的zxid比自己的大则说明发出这个题案的节点数据更新，则进行同意的投票，否则继续投自己，先得到多数的同意的节点当选为leader
现在leader就可以进行管理了，zookeeper也是两段提交的实现，客户端提交事务请求时Leader节点为每一个请求生成一个事务Proposal，将其发送给集群中所有的Follower节点，收到过半Follower的反馈后开始对事务进行提交，ZAB协议使用了原子广播协议
已赞过
已踩过<
