标签: distributed-system

这是来自Kubernetes 文档：

一致且高度可用的键值存储用作 Kubernetes 所有集群数据的后备存储。

Kubernetes 内部是否有单独的机制来使 ETCD 更可用？或者 ETCD 是否使用 Raft 的修改版本来实现这种超能力？

我将使用多个Paxos实现一个键值存储.我会有几个节点,其中一个是主节点.此主节点接收更新请求并将值复制到从属节点.

我的问题是如何选择主节点(或领导者)？我还可以使用Paxos算法吗？如果是这样,您是否认为有必要将paxos实现抽象为一个单元,该单元不仅可以由复制单元使用,还可以由领导选举单元使用？

如果我使用id最小的节点作为领导者？我该如何实施主租约？

谢谢你的回答.

我正在阅读有关GFS及其一致性模型的内容,但我未能掌握其中的一些内容.特别是,有人可以为我提供一个特定的示例场景(或解释为什么它不会发生):

• 并发记录追加可能导致记录重复
• 并发记录追加可能导致未定义的区域
• 并发写入(在单个块上)可能导致未定义的区域

什么是使分布式队列打勾的架构模式/解决方案？

请分享订购和非订购类型.

我最近读了很多关于拜占庭容错的论文。有一个常见的证明，需要 3m+1 台计算机来处理 m 个拜占庭故障。一般证明是这样的：

存在三个“将军”：A、B、C。假设将军们是这样沟通的，其中C是“叛徒”：

A --> B "Attack", A --> C "Attack"
B --> A "Attack", B --> C "Attack"
C --> A "Attack", C --> B "Retreat"

A receives "Attack" from both sources, and will attack.
B receives "Attack" from A but "Retreat" from C and doesn't know what to do.
C is a traitor, so his action could be anything.

因此，我们不能保证大多数参与者会达成共识。

我有点理解这个证明，但似乎忽略了一个要点。A、B、C不也各自内部计算着要做什么吗？由于A和B是这里的“忠诚”将军，因此似乎“正确”的行动是进攻。难道B在决定做什么时不允许考虑他自己的计算吗？在这种情况下，他可以轻松打破相互冲突的 A&C 输入之间的联系并决定进攻。然后，A和B都进攻，问题就解决了。这是一个与经典的拜占庭将军问题不同的问题吗？

一般来说，我想了解分布式应用程序 - 负载均衡器是单点故障吗？

我不确定，但这可以是 Apache 负载均衡器，也可以是F5 Network等提供的设备/硬件负载均衡器。

我已经看到（在论文/幻灯片上）对于同一个应用程序，设计可以有多个 apache 负载均衡器。

我与我的同事进行了讨论 - 将多个 IP 地址/虚拟机/unix 框（具有负载平衡器硬件设备）映射到相同的 DNS 域（例如 www.amazon.com） - 但是谁将负责基于什么基础/算法请求将转到哪个特定的 IP/unix 框（映射到 amazon.com/DNS）

我的问题：在请求流的开始（在第一个入口点） - 只有一台机器（它根据某种算法将请求发送到下面的负载均衡器），如果这台机器出现故障，系统会受到干扰（有多个负载均衡器）和集群等）会下降

我们使用 Spring 来运行在单节点上运行良好的计划任务。我们希望在 N 个节点的集群中运行这些计划任务，以便在一个时间点最多由一个节点执行任务。这是针对企业用例的，我们可能期望多达 10 到 20 个节点。

我研究了各种选择：

1. 使用 Quartz，它似乎是在集群中运行计划任务的流行选择。缺点：我想避免的数据库依赖。
2. 使用 zookeeper 并始终仅在领导者/主节点上运行计划任务。缺点：任务执行负载没有分布
3. 使用 zookeeper 并在所有节点上调用计划任务。但是在任务运行之前获取分布式锁并在执行完成后释放。缺点：所有节点上的系统时钟应该同步，如果应用程序过载导致系统时钟漂移，这可能是一个问题。
4. 使用zookeeper，让主节点按照时间表继续生成任务，并将其分配给随机工作者。如果先前的计划任务尚未处理，则不会分配新任务。缺点：这似乎增加了太多的复杂性。

我倾向于使用 #3，这似乎是一个安全的解决方案，假设 zookeeper 集成节点运行在一个单独的集群上，系统时钟使用 NTP 同步。这也是假设如果系统时钟同步，那么所有节点都有平等的机会获得锁来执行任务。
编辑：经过深思熟虑后，我意识到这可能不是一个安全的解决方案，因为系统时钟应该在运行计划任务的节点之间同步，而不仅仅是 Zookeeper 集群节点。我说不安全是因为运行任务的节点可能因 GC 暂停和其他原因而过载，并且时钟可能不同步。但我再次认为这是分布式系统的标准问题。

您能否告知我对每个选项的理解是否准确？或者可能有比列出的选项更好的方法来解决这个问题。

昨天有人问我这个问题。我必须编写代码将数组分为两部分，以使这两部分之和之间的差异最小。

这是我写的复杂度为O（n）的代码

function solution(a) {
  let leftSum = 0;
  let rightSum = a.reduce((acc, value) => acc + value ,0);
  let min = Math.abs(rightSum - leftSum);
  a.forEach((item, i) => {
   leftSum += a[i];
   rightSum -= a[i]; 
   const tempMin = Math.abs(rightSum - leftSum);
   if(tempMin < min) min = tempMin;
  })
  return min;
}

但是随后我被问到输入数组的长度是否为1000万，如何在分布式环境中解决此问题？

我是分布式编程的新手，在这方面需要帮助。

我曾经在一次采访中被问到，如何处理消息队列中无序传入的消息。已经有一段时间了，我还没有找到明确的答案，我想知道该领域的专家是否可以帮助我回答这个问题，以满足我自己的好奇心。

据我了解，某些消息队列提供一次性和 FIFO 保证。我还知道流系统中事件时间和处理时间的概念。例如，在像 Kafka 这样的基于日志的消息队列中，由于偏移量和消息持久性的存在，混合排序可能不太可能发生（我可能是错的）。我还考虑过使用时间戳，要求每个消息发送者在发送之前记录消息的时间，但由于时钟偏差，这充满了不一致。

考虑到所有这些，我想知道如何解决 AMQP、JMS 或 RabbitMQ 等传统消息传递系统中的混合排序问题，其中十几个物联网设备可能正在发送消息，而我作为消费者希望以正确的顺序协调它们。

根据Kafka的commitTransaction文档，如果在一定时间内没有收到响应，commitTransaction将会失败TimeoutException

请注意，如果在 max.block.ms 到期之前无法提交事务，则此方法将引发 TimeoutException。此外，如果中断，它将引发 InterruptException。在任何一种情况下重试都是安全的，但不可能尝试不同的操作（例如 abortTransaction），因为提交可能已经在完成过程中。如果不重试，唯一的选择是关闭生产者。

考虑一个应用程序，其中 Kafka 生产者发送一组记录作为事务 A。

记录成功发送到主题后，Kafka Producer 将执行commitTransaction. Kafka 集群接收提交事务请求并成功提交作为事务 A 一部分的记录。Kafka 集群发送有关成功提交的确认。

然而，由于某些问题，此确认丢失，导致TimeoutKafka 生产者commitTransaction调用出现异常。因此，即使记录已经提交到 Kafka 集群上，从生产者的角度来看，提交还是失败了。

通常在这种情况下，应用程序会在新事务 B 中重试发送事务 A 记录，但这会导致记录重复，因为它们已经作为事务 A 的一部分提交。

上述场景可能吗？您如何处理commitTransaction确认丢失以及由此导致的最终记录重复？