Думаю над архитектурой приложения (должна поддерживать горизонтальное масштабирование, fail-over и т.д.), исходя из требований (постоянные соединения с клиентами), надумал следующее:
Система состоит из двух видов серверов:

•  frontend серверы (пишут сообщения в очередь application серверам), которые держат постоянные соединения с клиентами и получают/отправляют информацию (реализация с использованием Apache Mina);
•  application серверы, которые обрабатывают информацию от клиентов и генерируют ответы.

На данный момент остановился на MQ подходе к решению этой задачи, а конкретно на HornetQ. Но остались нерешенными некоторые очень важные вопросы:

•  если делать одну очередь сообщений и множество consumer'ов, то непонятно как балансировать нагрузку между ними.
•  если сделать по очереди на consumer'а и периодически от них слать информацию и нагрузке frontend'у, чтобы он учитывал её и, исходя из этого, выбирал очередь сообщений, то возникает ещё один вопрос: что делать, если consumer отвалился, куда девать сообщения из его очереди и как это можно реализовать?

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

Это сообщение отредактировал(а) freel0ader - 19.11.2010, 00:23

Очередь должна доставлять сообщение только одному подписчику. Доставленное сообщение удаляется из очереди. Должна быть такая опция в настройках очереди. А подписчик должен сначала обработать сообщение, и только потом обращаться за следующим.

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

Поскольку очередь тоже может умереть, то сообщения в ней надо сохранять на диск, чтобы можно было восстановить при рестарте.

А вообще, поскольку речь идет о потоке независимых заданий, т.е. порядок их обработки строго говоря не критичен, то концепция grid систем здесь наверное очень удачно применима. Сама по себе очередь - вчерашний день. Ведь хорошо бы, если очередь дублировалась, и узлы сами находили друг друга. В гриде это обеспечивается. По моим представлениям.   



Это сообщение отредактировал(а) COVD - 19.11.2010, 05:15

Да, это называется гарантированная доставка, реализовывать самому такое не нужно, в JMS это уже реализовано.
Очередь не обязана быть от end-point до end-point, так называемая архитектура Piples & Filters позволяет добавлять/удалять элементы в цепочке как угодно. Таким образом если сначала передать управление Router'у, то он будет решать какому клиенту отдать; так можно сделать что-то вроде load balancing (элементарный load balancing - когда сообщение будет запрашиваться Polling Consumer, когда первый освободившийся consumer забирает сообщение из очереди). Однако для load balancing есть много реализаций, лучше выбрать из существующего (например, apache zookeeper). 
Тебе обязательно нужно почитать Integration Patterns.

Это сообщение отредактировал(а) Старовъръ - 19.11.2010, 08:15