2

我需要想出一个解决复杂文件传输的方法。我可以做到这一点，但我想知道是否有人知道已经完成了我想做的 90% 的开源解决方案。

要求很奇怪。不要试图理解它们，它们是政治、领土和官僚主义的地狱般的混合物。

我控制两台服务器，每台服务器都从一组上游源中获取文件。我对来源有一些影响（但不是完全控制）。我的两台服务器收集这些文件并将新文件链接到处理目录（这有点简化）。

我的两台服务器，我们称它们为 A 和 B，现在必须将这些文件发送到下游的一对服务器。我几乎无法控制下游服务器，我们称它们为 X 和 Y。

  1. 文件由其文件名唯一标识。如果它有相同的文件名，它就是同一个文件。
  2. 文件可能无穷无尽。他们的名字包含一个时间戳。
  3. 服务器 A 和 B（我的服务器）通常会获得相同的文件。如果文件出现在服务器 A 上，那么它将有 98% 的可能性以相同的文件名出现在服务器 B 上。
  4. A 和 B 必须使用 sftp 或类似方法将他们收到的文件推送到 X 和 Y。我不允许在 X 和 Y 上安装软件。我不允许使用 shell 帐户，即使是受限制的帐户。现在它变得很奇怪：
  5. A 和/或 B 收到的每个文件必须由 A 或 B（但不是两者）复制一次到 X 或 Y，但不能同时复制到两者。
  6. 我上游的源可能包含同一文件的重复副本（这对我来说在 A/B 服务器上不是问题，他们每个人都可以跟踪他们提取的内容）。
  7. 必须容忍 A、B、X 或 Y 的故障（只要其伙伴仍处于活动状态）。来自 ==> A/B ==> X/Y 的文件流不能停止。

让我明白所有这一切的一点是，为了安全起见，我的本地部门希望在 A 和 B 之间复制文件，但下游接收器（不同的部门）坚持他们想要 X 和 Y 进行故障转移......但是每个文件只能复制到 A 或 B，不能同时复制（或仅在极少数情况下）。如果下游人员只管理重复文件，那将很容易（呃）。鉴于文件名可以快速识别重复，这真的不难。哦，好吧，他们不想那样做。即使 X 或 Y 失败可能会丢失一些文件。去搞清楚。

所以我正在研究一种算法来完成所有这些工作，并且我已经取得了一些进展，但是处理竞争条件、节点故障、节点重启、大多数独立的性质会有点复杂。 A 和 B 等等。如果经过一个月的努力，如果一位朋友说“你为什么不直接使用 SuperOpenSourceSolution？你可以在一天之内让它工作！”我会有点不高兴。

那么......有人知道开箱即用（或几乎如此）的解决方案吗？我知道那里有通用的 MFT 解决方案，但我还没有听说他们可以做这种事情。

我看过 rsync 但我看不出它如何处理奇怪的分布。

谢谢。

4

1 回答 1

1

看起来条件 (5) 很棘手，如果 A 和 B 可以查询您未指定的 X 和 Y 的状态，则会有所缓解。

这让我想起了可能有用的NNTP Ihave/Sendme协议。

如果你不能自由地对机器 X 和 Y 提出“你有P ”的请求，我有一种感觉，这个任务可能像经典的两军问题一样被证明是不可能的。如果是这样，那么您必须做面临不可能约束的设计人员所做的事情，或者提供一个令人满意的解决方案（例如TCP 4,3-way handshake），它可以在足够的时间内工作，或者如果“足够好”还不够好那么你必须向管理层表明他们确实要求不可能的事情。

我知道您说过不要问，但是为什么要像约束（5）那样禁止幂等转移？

于 2010-07-16T03:54:57.857 回答