标签: distributed-system

我想问一下,是否存在一个程序,它打算在全球范围内旅行(例如跟随一些物理力量),可能占用和释放计算资源/节点.从字面上看,这意味着某些基于代理的系统只是定期更改其位置和(在某种程度上)不可避免的配置.

一个例子是:假设你有外部传感器,空间中有免费的计算机 - 节点.自我复制代理遵循传感器的初始化程序是否有意义,但是以这种限制性方式,计算仅局限于物理业务正在进行的位置.

我想强调的是,这个问题只是为了"理论上的"乐趣,因为除了优化"过时的"(替代？)代理处理外,我看不到所提到的限制的任何实际好处.但也许它可能有一些兴趣.谢谢!

编辑:很明显病毒是合适的例子,尽管删除这些代理很少是开发人员关心的问题.更准确地说,我对"旅行"软件感兴趣 - 也就是说,当代理的计数(或至少是顺序)是不变的时候,它只是整个系统的旅行.

我正在阅读有关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 暂停和其他原因而过载，并且时钟可能不同步。但我再次认为这是分布式系统的标准问题。

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

我在网上找到了两个定义：

顺序一致性——任何执行的结果都是一样的，就好像所有处理器的操作都是按某种顺序执行的，每个处理器的操作都按照其程序指定的顺序出现在这个序列中。

最终一致性——如果没有对给定数据项进行新的更新，最终对该项目的所有访问都将返回最后更新的值。

这些定义对我来说很清楚。但是，当最终一致性不是连续的时，我不明白。一个例子：mem 中的初始值是 0。横轴是时间。

P1:      write 1             (x)
P2:  read 0    read 0 read 0     read 1   read 1    read 1

因此，有一些顺序顺序，如果我们在 (x) 槽中放置“写入 1”，这就是顺序一致性的定义。我哪里错了？

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

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

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

我一直无法找到适合Vector Clocks和Version Vectors 的用例以及它们可能有何不同的示例。我知道它们在很大程度上以相同的方式工作，向量时钟使用receive和send函数，版本向量使用sync函数，但我不明白这两个选项之间的区别。它只是表达同一事物的两种不同方式，还是它们之间的用例存在真正的差异？

我只能找到一个有点相关的问题：“我什么时候使用像 Paxos 这样的共识算法与使用像 Vector Clock 这样的算法？”

尽管链接的答案陈述了以下内容并引用了一篇短文，但我仍然不清楚这些差异。

您可能希望将版本向量用于无领导分布式存储。您可能会为此使用矢量时钟（尽管它更适合；本文还建议您将其用于一致的快照，用于在一般分布式系统中实现因果排序等）。

根据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确认丢失以及由此导致的最终记录重复？

快速免责声明，我对 gRPC 和 RPC 很陌生，所以请耐心等待

我有两个 gRPC 服务器运行在同一个 java 应用程序上，Service A并且Service B. Service A创建多个客户端的Service B，然后同步到做的各种实例调用Service B

服务器

Service A有一个由.proto文件定义的 rpc 调用

rpc notifyPeers(NotifyPeersRequest) returns (NotifyPeersResponse);

服务器端实现，

@Override
public void notifyPeers(NotifyPeersRequest request, StreamObserver<NotifyPeersResponse> responseObserver) {
    logger.debug("gRPC 'notifyPeers' request received");
    String host = request.getHost();
    
   
    for (PeerClient c : clients.values()) {   
        c.addPeer(host);    // <----  this call
    }

    NotifyPeersResponse response = NotifyPeersResponse.newBuilder()
            .setResult(result)
            .build();

    responseObserver.onNext(response);
    responseObserver.onCompleted();
}

对等点列表clients是在之前的 …