传入文件的roundrobin

一个具有唯一文件名的新文件在一台服务器上经常“出现” ¹ 。（像每天数百GB的新数据一样，解决scheme应该可以扩展到千兆字节，每个文件大小可以达到几兆字节，最高可达几十兆字节。）

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

有备份文件存储服务器上每个传入的文件必须复制的档案存储。数据不能丢失，所有传入的文件必须在备份存储服务器上传送。

每个传入文件myst被传送到一台机器进行处理，并应复制到备份存储服务器。

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

请build议一个强大的解决scheme，以上述方式分发文件。解决scheme不得基于Java。 Unix方式的解决scheme是可取的。

服务器是基于Ubuntu的，位于同一个数据中心。所有其他的东西都可以适应解决scheme的要求。

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

这是您正在寻找的解决scheme。没有java参与制作这个系统，只是随时可用的开放源代码位。这里介绍的模型可以与其他技术一起使用，而不是我正在使用的技术。

可扩展上传

文件被HTTP发送到特定的循环DNS地址。
系统发布文件然后通过另一对负载均衡器将作业放入AMQP系统（此处为Rabbit MQ）以启动处理工作stream程。
接收HTTP POST的负载均衡器分别位于一组OpenStack Swift对象存储服务器的前面。
- 每个负载均衡器都有两个或多个OpenStack Swift对象存储服务器。
- 如果目标是HA本身，“循环不是HA”就可以。因人而异。
- 为了获得额外的耐用性，RRDNS中的IP可以是单独的热备份LB集群。
实际获得POST的Object Store服务器将该文件传送到基于Gluster的文件系统。
- Gluster系统应该是分布式的（又名分片）和复制。这使其可以扩展到愚蠢的密度。
AMQP系统将第一个作业分配给一个可用的处理节点。
处理节点将文件从主存储器复制到备份存储器，并根据需要报告成功/失败。
- 故障模式处理在此处未示出。基本上，继续尝试，直到它的工作。如果它从来没有工作，通过一个例外的过程。
一旦备份完成，AMQP会将处理作业分派到可用的处理节点。
处理节点将文件拉到本地文件系统或直接从Gluster处理它。
处理节点将处理产品存放在任何地方，并将成功报告给AMQP。

这个设置应该能够以极高的速度吞服足够的服务器文件。获得10GbE聚合摄取速度应该是可行的，如果你足够的升迁。当然，处理这么多数据的速度将会在您的Processing机器级上需要更多的服务器。这个设置应该扩展到1000个节点，甚至可能超过（尽pipe多远取决于你正在做什么，所有这一切）。

AMQP过程中隐藏的工作stream程pipe理stream程面临着深刻的工程挑战。这就是所有的软件，可能是根据您的系统需求定制的。但应该充分利用数据！

鉴于你已经阐明了文件将通过scp到达，我没有看到任何前端服务器存在的原因，因为传输机制是可以在第3层redirect的东西。

我会在前面放置一个LVS导向器（配对），后面有一个处理服务器池和一个循环redirect策略。这样可以很容易地将服务器join到池中或者从池中减去服务器，这增加了可靠性，因为没有前端服务器可以倒下，这意味着我们不必处理从文件中获取文件的拉/推问题处理服务器的前端，因为没有前端。

每个池服务器在接收文件时都应该做两件事情 – 一是将其复制到档案存储器，然后处理文件并发送。