事件驱动的处理架构建议

Question

我目前正在开发一个需要实时执行文件处理的项目。这是我正在努力实现的工作流程

a. User requests a file to be processed to Server A (web)
b. Server A forwards the request to Server B
c. Server B finishes and signals Server A that it’s done
d. Server A signals the user that the file is ready (web)

我在寻找什么？我需要找到一种简单的事件驱动方式来在服务器A和服务器之间进行通信。服务器B（即步骤b＆amp; c）。仅供参考我将使用socket.io与用户通过步骤a＆amp; d通过网络。

我将使用的环境是运行node.js服务的Ubuntu 14.04服务器（请注意，只要有接口，解决方案就不必是严格的节点。）

看起来很简单？这就是复杂的地方。每组服务器（现在将它们视为Web服务器与处理服务器）将在云中复制（每个服务器中都有很多）。需要注意的是，当处理服务器完成处理文件时，它必须向所有 Web服务器发出信号，表明该文件已准备就绪。为什么？每个Web服务器可能已经为正在等待同一文件的请求提供服务。

我需要一个解决方案，以尽可能最快的时间（即事件驱动而不是轮询）与node.js接口并在Ubuntu上运行来实现此工作流程。有什么想法吗？

Answer 1

让您的生活更轻松的一种方法可能是使用redis进行与Web服务器的通信，以了解文件何时加载并准备就绪。 Redis内置了频道订阅/消息，并且很容易与node.js一起使用

因此，当文件请求进入时，如果Web服务器先前已从redis中听到该文件已加载，则它可以获取该文件并将其返回，否则发信号通知后端处理该文件，并等待来自redis频道