传入文件的轮询

一堆具有唯一文件名的新文件通常会在一个服务器上“出现” ¹。（与每天数百GB的新数据一样，解决方案应可扩展到TB。每个文件的大小为几兆字节，最大为几十兆字节。）

有几台计算机处理这些文件。（数十种，解决方案应可扩展到数百种。）应该可以轻松地添加和删​​除新机器。

有些备份文件存储服务器上必须复制每个传入文件以进行归档存储。数据不得丢失，所有传入文件都必须最终交付到备份存储服务器上。

每个传入文件都将被传送到一台计算机上进行处理，并且应将其复制到备份存储服务器。

接收方服务器在发送文件后无需存储文件。

请提供一种可靠的解决方案，以上述方式分发文件。解决方案不得基于Java。最好使用Unix-way解决方案。

服务器基于Ubuntu，位于同一数据中心。所有其他内容均可根据解决方案要求进行调整。

¹ 请注意，我故意省略了有关文件传输到文件系统的方式的信息。原因是如今，文件是由第三方通过几种不同的传统方式发送的（足够奇怪的是，通过scp和ØMQ）。在文件系统级别削减跨集群接口似乎更容易，但是如果一个或另一种解决方案实际上需要某些特定的传输，则可以将旧式传输升级为该传输。

这是您要寻找的解决方案。该系统的制作没有涉及Java，只有开放源代码才可用。除了我作为示例使用的技术外，此处介绍的模型还可以与其他技术配合使用。

1. 文件通过HTTP POST到特定的循环DNS地址。
2. 然后，发布文件的系统会通过另一对负载均衡器将作业放入AMQP系统（此处为兔子MQ）中，以开始处理工作流程。
3. 接收HTTP POST的负载均衡器分别位于一组OpenStack Swift对象存储服务器的前面。
   • 每个负载均衡器后面都有两个或多个OpenStack Swift对象存储服务器。
   • 如果目标是HA本身，则可能是“ Round Robin不是HA”。YMMV。
   • 为了提高耐用性，RRDNS中的IP可以是单独的热备用LB群集。
4. 实际获得POST的对象存储服务器将文件传送到基于Gluster的文件系统。
   • Gluster系统应同时是分布式的（也称为分片的）和复制的。这使其可以缩放到傻密度。
5. AMQP系统将第一个作业（进行备份）分派到可用的处理节点。
6. 处理节点将文件从主存储复制到备份存储，并根据需要报告成功/失败。
   • 故障模式处理未在此处绘制。从本质上讲，请继续尝试直到可行。如果它永远无法工作，请执行异常过程。
7. 备份完成后，AMQP然后将处理作业分派到可用的处理节点。
8. 处理节点要么将文件拉到其本地文件系统，要么直接从Gluster处理它。
9. 处理节点将处理产品存放到任何地方，并向AMQP报告成功。

如果有足够的服务器，此设置应能够以极高的速度摄取文件。如果足够大，则可以获取10GbE聚合的摄取速度。当然，要快速处理那么多数据将需要处理计算机级别的更多服务器。此设置应扩展到一千个节点，甚至可以扩展到更多（尽管到底有多远取决于您在做什么事情）。

深刻的工程挑战将在于隐藏在AMQP流程中的工作流管理流程中。这就是所有软件，并且可能是根据系统需求定制构建的。但这应该充满数据！

鉴于您已经澄清了文件将通过scp到达的情况，前端服务器根本不存在任何理由，因为传输机制可以在第3层进行重定向。

我将LVS控制器（一对）放在前面，后面有一个处理服务器池和一个循环重定向策略。这使向池中添加服务器或从池中删除服务器变得非常容易，由于没有前端服务器掉落，因此增加了可靠性，这意味着我们不必解决有关从中获取文件的拉/推问题。前端到处理服务器，因为没有前端。

然后，每个池服务器在接收文件时应做两件事-首先，将其复制到档案存储中，然后处理文件并按其方式发送。