¿Qué es un buen mecanismo de comunicación Maestro-Esclavo basado en Java?

Question

Estoy creando una aplicación Java que requiere una comunicación maestro-esclavo entre JVM, que posiblemente resida en la misma máquina física. Habrá un servidor "maestro" ejecutándose dentro de un servidor de aplicaciones Java EE (es decir, JBoss) que tendrá clientes "esclavos" conectados a él y se registrará dinámicamente para la comunicación (es decir, el maestro no conocerá las direcciones IP/puertos del esclavos entonces no se pueden configurar de antemano). El servidor maestro actúa como un controlador que funcionará para los esclavos y los esclavos responderán periódicamente con notificaciones, por lo que habría una comunicación bidireccional.

Originalmente estaba pensando en sistemas basados ​​en RPC, donde cada lado sería un servidor, pero podría ser complicado, así que preferiría un mecanismo donde haya un socket abierto y que hablen de un lado a otro.

Estoy buscando un mecanismo de comunicación de baja latencia donde los mensajes sean en su mayoría tipos primitivos, por lo que no es necesaria una seria serialización. Esto es lo que he visto:

• RMI
• JMS: Built-in de Java, los clientes "esclavos" se conectarían a la ConnectionFactory existente en el servidor de aplicaciones.
• JAX-WS/RS: Tanto el maestro como el esclavo serían servidores que expondrían una interfaz RPC para la comunicación bidireccional.
• JGroups/Hazelcast: utilice estructuras de datos distribuidos compartidos para facilitar la comunicación.
• Memcached/MongoDB: Úselos como "colas" para facilitar la comunicación, aunque los clientes tendrían que sondear para que haya alguna latencia.
• Ahorro: Esto parece mantener una conexión persistente, pero no sabe cómo integrar/incrustar un servidor de Ahorro en JBoss
• WebSocket/Raw Socket: Esto funcionaría, pero requiere código mucho más a medida de lo que había me gusta.

¿Existe alguna tecnología que me falte?

Editar: también han visto:

• JMX: Haga que el cliente conectarse al servidor JMX JBoss y recibir notificaciones de JMX para comunicaciones bidireccionales.

Answer 1

Tenemos una aplicación similar, y acabamos de utilizar Servlet en JBoss con "esclavos" presionando de forma temporizada. Esto está bien, pero no es óptimo para baja latencia.

Ahora estamos buscando en Netty. Puede usar el protocolo que quiera usar. Probablemente usemos HTTP y JAXB. Supongo que esto podría clasificarse como "WebSocket/Raw Socket", pero es mucho mejor que usar uno sin formato ..

Answer 2

Es posible que desee echar un vistazo a Activable. Si los esclavos responden cuando el trabajo está completo, entonces rmi y Activatable podrían ser una buena solución en este caso. Si usa el rmiregistry en el controlador, entonces todos los esclavos pueden registrarse fácilmente con el controlador, y estos se pueden activar cuando sea necesario.

Answer 3

Otros dos opciones:

Zookeeper (http://hadoop.apache.org/zookeeper/) no lo ha usado, pero suena apropiado en este caso. RabbitMQ (http://www.rabbitmq.com/) Cola de mensajes de baja latencia. Mucha flexibilidad aquí.

Answer 4

Honestamente, me quedaría con JMS. Tienes una cola a la que tus esclavos pueden sacar mensajes, y una fila en la que los vuelven a poner. Puede establecer propiedades sobre quién procesó cada mensaje (para la contabilidad) directamente en el sobre. Obtiene persistencia con muchos proveedores J2EE (glassfish, jboss).

Además, puede pasar fácilmente a la JVM distribuida de servidores múltiples sin programación adicional.

Sin embargo, es posible que no se ajuste a la definición de "baja latencia" en algunos casos.

Answer 5

Bueno, sugiero JMS si está buscando algo que se base en Java. Tiene todas las características que está buscando además de un servidor de aplicaciones sólido como JBoss. Sin embargo, otra opción que no está completamente basada en Java y no está utilizando colas, estaría usando el protocolo HTTP y JAXB (servicios web RESTful). Esta es una forma muy ligera de comunicarse entre dos lados. Sus objetos se transformarían en XML utilizando JAXB, y se transferirían al otro lado, y luego lo lanzarían de regreso al objeto una vez que lo recibiera.

Answer 6

También puede marcar Mule. Siento que es la solución perfecta para su problema.

Answer 7

Si busca rendimiento y sus dos aplicaciones son java, sin un firewall intermedio, puede excluir inmediatamente todos los protocolos basados ​​en XML. Si la comunicación es síncrona (el maestro espera que el esclavo complete el trabajo), utilice RMI, de lo contrario JMS. También puede usar TCP directamente para obtener el máximo rendimiento. Si hay muchos esclavos que reciben el mismo mensaje, puede buscar kits de herramientas de comunicación grupal como JGroups o Spread (más rápido pero no 100% java). En última instancia, es posible que otras personas ya hayan compilado lo que intentas construir. Eche un vistazo a Gridgain.

Answer 8

Dependiendo de sus requerimientos, puede encontrar que Raw Socket tiene menos código que otros enfoques. Ciertamente tendrá la latencia más baja. Puedes bajarlo a unos 20 microsegundos por vuelta.

Cuantos más requisitos tenga, más probable es que desee una solución de alto nivel. Sin embargo, si lo único que quieres es algo ligero, los conectores crudos pueden ser los más simples.

Answer 9

Para ahorrar puede usar TServlet como punto de entrada para su servicio Thrift. Lo que describiste es un problema mayor que resolver con activemq o zookeeper.

Answer 10

WebSockets lo ayudará con la comunicación entre el servidor web y el cliente, no entre dos JVM. Si eso es lo que realmente quiere, http://fermiframework.org proporciona una RMI java a JavaScript (de servidor a cliente).

Answer 11

También puede consultar el proyecto Redisson que tiene publicar/suscribir y otras estructuras de datos distribuidos compartidos para sus necesidades.