一组具有唯一文件名的新文件定期“出现”在一台服务器上。（就像每天数百 GB 的新数据一样，解决方案应该可扩展到 TB 级。每个文件都有几兆字节大，最多几十兆字节。）
有几台机器可以处理这些文件。（数十台，解决方案应该可以扩展到数百台。）应该能够容易地添加和删除新机器。
有备份文件存储服务器，每个传入文件必须复制并存档。数据不得丢失，所有传入文件最终都必须传送到备份存储服务器上。
每个传入的文件都必须传送到一台机器进行处理，和应复制到备份存储服务器。
接收方服务器发送文件后无需存储文件。
请提供一个强大的解决方案，以上述方式分发文件。解决方案一定不基于 Java。Unix 方式的解决方案更可取。
服务器基于 Ubuntu，位于同一数据中心。其他一切都可以根据解决方案要求进行调整。
1请注意，我有意省略了有关文件传输到文件系统的方式的信息。原因是如今第三方通过几种不同的传统方式发送文件（奇怪的是，通过 scp 和通过 ØMQ）。在文件系统级别切断跨集群接口似乎更容易，但如果一个或另一个解决方案实际上需要某种特定的传输方式 — 可以将传统传输方式升级到该传输方式。
答案1
这是您要找的解决方案之一。此系统的制作不涉及 Java，仅涉及现成的开源代码。此处介绍的模型可以与我用作示例的技术以外的其他技术配合使用。
- 文件通过 HTTP POST 发送至特定的 Round-Robin DNS 地址。
- 然后，发布文件的系统通过另一对负载均衡器将作业放入 AMQP 系统（此处为 Rabbit MQ）中，以启动处理工作流程。
- 接收 HTTP POST 的每个负载均衡器都位于一组 OpenStack Swift 对象存储服务器的前面。
- 每个负载均衡器背后都有两个或更多个 OpenStack Swift 对象存储服务器。
- 如果目标本身是 HA，则“循环赛不是 HA”。YMMV。
- 为了增加耐用性，RRDNS 中的 IP 可以是单独的热备用 LB 集群。
- 实际获取 POST 的对象存储服务器将文件传送到基于 Gluster 的文件系统。
- Gluster 系统应同时具有分布式（又称分片式）和复制性。这样它就可以扩展到任意密度。
- AMQP 系统将第一个作业（进行备份）调度到可用的处理节点。
- 处理节点将文件从主存储复制到备份存储，并根据需要报告成功/失败。
- 这里没有图示故障模式处理。本质上，要不断尝试，直到成功为止。如果失败，则运行异常过程。
- 备份完成后，AMQP 会将处理作业调度到可用的处理节点。
- 处理节点要么将文件拉到其本地文件系统，要么直接从 Gluster 进行处理。
- 处理节点将处理产品存放到任何地方，并向 AMQP 报告成功。
只要有足够的服务器，此设置应该能够以极快的速度提取文件。如果您将其扩大到足够的规模，应该可以实现 10GbE 聚合提取速度。当然，加工如此快速地处理如此多的数据将需要更多 Processing 级的服务器。此设置应扩展到一千个节点，甚至可能更多（不过具体到什么程度则取决于您要用所有这些做什么）。
深度工程挑战在于隐藏在 AMQP 进程中的工作流管理进程。这些都是软件，可能根据系统需求定制。但它应该有充足的数据！
答案2
鉴于您已明确文件将通过 scp 到达，我根本看不出前端服务器存在的任何理由，因为传输机制是可以在第 3 层重定向的。
我会将一个（一对）LVS 控制器放在前面，后面是处理服务器池，并采用循环重定向策略。这样可以非常轻松地向池中添加或从池中减去服务器，这提高了可靠性，因为没有前端服务器会出故障，这意味着我们不必解决将文件从前端传输到处理服务器的拉/推问题，因为没有前端。
每个池服务器在接收文件时应该做两件事 - 首先，将其复制到档案存储，然后处理该文件并将其发送。