Python: OpenMPI vs. RabbitMQ

Question

Supongamos que a uno le interesa escribir una aplicación python donde debe haber comunicación entre los diferentes procesos. Las comunicaciones se realizarán enviando strings y/o numpy arrays.

¿Cuáles son las consideraciones para preferir OpenMPI frente a una herramienta como RabbitMQ?

Answer 1

No hay una sola respuesta correcta a dicha pregunta. Todo depende de una gran cantidad de factores diferentes. Por ejemplo:

1. ¿Qué tipo de comunicaciones tiene? ¿Está enviando paquetes grandes o pequeños, necesita un buen ancho de banda o baja latencia?
2. ¿Qué tipo de garantías de entrega necesita?
3. OpenMPI puede entregar mensajes instantáneamente solo a un proceso en ejecución, mientras que diferentes soluciones MQ pueden poner mensajes en cola y permitir configuraciones de productor-consumidor sofisticadas.
4. ¿Qué tipo de red tienes? Si está ejecutando en el host local, algo como ZeroMQ probablemente sea el más rápido. Si está ejecutando en el conjunto de hosts, depende de las interconexiones disponibles. P.ej. OpenMPI puede utilizar enlaces infiniband/mirynet.
5. ¿Qué tipo de procesamiento estás haciendo? Con MPI, todos los procesos se inician al mismo tiempo, se procesa y finaliza todo al mismo tiempo.

Answer 2

Este es exactamente el escenario en el que estuve hace unos meses y decidí usar AMQP con RabbitMQ usando intercambios de temas, además de Memcache para objetos grandes.

Los mensajes AMQP son todas cadenas de caracteres, en formato de objeto JSON para que sea fácil agregar atributos a un mensaje (como el número de reintentos) y volver a publicarlo. Los objetos JSON son un subconjunto de JSON que corresponde a los dictados de Python. Por ejemplo, {"recordid": "272727"} es un objeto JSON con un atributo. Podría haber escaqueado un dict de Python, pero eso nos habría bloqueado para usar Python con las colas de mensajes.

Los objetos grandes no son enrutados por AMQP, sino que entran en un Memcache en el que están disponibles para que otro proceso los recupere. Podrías usar Redis o Tokyo Tyrant para este trabajo. La idea es que no queríamos que los mensajes cortos se pusieran en cola detrás de objetos grandes.

Al final, mis procesos de Python terminaron usando AMQP y ZeroMQ para dos aspectos diferentes de la arquitectura. Puede encontrar que tiene sentido usar OpenMPI y AMQP pero para diferentes tipos de trabajos.

En mi caso, un proceso de supervisor se ejecuta para siempre, inicia una bandada completa de trabajadores que también se ejecuta para siempre a menos que mueran o se cuelguen, en cuyo caso el supervisor los reinicia. El trabajo fluye constantemente como mensajes a través de AMQP, y cada proceso maneja solo un paso del trabajo, de modo que cuando identificamos un cuello de botella podemos tener múltiples instancias del proceso, posiblemente en máquinas separadas, para eliminar el cuello de botella. En mi caso, tengo 15 instancias de un proceso, 4 de otras dos y alrededor de otras 8 instancias individuales.