tutorial rabbit parallel exchange español python django twisted rabbitmq

parallel - rabbitmq python



¿Por qué tenemos que usar rabbitmq (7)

Déjame contarte algunas razones que hacen que el uso de MOM (Middleware orientado a mensajes) sea probablemente la mejor opción.

Desacoplamiento:

Puede desacoplar / separar los componentes principales de la aplicación. No es necesario traer aquí todos los beneficios de la arquitectura desacoplada. Solo quiero señalar que este es uno de los principales requisitos para escribir un software de calidad y fácil de mantener.

Flexibilidad:

En realidad, es muy fácil conectar dos aplicaciones totalmente diferentes escritas en diferentes idiomas juntas mediante el uso del protocolo AMQP. Esta aplicación se comunicará entre sí con la ayuda de un "traductor" que es MOM.

Escalabilidad:

Al usar MOM, podemos escalar el sistema horizontalmente. Un productor de mensajes puede transmitir a un número ilimitado de consumidores de mensajes una tarea, un comando o un mensaje para procesar y escalar este sistema. Todo lo que tenemos que hacer es crear nuevos consumidores de mensajes. Digamos que estamos obteniendo 1000 imágenes por segundo y debemos redimensionarlas. Resolver este problema con los métodos tradicionales podría ser un dolor de cabeza. Con MOM podemos transmitir imágenes a los consumidores de mensajes que pueden hacer su trabajo de forma asincrónica y asegurar que la integridad de los datos esté intacta.

Son otros beneficios de usar MOM también, pero estos 3 son los más significativos en mi opinión.

¿Por qué necesitamos RabbitMQ cuando tenemos un framework de red más potente en Python llamado Twisted? Estoy tratando de entender la razón por la cual alguien querría usar RabbitMQ.

¿Podría proporcionarnos un escenario o un ejemplo usando RabbitMQ?

Además, ¿dónde puedo encontrar un tutorial sobre cómo usar RabbitMQ?

Los sistemas MQ tienden a funcionar mejor en escenarios de "disparar y olvidar". Si ocurre un evento y otros necesitan ser notificados, pero el sistema de origen no necesita retroalimentación de los otros sistemas, entonces MQ podría ser una buena opción.

Si comprende los pros y los contras de MQ y todavía no entiende por qué sería una buena opción para un sistema en particular, entonces probablemente no lo sea. He visto sistemas en los que se usaba MQ pero no era necesario, y el resultado no era bonito.

Uno de los usos clave del middleware, como las colas de mensajes, es poder enviar datos entre sistemas no homogéneos. Los mensajes en sí pueden ser muchas cosas. Las cadenas son las más fáciles de entender por diferentes idiomas en diferentes sistemas, pero a menudo son menos útiles para transferir datos más significativos. Como resultado, JSON y XML son muy populares para los mensajes. Estas son solo cadenas estructuradas que se pueden convertir en objetos en el idioma de elección en el extremo consumidor.

Funciones útiles adicionales :

  • En algunos sistemas MQ como RabbitMQ (no es cierto en todos los sistemas MQ), el cliente maneja muy bien el aspecto de la comunicación.
  • Los mensajes pueden ser asincrónicos. Si el consumidor baja, los mensajes permanecerán hasta que el consumidor vuelva a estar en línea.
  • El sistema MQ se puede configurar en grados variables de durabilidad del mensaje. Se pueden eliminar de la cola una vez que se leen o permanecen hasta que se reconocen. Pueden ser persistentes, por lo que incluso si los sistemas MQ se apagan, el mensaje no se perderá.

Aquí van algunos ejemplos posiblemente artificiales. Un programa Java en un sistema local desea enviar un mensaje a un sistema conectado a través de Internet. El sistema local tiene un servidor conectado a internet. Todo está bloqueado desde Internet, excepto una conexión con el MQ. El programa Java puede publicar el mensaje en el MQ sin necesidad de acceder a Internet. El mensaje se encuentra en la cola hasta que el sistema externo lo recoge. El programa Java publica un mensaje, digamos XML, y el consumidor podría ser un programa Perl. Siempre que tengan alguna forma de entender el XML con una forma predefinida de serialización y deserialización, estará bien.

Básicamente, los programas estrechamente relacionados son buenos si el programa es muy simple o si hay alguna razón especializada para usar un programa estrechamente acoplado.

En el mundo real, las cosas son mucho más complejas. Los programas no pueden ser tan simples, y se convierte en una pesadilla desarrollar aplicaciones empresariales de una manera estrechamente acoplada. Por lo tanto, usamos el término "débilmente acoplado" para definir sistemas grandes que se componen de muchas piezas más pequeñas. Las piezas tienen límites y funciones muy definidos, por lo que el cambio del sistema se puede realizar más fácilmente. Es la esencia del diseño orientado a objetos. Las colas de mensajes (como RabbitMQ) permiten que se produzca una comunicación similar a la del correo electrónico entre varios programas y partes de programas, lo que hace que el flujo de trabajo sea mucho más parecido al de las personas. Agregar capacidad extra se convierte en una simple cuestión de iniciar y computadora adicional donde sea que la necesite.

JMS (ActiveMQ es una implementación de intermediario JMS) se puede usar como un mecanismo para permitir el procesamiento asíncrono de solicitudes. Es posible que desee hacer esto porque la solicitud tarda mucho tiempo en completarse o porque varias partes pueden estar interesadas en la solicitud real. Otra razón para usarlo es permitir que múltiples clientes (potencialmente escritos en diferentes idiomas) accedan a la información a través de JMS. ActiveMQ es un buen ejemplo aquí porque puede usar el protocolo STOMP para permitir el acceso desde un cliente C # / Java / Ruby.

Uso en el mundo real de JMS / colas de mensajes :

Un ejemplo del mundo real es el de una aplicación web que se utiliza para realizar un pedido para un cliente en particular. Como parte de colocar ese orden (y almacenarlo en una base de datos) es posible que desee llevar a cabo una serie de tareas adicionales:

  • Almacene el pedido en algún tipo de sistema de back-end de terceros (como SAP)
  • Envía un correo electrónico al cliente para informarle que su pedido ha sido enviado

Para hacer esto, su código de aplicación publicaría un mensaje en una cola JMS que incluye una identificación de pedido. Una parte de su aplicación que escucha la cola puede responder al evento tomando el ID de pedido, mirando el pedido en la base de datos y luego haciendo el pedido con otro sistema de terceros. Otra parte de su aplicación puede ser responsable de tomar el ID de pedido y enviar un correo electrónico de confirmación al cliente.

RabbitMQ es una implementación de AMQP , que define un protocolo interoperable para middleware orientado a mensajes. Como tal, define la semántica para la creación, publicación, enrutamiento y consumo de mensajes que pueden implementarse en cualquier plataforma.

Conceptualmente, podría considerarse una especialización de un motor de red como Twisted, pero basado en un estándar aceptado por la industria.

Aquí hay un blog de Ross Mason que discute el interés de publicación-suscripción interoperable con AMQP: http://blogs.mulesoft.org/inter-operable-publishsubscribe-with-amqp/

Twisted es una biblioteca de red que implementa una serie de protocolos de red y le permite crear la suya propia. Uno de los protocolos que puede usar con Twisted es AMQP https://launchpad.net/txamqp

RabbitMQ es un intermediario AMQP, es decir, un servicio que se ejecuta fuera de su aplicación, probablemente en un clúster separado de servidores. AMQP es simplemente el protocolo que se utiliza para comunicarse con un intermediario de colas de mensajes como RabbitMQ. Obtienes muchas cosas de RabbitMQ. Puede enviar mensajes persistentemente con entrega garantizada para que lleguen incluso si su aplicación falla, e incluso si el broker RabbitMQ termina siendo reiniciado. Obtiene el equilibrio de carga entre los consumidores de mensajes si tiene varios consumidores en la misma fila. Obtiene interoperabilidad con aplicaciones en otros idiomas siempre que use un formato de serialización razonablemente abierto para los cuerpos de sus mensajes. AMQP le permite dividir una aplicación monolítica en muchas partes poco compactas que pueden ejecutarse en diferentes servidores. Esta es una gran victoria para el mantenimiento a largo plazo de una aplicación.

Twisted no es una implementación de cola. Además de eso, RabbitMQ ofrece características de cola de nivel empresarial e implementa el protocolo AMQP que a menudo se necesita en un mundo empresarial.

rabbitmq es un poco más que un mero mensaje ... es una plataforma común que tiene la capacidad de interconectar aplicaciones. Usando rabbitmq, una aplicación java puede hablar con un servidor Linux y / o una aplicación .net, con ruby ​​& rails + casi cualquier cosa que encuentre su lugar en el desarrollo web corporativo. Y lo más importante, implementa el modelo "disparar y olvidar" propuesto por AMQP. Es simplemente un reemplazo perfecto para JMS o ESB ... especialmente si se trata de una arquitectura multiplataforma, con una garantía de confiabilidad. Incluso hay una característica especial llamada RPC (Llamada a procedimiento remoto) que se suma a la facilidad de desarrollo en el arco distribuido.

Además de todo esto, en el mundo los servicios financieros, como el mercado bursátil o de acciones, donde se requiere una gran cantidad de enrutamiento confiable y eficiente (supongamos que no conoce el número real de personas suscritas a sus servicios, pero quiere asegurarse de que quien lo haga por lo tanto, recibe sus pings, ya sea que estén conectados en este momento, o se conectarán más tarde), las reglas de rabbitmq porque están basadas en ERLANG y la plataforma Open-telecom que asegura un alto rendimiento al usar recursos mínimos. Para ver la introducción más conveniente a rabbitmq, consulte rabbitmq.com/getstarted.html para su idioma de desarrollo nativo.