Escribir un sistema de colas básico es bastante simple, pero como ya mencionó anteriormente con todos los desafíos, hacerlo bien es otra cuestión. He utilizado sistemas locales para los que escribí el código fuente, sistemas de terceros y varios proveedores de JMS. JMS (Java Messaging Service) es la solución más completa que he encontrado hasta ahora. Gran parte de lo que pides está disponible en JMS. Mi proveedor JMS favorito es ActiveMQ. Gratis, eficiente, fácil de instalar y, lo que es más importante, fácil de insertar en mi aplicación con Spring. Los proveedores de JMS no proporcionan todo lo que solicitó de forma inmediata, pero proporcionan un conjunto de herramientas para manejar gran parte de lo que solicitó si su aplicación lo necesita. No he encontrado muchas aplicaciones que necesiten todo lo que enumeró. Es posible que ordenar no sea importante (es mejor si no lo es),
http://activemq.apache.org/what-open-source-integration-solution-works-best-with-activemq-.html
¿Tiene orden fuerte o pierde? Sí. Tiene ambos dependiendo de las necesidades de sus programas. Aquí están los detalles: http://activemq.apache.org/total-ordering.html .
¿Tiene puesto idempotente? No, pero esto es trivial de implementar en su capa de aplicación si lo necesita.
¿Podemos tener más colas de las que caben en una sola máquina? Sí. Puede tener servidores en clúster y, si desea configurar varias máquinas con diferentes colas, puede hacerlo y extraer de cualquiera de ellos.
¿Podemos tener más datos en una cola que los que caben en una sola máquina? Sí, la mayoría de los proveedores de JMS tienen que usar algún tipo de base de datos / almacenamiento persistente para garantizar que los mensajes no se pierdan o pierdan si el proveedor de JMS deja de funcionar.
¿Cuántas máquinas pueden fallar antes de que potencialmente perdamos datos? Esto es un poco más difícil de responder porque está relacionado con el tiempo. Sin embargo, puede bloquear un proveedor de JMS y siempre que el disco no esté dañado, volverá a funcionar y comenzará donde recibió la última confirmación. Esto significa que los mensajes podrían entregarse dos veces, pero si codifica su aplicación para manejar esto, no es un problema. Siempre que tenga al menos uno de cada tipo (productores, consumidores o servidores JMS) se completará. También puede tener carga / equilibrio / conmutación por error para la redundancia en caso de que se salga un disco.
¿Puede tolerar divisiones de red? Creo que entiendo lo que quieres decir con "división de red", pero no estoy completamente seguro. Supongo que quiere decir que si los servidores JMS están agrupados y perdemos la conexión con uno de los servidores, saltará a otro servidor y continuará donde se quedó. Sí, pero una vez más, este tipo de situaciones pueden conducir a mensajes duplicados dependiendo de en qué momento el cliente perdió la conexión.
¿Puede conciliar datos automáticamente cuando se repara una división de red? Si está utilizando sesiones transaccionadas, solo reenviará cualquier mensaje que haya recibido una confirmación a los clientes existentes que estén activos.
¿Puede garantizar la entrega cuando los clientes pueden fallar? Sí, este es uno de los principales objetivos de JMS. La entrega garantizada significa que si un mensaje está en cola, es garantizado que será manejado por un cliente.
¿Puede garantizar que el mismo mensaje no se entregue más de una vez? Sí, si se están utilizando las sesiones transaccionadas. Eso significa que un cliente ha aceptado el mensaje y llamó a commit / rollback. Una vez que se llama a commit, no volverá a entregar el mensaje.
¿Puede un nodo bloquearse en cualquier punto dado, volver a funcionar y no enviar basura? En el caso de que tenga colas agrupadas duraderas. Sí, no arrojará "basura" si el otro nodo del clúster ha entregado el mensaje. Todavía puede volver a entregar cualquier cosa que no haya sido reconocida.
¿Se pueden agregar nodos o eliminar nodos de un clúster en ejecución sin tiempo de inactividad? Sí.
¿Se pueden actualizar nodos en un clúster en ejecución sin tiempo de inactividad? Esto es un poco más complicado de responder, pero creo que sí, puedes hacer esto.
¿Se puede ejecutar sin problemas en servidores heterogéneos? Que significa exactamente? He descubierto que la mayoría de los proveedores de JMS son muy fáciles de ejecutar en entornos que utilizan diferentes hardware, SO, etc. Aunque, si se refiere al rendimiento, eso es otra cosa. Cualquier sistema de procesamiento distribuido puede verse afectado negativamente por un nodo lento. Tenía 2 8 servidores Intel Core ejecutando la cola y los consumidores. Eso es 16 núcleos juntos, y obtuve un mejor rendimiento al usar solo esas dos cajas, que cuando agregué una máquina de núcleo único como consumidor. Esa máquina de un solo núcleo era mucho más lenta que ralentizaba toda la red en un factor de 2x. Esto no tenía nada que ver con JMS per se.
¿Puedes "pegar" las colas a un grupo de servidores? Respuesta corta si. Se me ocurre una forma en la que puede ejecutar un clúster que solo está en el centro de datos europeo y configurar la cola allí. Luego, en su configuración de primavera, configure a sus consumidores para que consuman esa cola y otras colas en otros clústeres. Es posible que desee consultar los documentos:
http://activemq.apache.org/clustering.html
¿Puede asegurarse de poner réplicas de datos en al menos dos centros de datos, si están disponibles? Una vez más, creo que sí, pero es mejor consultar los documentos de agrupación.
Nuevamente, JMS tiene muchas opciones que puede ajustar según sus necesidades. El uso de sesiones de transacciones y colas duraderas conlleva un costo de rendimiento. He visto encender todas las campanas y silbatos impactando el rendimiento hasta 10 veces. Cuando usé JBossMQ si desactivamos algunas de estas características, podríamos obtener alrededor de 10,000 mensajes / s, pero al activarlos nos redujo a 1000 mensajes / s. Gran caída.