rabbitmq - palas - paletas para natacion speedo
¿Cuándo usar las palas RabbitMQ y cuándo el complemento de Federation? (2)
Para la empresa para la que trabajo, nos gustaría utilizar RabbitMQ como nuestro principal bus de mensajes. La idea que tenemos es que cada aplicación utiliza su propio vhost para la comunicación interna y que a través del plugin de pala o federación permitiríamos compartir cierto tipo de eventos en múltiples fantasmas (quizás incluso varias máquinas (no agrupadas)) . Elegimos para la aplicación por vhost separar la comunicación interna de los eventos públicos y mantener la seguridad ajustable por aplicación.
Según la información publicada en el sitio web de RabbitMQ , no la recibo cuando tengo que elegir palas o cuando tengo que elegir el complemento de federación.
RabbitMQ tiene la siguiente explanation cuándo usar qué:
Normalmente, usaría la pala para vincular corredores a través de Internet cuando necesita más control del que proporciona la federación.
¿Cuál es el control de grano fino en las palas que me falta cuando elijo para la federación?
En este momento, creo que preferiría el complemento de federación porque podría automatizar la comunicación entre servidores a través de la API REST proporcionada por el complemento de federación. En el caso de las palas, necesitaría cambiar la configuración de la pala y reiniciar la instancia de RabbitMQ cada vez que quisiéramos compartir un evento entre fantasmas. ¿Son mis pensamientos correctos acerca de esto?
Actualmente estamos ejecutando RMQ en Windows con clientes que se conectan desde .NET. Próximamente se unirán los clientes de Java / Perl / PHP.
Para resumir mis preguntas:
- ¿Cuál es el control de grano fino en palas que me extraño cuando
elegir para la federación? - ¿Es correcto que la única forma de cambiar la comunicación entre servidores cuando uso palas es cambiando el archivo configurado y reiniciando la instancia?
- ¿La configuración (vhost por aplicación) tiene sentido o me falta el punto por completo?
Las palas y la cola proporcionan diferentes medios para enviar mensajes desde un nodo RabbitMQ a otro.
Intercambio federado
Con un intercambio federado, las colas se pueden conectar a la cola en el nodo de origen (origen). Además, un intercambio en el nodo descendente (destino) recibirá una copia de los mensajes que se publican en el nodo ascendente.
Los intercambios federados son similares a los enlaces de intercambio por intercambio, ya que pueden (opcionalmente) suscribirse a un conjunto limitado de mensajes de un intercambio ascendente.
Cola federada (NOTA: estos son nuevos en RabbitMQ 3.2.x)
Con una cola federada, los consumidores pueden conectarse a la cola tanto en los nodos ascendente (origen) como descendente (destino).
Básicamente, la cola en sentido descendente es un consumidor en la cola ascendente, con la expectativa de que haya consumidores adicionales en sentido descendente que procesen los mensajes de la misma manera que un consumidor vinculado a la cola ascendente.
Cualquier mensaje consumido por la cola en sentido descendente (federado) no estará disponible para los consumidores en la cola ascendente.
Caso de uso:
Si los consumidores se migran de un nodo a otro, una cola federada permitirá que esto suceda sin que se pierdan mensajes o que se procesen dos veces.
Caso de uso: de los documentos de RabbitMQ
El uso típico sería tener la misma cola "lógica" distribuida entre muchos intermediarios. Cada intermediario declarará una cola federada con todas las demás colas federadas en sentido ascendente. (Los enlaces formarían un gráfico bidireccional completo en n colas).
Pala
Las palas, por otro lado, conectan una cola "aguas arriba" a un intercambio "aguas abajo". (Pongo los términos entre comillas porque la documentación de la pala no describe los nodos con la misma semántica que la documentación de la federación).
La pala consume los mensajes de la cola y los envía al intercambio en el nodo de destino. (NOTA: aunque normalmente no se discute como parte de este patrón, no hay nada que impida que un consumidor se conecte a la cola en el nodo de origen).
Para responder las preguntas específicas:
¿Cuál es el control de grano fino en las palas que me falta cuando elijo para la federación?
Una pala no tiene que residir en un nodo "aguas arriba" o "aguas abajo". Se puede configurar y operar desde un nodo independiente.
Una pala puede crear todos los elementos del enlace por sí mismo: la cola de origen, los enlaces de la cola y el intercambio de destino. Por lo tanto, no es invasivo para el nodo de origen o de destino.
¿Es correcto que la única forma de cambiar la comunicación entre servidores cuando uso palas es cambiando el archivo configurado y reiniciando la instancia?
En general, este ha sido el inconveniente aceptado de la pala.
Con el siguiente comando (advertencia: solo probado en RabbitMQ 3.1.x, y con un archivo rabbitmq.config muy específico que solo contiene), puede volver a cargar una configuración de pala del archivo especificado. (en este caso /etc/rabbitmq/rabbitmq.config )
rabbitmqctl eval ''application:stop(rabbitmq_shovel), {ok, [[{rabbit, _}|[{rabbitmq_shovel, [{shovels, Shovels}] }]]]} = file:consult("/etc/rabbitmq/rabbitmq.config"), application:set_env(rabbitmq_shovel, shovels, Shovels), application:start(rabbitmq_shovel).''
.
¿La configuración (vhost por aplicación) tiene sentido o me falta el punto por completo?
Esta decisión dependerá de su caso de uso. Los vhosts proporcionan principalmente separación lógica (y acceso) entre colas / intercambios y usuarios autorizados.
Shovel actúa como un consumidor integrado bien diseñado. Puede consumir mensajes de un intermediario de origen y una cola, y publicarlos en un intermediario de destino e intercambiarlos. Podría escribir una aplicación para hacer eso, pero la pala ya lo hizo bien; si lo único que necesita es mover los mensajes de una cola a un intercambio en el mismo intermediario u otro, la pala puede hacerlo por usted. Al igual que una aplicación de buen comportamiento, puede declarar intercambios / colas / enlaces, volver a conectarse, cambiar la clave de enrutamiento, etc. Puede configurarlo en la fuente o en el intermediario de destino, o incluso utilizar un tercer intermediario. Básicamente es un cliente de AMQP.
La federación , por otro lado, se usa para conectar su corredor a uno o varios intermediarios ascendentes, o incluso puede crear cadenas de intermediarios, doblando la topología de la forma que desee. Puede federar intercambios o colas y, por ejemplo, distribuir mensajes a varios intermediarios sin la necesidad de enlazar colas adicionales a un intercambio de temas o utilizar un intercambio de fanouts, y traspasar mensajes de cada cola a un intermediario en sentido descendente.
Para recapitular, la federación opera a un nivel superior, mientras que pala es en su mayoría "solo" un cliente bien escrito.
Para reconfigurar la pala, tiene que reiniciar el intermediario, desafortunadamente.
No creo que realmente necesites un vhost por aplicación. Puede agregar un usuario por aplicación al bróker sin vhosts separados. Sin embargo, no estoy seguro de lo que quiere decir con "compartir un evento entre fantasmas".