带有Queue和ZeroMQ IPC的Python多处理


10

我正在忙着使用ZeroMQ编写Python应用程序,并实现ZGuide中描述的Majordomo模式的变体。

我有一个经纪人,作为一组工人和客户之间的中介。我想对传入的每个请求进行大量日志记录,但是我不希望经纪人浪费时间这样做。代理应将该日志记录请求传递给其他对象。

我想到了两种方法:

  1. 创建仅用于日志记录的工作程序并使用ZeroMQ IPC传输
  2. 与队列一起使用多处理

我不确定哪一个更好或更快速。第一个选项确实允许我使用我已经用于普通工作程序的当前工作程序基类,但是第二个选项似乎可以更快地实现。

我想就以上内容或其他解决方案提出建议或意见。

Answers:


4

我喜欢使用Jonathan提出的标准工具的方法。您没有提到要在哪个OS上进行工作,但是遵循相同精神的另一种选择可能是与Python的标准日志记录模块一起使用logging.handlers.SysLogHandler,并将日志记录消息发送到rsyslog服务(可在任何linux / unix上使用,但我认为还有一个Windows选项,但我从未使用过该选项)。

本质上,整个系统实现了您正在考虑的同一件事。您的本地进程将日志消息排队,由其他人处理/处理/编写。在这种情况下,别人(rsyslog)是一项众所周知的成熟服务,它具有许多内置功能和灵活性。

这种方法的另一个优点是您的产品将与基于syslog的其他sysadmin工具更好地集成。而且它甚至不需要您编写任何代码即可获得该选项。


1
+1是避免重复发明轮子的建议。我不介意继承以此方式设计的系统。它可以很好地完成工作,但为将来的修改提供了许多自由度。
evadeflow 2013年

2

您可能要考虑实现远程日志记录的第三种可能性。如果使用标准的Python日志记录模块,则可以考虑logging.QueueHandler在worker,客户端和代理中使用该类,并logging.QueueListener在远程日志记录过程中使用该类。

与其使用普通的Python multiprocessing.Queue作为应用程序进程和日志记录进程之间的传输方式,不如Queue使用ZeroMQ和鸭子类型来实现自己的替换类,以使您的类成为标准Python的直接替代品Queue。这样,您的应用程序将能够从一台多核计算机到分布式数据中心,在任何环境中保持不变。

总而言之,将标准Python记录器与QueueHandler您的所有工作人员,客户和经纪人一起使用,并基于QueueListenerlogging您选择的Python 处理程序创建一个独立的进程来处理繁重的记录。


我正在使用Python 2.7。我相信QueueHandler类仅可用于Python 3.2。
伊姆拉恩

从Python 3中提取代码并将其直接用作应用程序的一部分非常容易。
乔纳森

我会尽力的,让您知道它是否有效
Imraan

0

这些是截然不同的方法,每种方法各有优缺点,您很可能会在以后的开发阶段看到这些方法:

我想到了两种方法:

  1. 创建仅用于日志记录的工作程序并使用ZeroMQ IPC传输
  2. 与队列一起使用多处理

您可以尝试的一种方法是,像方法1一样,有一个额外的日志记录工作程序。您可以让您的工作程序登录到Memcache日志记录群集,并且日志记录工作程序监视当前资源负载,并在超过给定的资源负载参数时监视该资源负载。工人登录到IOPs受限设备(例如硬盘)。

我也喜欢乔纳森(Jonathan)的方法,我只使用了Python 2.x,但您可能必须设置自己的日志记录后端才能真正提高性能。

如果我错了,请纠正我,但是我的看法是您正在执行一些真正的数据密集型任务,而存储IOP是您的瓶颈。

一种方便的方法仍然是让代理brokerage以所描述的形式进行日志记录,同时具有中央代理实例的所有缺点。例如,如果代理人的需求如此之高,以至于它再也没有喘息的机会将内存缓存的日志写回到存储中,那么您就需要采取另一种方法。

您最终可能最终会获得无经纪人模型。那就是工人在自己之间管理工作。在一个简单的示例中,通过分布式轮询算法。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.