¿Por qué usar AMQP / ZeroMQ / RabbitMQ?

Question

en lugar de escribir su propia biblioteca.

Estamos trabajando en un proyecto aquí que será un grupo de servidores de división automática, si una sección se vuelve demasiado pesada, el gerente la dividiría y la colocaría en otra máquina como un proceso separado. También alertaría a todos los clientes conectados que esto afecta para conectarse al nuevo servidor.

Tengo curiosidad por usar ZeroMQ para la comunicación entre servidores y entre procesos. Mi compañero preferiría rodar el suyo. Estoy esperando que la comunidad responda esta pregunta.

Soy un programador bastante novato y acabo de aprender sobre las colas de mensajería. Como busqué en Google y leí, parece que todos están usando colas de mensajes para todo tipo de cosas, pero ¿por qué? ¿Qué los hace mejores que escribir tu propia biblioteca? ¿Por qué son tan comunes y por qué hay tantos?

Answer 1

  

¿Qué los hace mejores que escribir su propia biblioteca?

Al implementar la primera versión de su aplicación, probablemente nada: sus necesidades están bien definidas y desarrollará un sistema de mensajería que se adaptará a sus necesidades: pequeña lista de funciones, pequeño código fuente, etc.

Esas herramientas son muy útiles después de la primera versión, cuando realmente tiene que extender su aplicación y agregarle más funciones. Déjame darte algunos casos de uso:

• su aplicación tendrá que hablar con una máquina endian grande (sparc / powerpc) desde una pequeña máquina endian (x86, intel / amd). Su sistema de mensajería tenía una suposición de pedido endian: vaya y corríjala
• diseñó su aplicación para que no sea un protocolo binario / sistema de mensajería y ahora es muy lenta porque pasa la mayor parte de su tiempo analizándola (el número de mensajes aumentó y el análisis se convirtió en un cuello de botella): adáptelo para que pueda transporte binario / codificación fija

• al principio tenías 3 máquinas dentro de un lan, sin demoras notables, todo llega a cada máquina. su cliente / jefe / jefe-diablo-de pelo puntiagudo aparece y le dice que instalará la aplicación en WAN que no administra, y luego comienza a tener fallas de conexión, mala latencia, etc., necesita almacenar el mensaje y volver a intentar el envío más adelante: regrese al código y conecte estas cosas (y disfrute)

Los mensajes

• enviados deben tener respuestas, pero no todas: envía algunos parámetros y espera una hoja de cálculo como resultado en lugar de enviar y confirmar, vuelva al código y conecte estas cosas (y disfrute .)

• algunos mensajes son críticos y su recepción / envío necesita una copia de seguridad / persistencia / adecuada. Porque preguntas ? fines de auditoría

Y muchos otros casos de uso que olvidé ...

Puede implementarlo usted mismo, pero no pase mucho tiempo haciéndolo: probablemente lo reemplazará más adelante de todos modos.

Answer 2

Eso es muy parecido a preguntar: ¿por qué usar una base de datos cuando puedes escribir la tuya?

La respuesta es que el uso de una herramienta que ha existido por un tiempo y que se entiende bien en muchos casos de uso diferentes, vale la pena cada vez más a medida que evolucionan sus requisitos. Esto es especialmente cierto si más de un desarrollador está involucrado en un proyecto. ¿Desea convertirse en personal de soporte para un sistema de colas si cambia a un nuevo proyecto? Usar una herramienta evita que eso suceda. Se convierte en el problema de otra persona.

Caso en cuestión: persistencia. Escribir una herramienta para almacenar un mensaje en el disco es fácil. Escribir un persistor que escala y funciona bien y de manera estable, en muchos casos de uso diferentes, y es manejable y económico de soportar, es difícil. Si quieres ver a alguien quejarse de lo difícil que es, mira esto: http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange

De todos modos, espero que esto ayude. Por supuesto, escribe tu propia herramienta. Muchas, muchas personas lo han hecho. Lo que resuelva su problema, es bueno.

Answer 3

Estoy considerando usar ZeroMQ yo mismo, por lo tanto me topé con esta pregunta.

Supongamos por el momento que tiene la capacidad de implementar un sistema de colas de mensajes que cumpla con todos sus requisitos. ¿Por qué adoptaría ZeroMQ (u otra biblioteca de terceros) sobre el enfoque roll-your-own? Simple - costo.

Supongamos por un momento que ZeroMQ ya cumple con todos sus requisitos. Todo lo que debe hacerse es integrarlo en su compilación, leer algunos documentos y luego comenzar a usarlo. Eso tiene que ser mucho menos esfuerzo que rodar el tuyo. Además, la carga de mantenimiento se ha trasladado a otra empresa. Dado que ZeroMQ es gratuito, es como si acabaras de hacer crecer tu equipo de desarrollo para incluir (parte del) equipo de ZeroMQ.

Si dirigía un negocio de desarrollo de software, creo que equilibraría el costo / riesgo de usar bibliotecas de terceros con la creación de su propia cuenta y, en este caso, usar ZeroMQ ganaría sin dudas.

Quizás usted (o más bien, su pareja) sufra, como lo hacen muchos desarrolladores, de " Not ¿Inventado aquí " síndrome? Si es así, ajuste su actitud y vuelva a evaluar el uso de ZeroMQ. Personalmente, prefiero los beneficios de la actitud Proudly Found Othersewhere. Espero poder estar orgulloso de encontrar ZeroMQ ... el tiempo lo dirá.

EDITAR: Encontré esto video de los desarrolladores de ZeroMQ que habla sobre por qué debe usar ZeroMQ.

Answer 4

  

¿Qué los hace mejores que escribir su propia biblioteca?

Los sistemas de colas de mensajes son transaccionales, lo que es conceptualmente fácil de usar como cliente, pero difícil de implementar como implementador, especialmente teniendo en cuenta las colas persistentes. Puede pensar que puede salirse con la suya escribiendo una biblioteca de mensajería rápida, pero sin transacciones y persistencia, no tendría todos los beneficios de un sistema de mensajería.

La persistencia en este contexto significa que el middleware de mensajería mantiene los mensajes no manejados en almacenamiento permanente (en el disco) en caso de que el servidor se caiga; después de un reinicio, los mensajes pueden manejarse y no es necesario retransmitirlos (el remitente ni siquiera sabe que hubo un problema). Transaccional significa que puede leer mensajes de diferentes colas y escribir mensajes en diferentes colas de manera transaccional, lo que significa que todas las lecturas y escrituras tienen éxito o (si una o más fallan) ninguna tiene éxito. Esto no es muy diferente de la transaccionalidad conocida de la interfaz con las bases de datos y tiene los mismos beneficios (simplifica el manejo de errores; sin transacciones, tendría que asegurarse de que cada lectura / escritura individual tenga éxito, y si una o más fallan, tiene para revertir los cambios que tuvieron éxito).

Answer 5

Antes de escribir su propia biblioteca, lea la Guía 0MQ aquí: http://zguide.zeromq.org/ página: todos

Lo más probable es que decidas instalar RabbitMQ, o de lo contrario harás tu biblioteca sobre ZeroMQ ya que ya han hecho todas las partes difíciles.

Answer 6

Si tienes un poco de tiempo, pruébalo y despliega tu propia implementación. Los aprendizajes de este ejercicio lo convencerán sobre la sabiduría de usar una biblioteca ya probada.