问题标签 [paxos]

假设我有这样的 SQL 模式-

现在每个节点都尝试插入这样的值-

无论哪个节点能够成功插入，现在都可以被认为是主节点。我们可以在 sql 表中添加一个新的列时间戳，这样陈旧的锁就可以被移除。

通过这个方案，我可以很容易地选出一个主节点。为什么我需要 Paxos/Raft 等？

我正在学习分布式系统中的共识协议知识。这样的分布式系统对数据库进行主备份。

我了解到“每个共识协议都可以永远循环”。来自 基于 paxos 的复制键值存储的领导者选举

“每个共识协议都可以永远循环”的信息来源在哪里？

Status update:问题已回答。rystsov 和另一个职位的另一个人提供了相同的信息来源。

能否分享更多的理论成果和相应的信息来源？

我们正在尝试构建一个系统，该系统从 Cassandra 数据库获取要执行的任务列表，然后通过某种组共识创建一个执行计划（最好在一个节点上），然后由整个服务器集群同意并执行. 我们真的不想添加任何额外的软件，例如 Redis 或 AMPQ 系统，而是将共识直接内置到所有运行作业的服务器中。到目前为止，我们已经找到了 Skiff，它是 Raft 算法的一种实现，看起来可以完成任务，但我想知道是否有人以纯 Node.js 的方式找到了一个优雅的解决方案，不涉及外部消息传递系统。

所以我试图在 Cassandra 中进行 CAS（比较和设置）类型操作，我只想在特定的非主键列是NULL或由客户端代码提供的情况< ?下进行数据更新。?

我该怎么做呢？像下面这样的东西不起作用：

我得到的错误类似于以下内容：

如何在 Cassandra 2.0/2.1 中执行此操作？

etcd 使用的 Raft 算法和 Zookeeper 使用的 ZAB 算法都是使用复制日志来更新状态机。

我想知道是否可以通过简单地使用领导者选举和版本化值来设计一个类似的系统。以及为什么这些系统决定使用复制日志。

如果我们有以下设置，我就是我的例子

• 机器 A（Leader），包含版本 1
• 机器 B（跟随者），包含版本 1
• 机器 C（跟随者），包含版本 1

写入将是这样的：

1. 机器 A 接收写入请求并存储待处理的写入 V2
2. 机器 A 向机器 B 和机器 C 发送准备请求
3. 追随者（机器 B 和机器 C）向领导者（机器 A）发送确认
4. 领导者（机器 A）从机器的 quorum 收到确认后，它知道 V2 现在已提交，并向客户端发送成功响应
5. Leader（机器 a）向 Follower（机器 A 和机器 B）发送 finalize 请求，通知他们 V2 已提交，V1 可以被丢弃。

为了使该系统正常工作，在获得领导者租赁后领导者发生变化时，领导者机器必须通过在接受请求之前从节点的法定人数中读取来获取最新的数据版本。

我尝试在 TLA+ Toolbox（工具箱）中建模 Paxos（ Paxos 示例）。我应该在模型中输入什么数字才能使其工作？或者还有其他方法可以在这个工具箱中确认这个算法吗？

基于此代码：

我尝试这样的数字：

接受者 <- [11,12,13,14,15];

法定人数 <- [11,12,13,14,15,16,17,18,19];

值 <- [0,1]；

但我收到 ArrayIndexOutOfBoundsException 错误。

Zookeeper 管理员指南说以下内容：

由于 ZooKeeper 服务器的事务日志中的某些文件损坏，服务器可能无法读取其数据库并且无法启动。你会在加载 ZooKeeper 数据库时看到一些 IOException。

在这种情况下，请确保您的 ensemble 中的所有其他服务器都已启动并正常工作。在命令端口上使用“ stat ”命令查看它们是否健康。在您确认 ensemble 的所有其他服务器都已启动后，您可以继续清理损坏服务器的数据库。删除 datadir/version-2 和 datalogdir/version-2/ 中的所有文件。重新启动服务器。

我如何从以下信息中知道当前 Zookeeper Server 何时可以安全地以空状态重新启动？

对于追随者

对于领导者

尝试连接到当前集合并尝试使用 Zookeeper 客户端库创建会话也是验证集合当前具有法定人数并且可以安全加入空状态的好方法吗？

在网络分区或节点崩溃的情况下，大多数分布式原子广播协议（如扩展虚拟同步或 Paxos）都需要运行节点来保持记录消息，直到崩溃或分区节点重新加入集群。当一个节点重新加入集群时，重播记录的消息足以重新获得当前状态。

我的问题是，如果分区/崩溃节点需要很长时间才能再次加入集群，那么最终日志会溢出。这似乎是一个非常实际的问题，但他们的论文中仍然没有人谈论它。我缺少一个非常明显的解决方案吗？或者我的理解不正确。

PeerAwareInstanceRegistryImpl会在注册发生变化时同步到其他peer，代码如下：

我对多个 eureka 服务器的分布式一致性感到困惑。当复制操作失败时。它只是捕获了 throwable。为什么不使用 gossip、paxos 等一致性算法来保证更高的一致性呢？

我看到了wiki的描述，知道 eureka 只是让它暂时不一致。服务器试图尽可能有弹性。啊哈上限理论！

在 paxos 算法的第二阶段，如果接受者之前已经选择了一个值，那么提议者会发出一个接受请求，其中包含从接受者那里获得的数字n和值。v我的问题是为什么提议者这样做？因为一旦选择了一个值，它就是永久的并且不能更改，所以在这种情况下，提议者只是在学习选择的值，该值是在准备请求的响应中发送的。为什么它会要求接受已经接受的值？