问题标签 [paxos]

我的问题是“是否可以使用 C 类寻址为分布式容错应用程序实现 paxos 算法，而不使用使用 D 类的基于 Java 的多播？ ”

实际上，无论我在 Quora 上读到什么像这样的 Paxos ，他们都建议应该使用 UDP，这需要 D 类寻址。

在我的项目中，我实现了一个用于文件服务器下载的分布式应用程序，使用的 C 类地址范围为192.168.1.#. 现在，如果我切换到 D 类地址进行多播，我将不得不到处更改我的服务器地址，这在我看来是一项艰巨的任务！

注意：- 我知道有类寻址现在已经过时了，我们到处都使用无类寻址。但是，我使用该术语来澄清我的 IP 地址。

如果您的答案是否定的，那么请建议我如何在不更改大部分代码的情况下轻松切换到多播。谢谢。

我读过 paxos 可用于通过将操作日志同步到复制来保持复制同步。

据我了解，每个 paxos 实例都会在操作中定义一个日志 ID

理想情况下，每个节点上的日志都是这样的，因此它们按照日志 id 的顺序应用操作日志，以保持数据彼此一致

1. 删除 ....
2. 添加 ...
3. 消除 ...

据我了解，日志ID不会一一增加，所以日志应该是这样的：

1.删​​除....

3.添加...

5.删除...

我想我的问题是在 paxos 实例期间，如果一个节点关闭，它实际上是如何工作的？

因为这个节点会丢失一个日志条目，这个节点在恢复后怎么知道它丢失了一个条目？

根据维基

https://en.wikipedia.org/wiki/Paxos_(computer_science)#Multi-Paxos

Multiple-paxos 似乎以确保 LOG ID 始终无间隙地增加的方式实现。

也就是说，据我了解，每个副本仍然需要定期与一些人交谈，以确保它们是最新的变化。

我正在尝试使用 Paxos 在大小约为 50MB 的文件上保持节点之间的共识，并在各个节点上不断进行修改。我遇到了实用性问题。要求：

1. 跨数百个节点同步一个 50MB 以上的文件
2. 对此文件进行更改，可以从任何节点进行，并且不太可能直接相互竞争，最多在几秒钟内通过网络传播
3. 加入网络的新节点可以在几分钟（<1 小时）内按照 Paxos 消息构建整个文件

我面临的问题是似乎没有办法同时实现目标 2 和 3。

以下是我目前考虑过的选项：

• 每轮同步整个文件——完全不切实际，Paxos 轮次需要几分钟
• 仅同步对文件的更改——对于目标 1 和 2 来说是合理的，但会破坏目标 3，因为新节点只能在每个状态单元更改后才能同步整个文件
• 每轮同步更改和文件的随机部分——我不确定 Paxos 是否允许这样做。节点将能够根据自己的更改验证更改（允许新更改），并且能够根据其版本的所述部分验证文件的随机部分，但这实用吗？

我认为第三种选择是最好的，但我不确定 Paxos 是否允许这样做。想法是将每轮交换的数据限制为 1500 字节，并主要用对文件的更改来填充这 1500 字节。大多数轮次，文件将保持不变，而发生变化的轮次很可能少于 100 字节的更改状态，因此其他 1400 字节可以用文件的某些部分填充，这将允许构建新节点随着时间的推移整理整个文件。这实用吗？这个问题已经解决了吗？

我正在学习 MIT 6.824 课程，我有一个关于 paxos 的问题。当提议者向接受者发送准备时，接受者将返回一个带有 n 和 v 的 prepare_ok 最高接受者看到。我想知道为什么接受者需要返回 n 和 v？

我对 paxos 有一些困惑，特别是在数据库事务的上下文中：

在“paxos made simple”一文中，它说在第二阶段，提议者需要选择其中一个接受者之前接受过的具有最高序列号的值之一（如果不存在这样的值，则提议者可以自由选择建议选择原始值）。

问题：

1. 一方面，我理解这样做是为了保持共识。但另一方面，我对实际价值感到困惑——“必须向接受者发送以前接受过的价值”有什么意义？

2. 在数据库事务的上下文中，如果它需要提交一个新值怎么办？是否需要启动一个新的 Paxos 实例？

3. 如果上述问题的答案是“是”，那么接受者如何重置状态？（据我了解，如果它不重置状态，提议者将被迫发送之前已接受的旧值之一，而不是自由提交新值。）

最近在学习Paxos，到现在已经对它的工作原理有了基本的了解。但是谁能解释一下 Paxos 如何处理丢包和新节点加入？如果提供一个简单的例子可能会更好。

我有一个运行 Cassandra 2.0.12（DataStax 社区版）的 9 节点集群。我不得不扩展这个集群，所以按照http://docs.datastax.com/en/cassandra/2.0/cassandra/operations/ops_add_node_to_cluster_t.html建议的 DataStax 添加了 3 个节点

我们的应用程序利用了轻量级事务功能，我们发现虽然新节点处于 JOINING 状态（数据从旧节点流式传输到它们），但大多数涉及 LWT 的应用程序调用都因以下错误而失败

com.datastax.driver.core.exceptions.UnavailableException：没有足够的副本可用于一致性序列查询（需要 6 个但只有 5 个活着）

我不确定

1. 为什么当我的复制因子为 3 时错误消息说它需要 6 个节点。这是否意味着当数据从旧节点流式传输到新节点现在由新节点拥有的范围时，PAXOS 将要求新旧节点都是参与各种 PAXOS 阶段？

2. 我的理解是，当新节点加入集群时，旧节点仍会收到所有客户端请求（对于现在由新节点拥有的令牌范围），但旧节点会将所有 WRITE 请求转发给新节点，同时仍为 READ 请求提供服务. 这如何与 LWT 和 Paxos 一起工作，因为 CAS 操作意味着 READ 和 WRITE。那么这可能是在执行任何 CAS（如果不存在）操作时需要 6 个节点响应的原因吗？即使是这样，为什么大多数 CAS 操作都失败了？新节点加入时 LWT 是否可能存在错误，或者新节点非常繁忙且没有响应的事实。就我而言，我确信新节点在它们处于 JOINING 状态时并不是一直非常忙，尽管 LWT 调用在它们处于 JOINING 状态时几乎整个时间都失败了。

一旦 3 个新节点中的两个加入集群，我们可以看到错误数量大大减少，并且一旦第 3 个节点也加入（第一个节点加入大约需要 5 小时，然后其他节点在接下来的 10-20 分钟内加入），所有错误都消失了，我们的应用程序恢复正常。

有人可以解释一下这种行为，以及当我们实际升级“生产环境”时我们能做些什么来避免这些错误（上述测试是在我们的测试环境中完成的）。

下图是基本 Paxos 的消息流，在阶段 2a，Leader 为其提案 1 选择值 Vn，并向每个接受者发送 Accept!(1,Vn)。我的问题是：如果这三个消息中的两个丢失了怎么办？我的意思是只有接受者 1（不是多数）接收接受！（1，Vn）。Acceptor 1 会接受这个请求吗？然后广播给每个学习者？选择这个值？

假设我将一些机器放在一个弹性集群中，并希望在它们中运行一些共识算法（比如 Paxos）。假设他们知道网络的初始规模，比如 8 台机器。

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

现在，考虑这些情况：

1. 我看到 CPU 太低了，我将集群大小减半，减少到 4 台机器。
2. 有一个分区拆分，每个拆分得到4台机器。

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

我有第三种选择，即在扩展时通知所有机器集群的大小，但是有可能在扩展之前发生分区，例如，该分区没有收到新的大小并且有足够的仲裁使用旧尺寸的共识。

Paxos（以及任何其他安全的共识算法）在弹性环境中无法使用吗？

在Spanner：Google 的全球分布式数据库，第 2.1 节中，我们读到：

为了支持复制，每个 spanserver 在每个 tablet 上实现一个 Paxos 状态机。（早期的 Spanner 化身支持每个平板电脑多个 Paxos 状态机，这允许更灵活的复制配置。该设计的复杂性导致我们放弃了它。）

Paxos 状态机用于实现一致复制的映射包。

这个单一的 Paxos 状态机是否类似于“Paxos Made Simple”中提到的 Paxos 状态机？

我很好奇一旦一位新领导人选出了如何学习所有丢失的数据。任何人都可以在 Spanner 中描述 Paxos 组的详细实现吗？