Etcd与zookepr等的对比

最新推荐文章于 2024-08-09 07:38:20 发布

say丶

最新推荐文章于 2024-08-09 07:38:20 发布

阅读量1.3w

点赞数 5

分类专栏：分布式文章标签： zookeeper etcd

本文链接：https://blog.csdn.net/qq_33754458/article/details/73604877

版权

本文介绍了Etcd和Zookeeper在服务发现、一致性协议（如Raft和ZAB）以及消息队列方面的差异。Etcd因其简洁的API、HTTP+JSON接口、SSL安全认证和快速写入性能而受到青睐。它使用Raft协议，相较于Zookeeper的ZAB协议，Raft更为易于理解和实现。此外，文章还讨论了Etcd作为任务队列和配置管理工具的使用。

摘要由CSDN通过智能技术生成

Etcd:

一个键值存储仓库，主要用于配置共享和服务发现。

优点：

简单：支持 curl 方式的用户 API (HTTP+JSON)
安全：可选 SSL 客户端证书认证
快速：单实例可达每秒 1000 次写操作
可靠：使用 Raft 实现分布式

raft算法

百战将军问题

拜占庭位于如今的土耳其的伊斯坦布尔，是东罗马帝国的首都。由于当时拜占庭罗马帝国国土辽阔，为了防御目的，因此每个军队都分隔很远，将军与将军之间只能靠信差传消息。在战争的时候，拜占庭军队内所有将军必需达成一致的共识，决定是否有赢的机会才去攻打敌人的阵营。但是，在军队内有可能存有叛徒和敌军的间谍，左右将军们的决定又扰乱整体军队的秩序，在进行共识时，结果并不代表大多数人的意见。这时候，在已知有成员不可靠的情况下，其余忠诚的将军在不受叛徒或间谍的影响下如何达成一致的协议，拜占庭问题就此形成。拜占庭假设是对现实世界的模型化，由于硬件错误、网络拥塞或断开以及遭到恶意攻击，计算机和网络可能出现不可预料的行为。
在一个由 Raft 协议组织的集群中有三类角色：

Leader（领袖） Follower（群众） Candidate（候选人）就像一个民主社会，领袖由民众投票选出。刚开始没有领袖，所有集群中的参与者都是群众，那么首先开启一轮大选，在大选期间所有群众都能参与竞选，这时所有群众的角色就变成了候选人，民主投票选出领袖后就开始了这届领袖的任期，然后选举结束，所有除领袖的候选人又变回群众角色服从领袖领导。这里提到一个概念「任期」，用术语 Term 表达。关于 Raft 协议的核心概念和术语就这么多而且和现实民主制度非常匹配，所以很容易理解。

Leader 选举过程

在极简的思维下，一个最小的 Raft 民主集群需要三个参与者（如下图：A、B、C），这样才可能投出多数票。初始状态 ABC 都是 Follower，然后发起选举这时有三种可能情形发生。下图中前二种都能选出 Leader，第三种则表明本轮投票无效（Split Votes），每方都投给了自己，结果没有任何一方获得多数票。之后每个参与方随机休息一阵（Election Timeout）重新发起投票直到一方获得多数票。这里的关键就是随机 timeout，最先从 timeout 中恢复发起投票的一方向还在 timeout 中的另外两方请求投票，这时它们就只能投给对方了，很快达成一致。选出 Leader 后，Leader 通过定期向所有 Follower 发送心跳信息维持其统治。若 Follower 一段时间未收到 Leader 的心跳则认为 Leader 可能已经挂了再次发起选主过程。

Leader 节点对一致性的影响

Raft 协议强依赖 Le