python - 使用队列或 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 个操作， future 可能还会有更多操作。

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

Answer 1

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

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

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

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

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