假设我有 3 个节点和两种可能的 ArangoDB 配置：
或
现在假设节点 1 和 2 发生故障。哪种配置更有弹性？ ActiveFailover 配置中的 Follower 是否可以访问，即使运行 Agent 的节点 1 关闭了？还是集群配置会更优雅地处理这种情况，让节点 3 可用于处理读取和写入？
【问题讨论】：
标签： arangodb
不幸的是，这两种配置都不能在两个节点出现故障时存活下来。这样做的原因是，没有任何一个支持一致性而不是可用性的配置将永远能够只使用 3 个节点中的一个节点。这是因为这个节点可能是网络拆分的较小一半。如果我们继续使用单个节点，那么我们可能会面临裂脑场景，在这种情况下，其他 2 节点的一半也会继续，我们最终会出现不一致的状态。
在 ArangoDB 中，我们选择了一致性而不是可用性。因此，在任何有 2 个节点出现故障的 3 节点集成中，幸存的节点将不会继续服务，而是等待它结束，直到至少有一个节点恢复。
现在让我们比较两个配置在一个节点故障的情况下：ActiveFailover 配置将继续工作，因为至少两个数据节点（Leader 和 Follower）中的一个会存活下来，并且与第三个一起运行的只有一个代理，他们可以选举一个领导者，并使幸存的数据节点成为领导者。如果唯一代理节点失败，那么领导选举仍然有效，因为其他两个节点实际上也运行一个代理。但请注意，如果当前 Leader 失败，则会发生故障转移，但由于复制只是异步的，因此可能会丢失一些已提交的数据！
集群的行为方式基本相同，只是它具有更对称的设置。如果任何一个节点发生故障，其他两个可以继续。如果所有集合至少具有 replicationFactor 2，则故障转移可以将每个分片的领导权转移到幸存的节点。由于复制是同步的，因此不会丢失任何已提交的数据。这是集群相对于 ActiveFailover 设置的优势。但是，请注意，由于同步复制，操作的延迟可能会更高，并且由于并非所有数据都集中在单个节点上，因此某些操作的性能可能会更差，因为我们的数据局部性较少。无论如何，没有免费的午餐，最终还是要付钱的。
【讨论】：