使用队列或 REST Web 服务协调分布式 Python 进程

Question

服务器 A 有一个将 n 个数据库表导出为平面文件的进程。 服务器 B 包含将平面文件加载到 DW 设备数据库中的实用程序。

一个进程在服务器 A 上运行，它导出和压缩大约 50-75 个表。每次导出一个表并生成一个文件时，也会生成一个 .flag 文件。

服务器 B 有一个 bash 进程，它重复检查服务器 A 生成的每个 .flag 文件。它通过连接到 A 并检查文件是否存在来做到这一点。如果标志文件存在，服务器 B 将从服务器 A scp 文件，解压缩，并将其加载到分析数据库中。如果该文件尚不存在，它将休眠 n 秒并重试。对服务器 B 期望在服务器 A 上找到的每个表/文件重复此过程。该过程串行执行，一次处理一个文件。

另外：在服务器 A 上运行的进程无法将文件“推送”到服务器 B。由于文件大小和地理问题，服务器 A 无法将平面文件加载到 DW 设备中。

我发现这个过程很麻烦，并且恰好需要重写/改造。我提出了一个基于消息传递的解决方案。我最初认为这将是 RabbitMQ（或类似）的一个很好的候选者

• 服务器 A 会写入一个文件，对其进行压缩，然后为队列生成一条消息。

• 服务器 B 将订阅队列并处理消息正文中指定的文件。

我觉得基于消息传递的方法不仅可以节省时间，因为它可以消除每个表的检查-等待-重复循环，而且还允许我们并行运行进程（因为没有依赖关系）。

我向我的团队展示了使用 RabbitMQ 的概念验证，他们都接受使用消息传递。他们中的一些人很快发现了我们可以从基于消息的处理中受益的其他机会。我们将从实现消息传递中受益的一个领域是实时填充我们的 DW 维度，而不是通过批处理。

然后我突然想到，考虑到低容量（50-75 个任务），基于 MQ 的解决方案可能会过大。考虑到我们的运营团队必须安装 RabbitMQ（及其依赖项，包括 Erlang），这可能有点过头了，而且还会带来新的管理难题。

然后我意识到这可以通过基于 REST 的解决方案变得更简单。服务器 A 可以生成一个文件，然后对服务器 B 上的简单 (web.py) Web 服务进行 HTTP 调用。然后，服务器 B 可以根据调用的 URL 启动传输和加载过程。考虑到传输、解压缩和加载每个文件所需的时间，我可能会使用 Python 的多处理来创建一个加载每个文件的子进程。

我认为基于 REST 的解决方案是一个想法，因为它更简单。在我看来，使用 MQ 更适合处理大量任务，但我们（目前）只谈论 50-75 次操作，未来可能还会更多。

考虑到我的要求和数量，基于 REST 的解决方案会是一个好的解决方案吗？是否有其他框架或 OSS 产品已经这样做了？我希望在不造成其他管理和开发难题的情况下添加消息传递。

Answer 1

Rabbit 等消息代理包含许多问题的实用解决方案：

• 支持多个生产者和消费者，没有重复消息的风险
• 原子性和工作单元逻辑提供事务完整性，防止发生故障时重复和丢失消息
• 横向扩展——大多数成熟的代理都可以集群，这样一个队列就存在于多台机器上
• 无集合消息传递 - 发送方和接收方不必同时运行，因此可以关闭其中一个进行维护而不会影响另一个
• 保持先进先出顺序

根据您正在考虑的特定 Web 服务平台，您可能会发现您需要其中一些功能，并且如果不使用代理，则必须自己实现它们。 HTTP、SOAP、JSON 等 Web 服务协议和格式并不能为您解决这些问题。

在我之前的工作中，项目管理很早就使用消息代理，但后来团队最终实现了快速而肮脏的逻辑，旨在解决我们的 Web 服务架构中与上述相同的一些问题。我们没有多少时间来提供业务价值，因为我们要解决很多并发和错误恢复问题。

因此，虽然消息代理表面上看起来像是一个重量级的解决方案，并且实际上可能超出了您现在的需要，但它确实有很多好处，您以后可能会在没有意识到的情况下需要它。

Answer 2

正如 wberry 所暗示的，基于 REST 或 web-hook 的解决方案可以正常工作，但不会非常容忍失败。为消息传递预先支付运营成本将带来长期收益，因为您会发现其他问题自然适合消息传递模型。

关于其他 OSS 选项；如果您正在考虑除此特定用例之外的基于流的处理，我建议您查看Apache Kafka。 Kafka 提供了与 RabbitMQ 类似的消息传递语义，但更专注于处理消息流（更不用说它已经在 LinkedIn 的生产环境中进行了实战测试）。