问multiprocessing.Queue的高性能替换

EN

我认为这在很大程度上取决于你对个人信息的重视程度。

如果每一个都是至关重要的，并且您必须考虑在某个地方发生故障时它们会发生什么，那么像RabbitMQ这样的框架可能是有用的。RabbitMQ有一个代理，可以将其配置为某种高可用性、高可靠性的模式。有了正确的队列设置，RabbitMQ将照看您的消息，直到系统的某些部分使用它们为止。

要做到这一点，RabbitMQ需要一个代理。这使得它相当慢。尽管曾经讨论过在ZeroMQ的底层协议(zmtp)之上重新实现RabbitMQ并取消代理，而是在端点中实现所有功能。

相反，ZeroMQ在确保在发生故障时，您的消息最终会到达预期的目的地方面做得更少。如果进程死亡，或者网络连接失败，那么消息丢失的可能性很大。可以设置更新的版本来主动监视连接，以便如果网络电缆中断或某个进程在某个地方死亡，则可以非常迅速地通知套接字另一端的端点。如果您随后在ZMQ的参与者框架(例如:消息确认等)之上实现了一个通信顺序流程框架，那么您最终可能会得到一个系统，在这个系统中，端点可以确定消息已经传输到预定的目的地。

因为没有经纪人，zmq可以非常快。它在从inproc到tcp的许多不同传输中都是有效的，所有这些都可以混合在一起。如果您不担心进程崩溃或网络连接失败，ZMQ将为您提供立即传递消息的保证。

因此，确定应用程序中最重要的是什么可以帮助您选择要使用的技术-- RabbitMQ、ZeroMQ等等。一旦您决定了这一点，那么“如何获得我所需要的模式”的问题就变成了“该技术支持什么模式”。RabbitMQ是，AFAIK，纯粹的pub/sub (每个都可以有很多)，而ZeroMQ有更多。

在尝试了一些可用的实现和框架之后，我仍然找不到适合我的任务的任何东西。不是太慢就是太重。

为了解决这个问题，我和我的同事开发了以下内容：https://github.com/alex-petrenko/faster-fifo

更快-fifo是Python的multiprocessing.Queue的替代物，而且速度要快得多。事实上，在我所关心的配置中，它的速度快了30倍(很多生产者，很少有消费者)，因为它在消费者端还支持get_many()方法。

它是无代理的，轻量级的，支持任意的多到多配置，为Posix系统实现了使用p线程同步原语。

为了取代Python标准的多处理队列，我尝试了Redis队列。这是不适合雷迪斯的！Python是最好的，最快的，并且可以接受你抛出的任何类型的数据类型，在这里使用Redis和复杂的数据类型，比如dict和大量的numpy数组等等。您必须挑选或json转储/负载，这会增加进程的开销。

干杯，史蒂夫