distributed-computing - Paxos 和发现

标签 distributed-computing paxos consensus

假设我将一些机器放在一个弹性集群中,并希望在其中运行一些共识算法(比如 Paxos)。假设他们知道网络的初始大小,比如 8 台机器。

因此,他们将运行共识算法,法定人数为 5。

现在,考虑这些情况:

  1. 我发现 CPU 太低,我将集群大小减半,减至 4 台机器。
  2. 有一个partition split,每个split有4台机器。

如果我使用当前的集群大小来获得仲裁,我就会受到分区 split 的影响。因为对于底层集群,情况 (1) 和 (2) 看起来完全一样。但是,如果我使用固定数字,我将无法缩小集群(如果我扩大集群,我会因分区而出现不一致)。

我有第三种选择,即在扩展时通知所有机器集群的大小,但是有可能在扩展之前发生分区,例如,该分区没有接收到新的大小并且有足够的法定人数以使用旧大小达成共识。

Paxos(以及任何其他安全共识算法)是否无法在弹性环境中使用?

最佳答案

基于群体的共识协议(protocol)从根本上需要群体才能运行。 Multi-Paxos 和 Raft 都可以在集群和仲裁大小动态变化的环境中使用,但必须以始终保持一致仲裁的受控方式完成。例如,如果您当前使用的簇大小为 8,并且希望将该簇的大小减小到 4。您可以这样做。但是,将集群大小减少到 4 的决定必须是经过原始 8 同意的共识决定。

你的问题有点不清楚,但听起来你是在问你是否可以安全地将你的集群大小减少到 4 作为一种恢复机制,以防某种网络分区导致你原来的 8 集群无法运行。答案实际上是否定的,因为这样做的决定不可能是双方同意的,并且试图落后于共识算法实际上肯定会导致不一致。如何定义新的 4 组?你如何保证所有同行都得出相同的结论?您如何确保他们都同时做出相同的决定?

当然,您可以手动做出所有这些决定,并通过关闭每个系统上的共识服务并手动重新配置其仲裁定义来强制系统恢复。假设您没有搞砸(对于任何现实世界的部署来说,这是一个压倒性的大假设),这将是安全的。不过,更好的方法是设计系统,使一个或两个网络分区不会停止系统(很多站点)或使用最终一致性模型来优雅地处理偶尔的网络分区。没有绕过 CAP 限制的 Elixir 。

关于distributed-computing - Paxos 和发现,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/34422868/

相关文章:

algorithm - 什么时候使用 Paxos(真正的实际用例)?

consensus - RAFT 中是否存在竞争条件?

algorithm - 为什么使用空操作来填补 paxos 事件之间的空白是合法的?

angularjs - Node.js 的共识算法

distributed-computing - 避免在分布式系统中过度使用共识协议(protocol)

distributed - Raft 如何处理 AppendEntries RPC 中的延迟回复?

c - 生成字符串

java - 需要实现P2P的分布式哈希表

java - 什么是 zookeeper 端口及其用途?

windows - 请推荐 Microsoft HPC 的替代方案