Как обрабатывать сообщения в том же порядке из очереди, используя несколько серверов в Java - PullRequest
0 голосов
/ 23 мая 2019

У нас есть очередь ActiveMQ, которая будет получать 100 тыс. Сообщений о заказе акций (каждое сообщение содержит название акции, цену продажи, цену покупки в формате json) в секунду.Из 100 000 сообщений в секунду не может быть n сообщений одной акции.Если мы получаем несколько сообщений одного и того же товара, нам нужно обрабатывать все эти сообщения в одном и том же порядке, используя Java.Мы не можем обрабатывать 100 тыс. Сообщений в секунду, используя одного слушателя на одном сервере.Необходимо обработать его с помощью нескольких слушателей и серверов, но отобразить результат в пользовательском интерфейсе, используя тот же порядок, который размещен в очереди.

Чтение очереди акций -> Проверка запроса -> Обновление цены акций в пользовательском интерфейсе

Пример сообщения: - {stockName: "TCS", sellPrice: "102", bidPrice: "100 "}

Можете ли вы предложить решение для вышеуказанной проблемы.

Ответы [ 3 ]

1 голос
/ 23 мая 2019

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

0 голосов
/ 23 мая 2019

У нас было похожее требование, и мы использовали среду с открытым исходным кодом, называемую LMAX Disruptor, предположительно высокопроизводительную среду параллелизма.Вы можете поэкспериментировать, https://github.com/LMAX-Exchange/disruptor/wiki/Getting-Started.

На очень высоком уровне:

  1. Поместить полученные акции в кольцевой буфер [базовая структура данных, на которой построена структура], это будет потребитель для ActiveMQ и производитель для кольцевого буфера.

  2. Потребители / рабочие [в вашем случае множественное число - mulltiple здесь - это рабочий поток для каждого уникального имени запаса] возьмите Акции из рингбуфера упорядоченным способом.В работнике / слушателе вы можете обрабатывать событие на основе условия.

Я только что передал пример кода, пытаясь продемонстрировать ваш вариант использования, для справки: https://github.com/reddy73/Disruptor-Example

0 голосов
/ 23 мая 2019

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

  1. выбор групповых символов подписки и
  2. возможно добавление других сервисов позже к этой архитектуре. Вы можете не требовать этого сейчас, но, возможно, через 5 лет вам понадобится другой графический интерфейс или какой-либо вид службы мониторинга или воспроизведения. Если вы использовали темы, вы можете просто подключить новых подписчиков - вам не нужно менять сторону публикации для этих ...

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

Порядок сообщений гарантируется в одной и той же теме публикации, поэтому вы должны включить название темы в тему. Вы можете опубликовать что-то вроде ORDER.STOCK.TCS.

Но сбалансированная нагрузка, основанная на названиях акций, непроста, поскольку некоторые буквы, такие как Z, встречаются очень редко, а другие - часто. Поэтому в дополнение к названию акции добавьте в тему хэш% 100 имени акции. Например, если хеш-код TCS равен 12357, и вы делаете по модулю 100, вы публикуете его в ORDER.STOCK.TCS.57

Допустим, у вас есть 10 подписчиков, каждый подписчик может затем сделать 10 подписок. Например, подписчик 1 будет подписываться на ORDER.STOCK. *. 0, ORDER.STOCK. *. 1, ... ORDER.STOCK. *. 9

Подписчик 2 будет подписываться на ORDER.STOCK. *. 10, ORDER.STOCK. *. 11, ... ORDER.STOCK. *. 19

Если у вас есть 5 подписчиков, каждый из них делает 20 подписок (вы поняли). Причина этого в том, что

...