Какой хороший механизм связи Master-Slave на основе Java?

Question

Я создаю Java-приложение, которое требует связи главный-подчиненный между JVM, возможно, находящейся на одной физической машине.Будет «главный» сервер, работающий внутри сервера приложений Java EE (то есть JBoss), к которому будут подключаться «подчиненные» клиенты и динамически регистрироваться для связи (то есть мастер не будет знать IP-адреса / портыпоэтому не могут быть настроены заранее).Главный сервер выступает в роли контроллера, который будет выполнять работу с подчиненными, и подчиненные будут периодически отвечать уведомлениями, поэтому будет двусторонняя связь.

Я изначально думал о системах на основе RPC, где каждыйсторона была бы сервером, но это могло бы стать сложным, поэтому я бы предпочел механизм, где есть открытый сокет, и они общаются взад и вперед.

Я ищу механизм связи, который был бы низкимзадержка, когда сообщения будут в основном примитивными типами, поэтому никакой серьезной сериализации не требуется.Вот что я посмотрел:

• RMI
• JMS: встроенные в Java, подчиненные клиенты будут подключаться к существующей ConnectionFactory на сервере приложений.
• JAX-WS / RS: и ведущий, и ведомый будут серверами, предоставляющими интерфейс RPC для двунаправленной связи.
• JGroups / Hazelcast: используйте общие распределенные структуры данных для облегчения связи.
• Memcached / MongoDB: используйте их в качестве «очередей» для облегчения связи, хотя клиентам придется опрашивать, чтобы была некоторая задержка.
• Thrift: кажется, что сохраняется постоянное соединение, но не уверенКак интегрировать / встраивать сервер Thrift в JBoss
• WebSocket / Raw Socket: это будет работать, но потребует гораздо больше пользовательского кода, чем хотелось бы.

Есть литехнология, по которой я скучаю?

Редактировать: Также посмотрел:

• JMX: клиент подключается к JMX-серверу JBoss и получает JMX-уведомления для bidirectional comms.

Answer 1

Хорошо, я предлагаю JMS, если вы ищете что-то, что основано на Java.Он имеет все функции, которые вы ищете, плюс мощный сервер приложений, такой как JBoss.Однако другой вариант, который не полностью основан на Java и не использует очереди, будет использовать протокол HTTP и JAXB (веб-службы RESTful).Это очень легкий способ общения между двумя сторонами.Ваши объекты будут преобразованы в XML с использованием JAXB и перенесены на другую сторону, а затем вы приведете их к объекту, как только получите его.

Answer 2

Честно говоря, я бы просто придерживался JMS. У вас есть одна очередь, из которой ваши подчиненные могут получать сообщения, и одна очередь, в которую они помещают их обратно. Вы можете установить свойства о том, кто обрабатывал каждое сообщение (для учета) прямо на конверте. Вы получаете постоянство со многими J2EE-провайдерами (glassfish, jboss).

Кроме того, вы можете легко перейти на распределенную JVM с несколькими серверами без дополнительного программирования.

Однако в некоторых случаях он может не соответствовать определению «малой задержки».

Answer 3

Если вы ищете производительность, и оба ваших приложения работают на Java, без межсетевого экрана, вы можете немедленно исключить все протоколы на основе XML. Если связь является синхронной (ведущий ожидает, пока ведомое устройство завершит работу), тогда используйте RMI, в противном случае JMS. Вы также можете использовать TCP напрямую для максимальной производительности. Если есть много подчиненных, которые получают одно и то же сообщение, вы можете посмотреть на наборы инструментов групповой коммуникации, такие как JGroups или Spread (быстрее, но не на 100% Java). В конечном итоге вы можете обнаружить, что другие люди уже создали то, что вы пытаетесь построить. Посмотрите на Gridgain.

Answer 4

Еще два варианта:

Zookeeper (http://hadoop.apache.org/zookeeper/) Не использовал его, но здесь уместно звучит. RabbitMQ (http://www.rabbitmq.com/) Организация очереди сообщений с низкой задержкой. Здесь много гибкости.

Answer 5

Вы также можете проверить Мул.Я чувствую, что это идеальное решение для вашей проблемы.

Answer 6

Вы также можете взглянуть на Redisson проект, в котором есть публикация / подписка и другие общие структуры распределенных данных для ваших нужд.

Answer 7

WebSockets поможет вам общаться между веб-сервером и клиентом, а не между двумя JVM. Если это действительно то, что вам нужно, http://fermiframework.org предоставляет Java-RMI (от сервера к клиенту).

Answer 8

Для Thrift вы можете использовать TServlet в качестве точки входа для вашего сервиса Thrift. То, что вы описали, звучит как большая проблема, которую нужно решить с помощью activemq или zookeeper.

Answer 9

В зависимости от ваших требований, вы можете обнаружить, что Raw Socket имеет меньше кода, чем другие подходы. Это, безусловно, будет иметь самую низкую задержку. Вы можете уменьшить его до 20 микросекунд по петле назад.

Чем больше у вас требований, тем больше вероятность, что вы захотите решение высокого уровня. Однако, если все, что вам нужно, это что-то более легкое, необработанные сокеты могут быть самыми простыми.

Answer 10

Возможно, вы захотите взглянуть на Activatable. Если подчиненные устройства отвечают, когда работа завершена, то в этом случае хорошим решением могут быть rmi и Activatable. Если вы используете rmiregistry на контроллере, то все ведомые могут легко зарегистрироваться на контроллере, и они могут быть активированы при необходимости.