ELI5：etcd 是如何工作的以及什么是共识算法

Question

我很难理解 etcd（在 CoreOS 中）的真正作用，因为所有那些“分布式键值存储”对我来说似乎是无形的。深入阅读 etcd，深入研究 Raft 共识算法，然后变得非常混乱。

假设 如果集群系统没有 etcd 会发生什么？

感谢您的时间和精力！

Answer 1

作为没有使用 etcd 构建分布式系统的 CoreOS 经验的人，我想我可以对此有所了解。

etcd 的想法是提供一些非常基本的原语，适用于构建各种分布式系统。原因是分布式系统从根本上来说很难。大多数程序员并不会仅仅因为有更多的机会来学习单系统程序而真正理解这些困难。自从云计算使分布式系统的构建和试验成本降低以来，这种情况在过去 5 年才真正开始转变。即便如此，there's a lot to learn。

分布式系统中最大的问题之一是共识。换句话说，保证系统中的所有节点都同意一个特定的值。现在，如果硬件和网络是 100% 可靠的，那将很容易，但当然这是不可能的。设计一种算法来围绕共识提供一些有意义的保证是一个非常困难的问题，而且很多聪明人已经投入了大量时间。 Paxos 是以前最先进的算法，但很难理解。 Raft 试图提供类似的保证，但对普通程序员来说更容易接近。然而，即便如此，正如您所发现的，了解它的操作细节和应用程序并非易事。

关于 etcd 在 CoreOS 中的具体用途，我无法告诉你。但我可以肯定地说，任何需要集群中所有机器共享和同意的数据都应该存储在 etcd 中。相反，节点（或节点子集）可以自己处理的任何内容都应该不存储在 etcd 中（因为它会产生在所有节点上进行通信和存储的开销）。

使用 etcd 可以让大量相同的机器自动协调、选举领导者并保证其键值存储中的数据历史记录相同，这样：

• 任何 etcd 节点都不会返回大多数节点不同意的数据。
• 对于集群大小 x 任意数量的机器 > x/2 可以继续运行并接受写入，即使其他机器死亡或失去连接。
• 对于任何失去连接的机器（例如，由于 netsplit），即使写入失败，它们也可以保证继续返回正确的历史数据。

键值存储本身非常简单，没有什么特别有趣的地方，但这些属性允许我们构建能够抵抗单个组件故障并可以提供正确性的合理保证的分布式系统。

Answer 2

etcd 是一个可靠的集群范围协调和状态管理系统。它建立在 Raft 之上。

Raft 为 etcd 提供了跨分布式 etcd 节点系统的事件的总排序。这有很多优点和缺点：

优势包括：

• 任何节点都可以被视为主节点
• 最少的停机时间（如果一个节点没有响应，客户端可以尝试另一个节点）
• 避免脑裂
• 一种为集群范围的协调构建分布式锁的可靠方法

• etcd 的用户可以构建分布式系统，而无需临时的、错误的、自主开发的解决方案

  例如：您将使用 etcd 来协调新 Postgres 主节点的自动选举，以便集群中仅保留一个主节点。

缺点包括：

• 出于安全原因，它要求大多数集群在回复客户端之前提交写入（通常是写入磁盘）
• 需要比单个主系统更多的网络聊天