事件驱动处理架构建议

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 和 c）。仅供参考，我将使用 socket.io 通过网络在步骤 a 和 d 上与用户交流。

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

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

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

Answer 1

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

所以当文件请求进来的时候，如果web服务器之前已经从redis那里听说过文件已经加载了，就可以拿到文件并返回，否则会通知后端处理文件，并等待来自a的通知redis 频道