是否有一个 ftp 服务器充当多个其他服务器的“分发前端”？这样，当我上传文件时，它会接受内容，将它们放在其他 ftp 服务器列表中的所有其他服务器上，并且（重要的是）直到文件到达所有其他服务器时才确认上传成功？
或者，如果它可以等到（比如说） rsync 将上传的文件复制到所有其他服务器后才返回成功（或者，更一般地说，等待某些外部命令完成后才返回成功）。
背景：
我们有一个应用程序，可以将文件上传到存储库（使用 ftp 或 sftp），然后立即指示设备下载该文件（通过 http）。
我们需要存储库具有负载平衡/高可用性/弹性。我们的企业托管标准不允许共享存储。
我们对其他相关应用程序的做法是拥有多个 ftp/http 服务器，并在通知应用程序（然后是设备）使用它们之前手动将文件上传到所有服务器。负载平衡器会分配下载请求。这样做之所以有效，是因为这些应用程序不进行上传，而是我们将它们配置为使用先前上传的文件的 URL。问题应用程序不这样做，它自己进行上传。
我们可以使用 rsync 或类似程序将问题应用程序上传的文件复制到多个服务器，但这些文件的使用是即时的，因此当收到对它们的请求时，它们可能尚未复制到其他服务器。无法在此处将应用程序配置为延迟。
但是，如果 ftp 服务器在文件复制完成之前没有返回（无论是服务器本身执行所有复制/上传到其他服务器，还是等待外部命令完成），那么应用程序不会告诉设备使用这些文件，直到我们知道它们无处不在。而且一切都会正常。
有没有合适的服务器？还有其他解决问题的方法吗？（遗憾的是，无法在规定的时间内更改应用程序）
答案1
如果您需要使用 FTP，您可以编写一个脚本（可能是 Python 程序，或者使用任何提供方便的 FTP 库的语言），您的上传程序在完成向“主”服务器的上传后立即运行该脚本。此脚本将扫描应该复制到的 FTP 站点，并且在看到这些文件之前不会退出。在主服务器上，您将有另一个脚本来监视文件系统（例如使用 Linux 的通知)，当它发现有新的或被修改的文件时，就把它们上传到从属服务器。
或者，您可以使用复制文件系统。这会将问题从应用程序层的自制脚本集转移到专门用于处理复制文件的层。查看太浩湖。我引用相关句子：
用户确实依赖存储服务器来实现可用性。密文被擦除编码为 N 份，分布在至少 H 个不同的存储服务器上（N 的默认值为 10，H 的默认值为 7），以便可以从这些服务器中的任意 K 个服务器恢复（K 的默认值为 3）。因此，只有 H-K+1 个（默认值为 5）服务器发生故障才会导致数据不可用。
答案2
我认为真正的答案是“不”。您要求的不仅仅是 FTP 协议提供的功能。如果客户端发送一个 TCP 段并且服务器说“我收到了”，则客户端会发送下一个。当所有段都收到后，传输就完成了。现有协议中没有让服务器说“请稍等，我正在处理。”的钩子。
如果您修改了 FTP 服务器，使其减慢 TCP ACK 速度，直到它将字节写入其他地方，您可能会得到您想要的结果，但我担心由于 TCP 滑动窗口，您的传输也可能会变得比需要的更慢。
您本质上是在要求对 FTP 内部的文件传输操作进行两阶段提交，但这并不存在。
或许您可以考虑一下虚拟化/复制的存储系统，正如上面建议的那样。