Как реализовать эту очередь в кластере Jboss? - PullRequest
Новая
       23

Как реализовать эту очередь в кластере Jboss?

0 голосов
/ 27 июля 2010

мое приложение работает как промежуточное ПО, получая запросы от клиентов, затем преобразовывая его в определенной логике и отправляя преобразованные запросы другому поставщику услуг в виде обычных HTTP-запросов или мыльных запросов Webservice. Приложение было развернуто на двух серверах jboss (в кластере) за балансировщиком нагрузки.

скажем, мое приложение А, поставщик услуг S.

Теперь мне сообщили, что каждый год S будет снижаться несколько (3-5) раз. Каждый простой будет длиться около 4 часов. Я могу получить график о времени простоя.

Во время простоя A не должен больше преобразовывать и отправлять запрос S, а помещать полученные запросы в очередь. После возвращения S запросы в очереди должны быть обработаны.

Примечание:

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

  2. На основании 1, когда A работает с запросами в очереди, новые входящие запросы должны ставиться в очередь, хотя S уже доступен. пока очередь не пуста, A может продолжить отправку запроса непосредственно в S.

  3. Каждую минуту А получает 2-3 запроса.

Поскольку у нас есть два Jboss, я планировал поддерживать эту очередь в базе данных, потоки, работающие в очереди и управляющие состоянием простоя. Однако синхронизация между двумя jboss всегда вызывает у меня головную боль.

Вскоре проблемы, с которыми я столкнулся, были:

  • как установить флаг времени простоя, чтобы два jboss выполняли запрос вместо отправки. (Я думал, что перед обработкой каждого запроса база данных запрашивала этот флаг. Флаг был установлен потоком. Возможно, это худшее решение.)

  • после возвращения S, как спроектировать операцию Dequeue для двух jboss. (кажется, что в то же время всегда есть один jboss бездействует ...)

  • как сообщить двум jboss: «теперь очередь пуста, больше не ставьте в очередь».

Логика немного сложна. Надеюсь, я четко объяснил свою проблему ...

Ребята, у вас есть идеи по этому поводу?

Еще немного описания о ФИФО. Если не было простоев, A может обрабатывать эти запросы от разных клиентов параллельно. Потому что этот «понравившийся транзакции» заказ обеспечивается клиентами. например. 

client x :
-send http://..../createUser...
-received 'success' from A
-send http://../updateUser...
-received 'success' from A

если createUser () не удалось, updateUser не будет отправлен. 

client y:
-send http://.. createCompany...

Учитывая, что другой клиент (y) отправлял запрос createCompany одновременно с x.createUser. эти два запроса могут обрабатываться A параллельно.

Однажды подумав о времени простоя и очереди: 

-send http://..../createUser...
(downtime)
-received 'enqueue'
(S is back)
-send http://../updateUser...

теперь порядок "create-> update" должен обеспечивать A, а не клиенты.

Заранее спасибо!

Kent

1 Ответ

0 голосов
/ 27 июля 2010

Получаете ли вы какие-либо подтверждения от S, что конкретный запрос был получен правильно?(Если нет, вам следует рассмотреть возможность реализации этого, чтобы сделать ваше приложение более надежным и минимизировать шансы на потерю запросов из-за проблем с сетью, сбоев сервера и т. Д.)

Такой механизм подтверждения мог бы быть улучшен с помощью алгоритмаиспользование увеличивающихся таймаутов в случае, если ACK не получен вовремя после отправки запроса.Т.е. если ACK не получен в течение настроенного интервала времени ожидания t, запрос повторно отправляется.В следующий раз будет больше тайм-аут, например, 2 * t, затем 4 * t и т. Д. Пока фактический запрос не подтвержден, входящие новые запросы ставятся в очередь.Как только фактический запрос успешно передан, поставленные в очередь запросы обрабатываются в порядке FIFO.Если очередь пуста, нормальная обработка возобновляется.

Этот алгоритм будет автоматически обрабатывать запланированные простои S, а также любые другие сбои сети и т. Д. За счет некоторого увеличения обработки и сетевого трафика.Но при 2-3 запросах в минуту это не должно вызывать беспокойства (если, конечно, отдельные запросы не очень большие).

Конечно, его можно даже улучшить, чтобы сделать время ожидания по умолчанию настраиваемым по периодам времени.Т.е. на время запланированного простоя в 4 часа время по умолчанию может быть установлено на 4 часа.По истечении времени простоя время сбрасывается до значения по умолчанию.

...