Дизайн системы обмена сообщениями - одна очередь на один тип сообщения против одной очереди для всех сообщений

Question

Я хочу реализовать систему обмена сообщениями со следующими участниками:

1) Веб-интерфейс 2) Демон 3) База данных

Веб-интерфейс отправляет запросы демону, которые помещаются вочередь (ActiveMQ).

Демон считывает сообщения, обрабатывает их и записывает некоторые данные в базу данных.

И веб-интерфейс, и демон обращаются к базе данных.

Еслитребуется, дополнительные демоны могут быть подключены к очереди (для повышения производительности).

---

Существует 4 типа сообщений, направленных к демону.Кроме того, я хочу, чтобы демон регулярно отправлял сообщение «heartbeat», чтобы я (или приложение мониторинга) знал, жив ли конкретный демон или нет.

Я могу спроектировать систему различными способами:

1) Поместить все сообщения от веб-интерфейса демону в очередь A, а сообщения пульса - в очередь B.

Очередь A будет содержать сообщения разных типов.

2) Поместите все сообщения типа 1 в очередь A1, сообщения типа 2 в очередь A2 и т. Д.

В этом случае каждая очередь будет содержать сообщения только одного типа.

Оба вариантатехнически возможно.

Мой вопрос: как я могу решить, какой из них лучше?

Какие критерии необходимо учитывать?

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

Дмитрий

Answer 1

@ Дмитрий, если есть разница в объеме сообщения определенного типа сообщения .. например, если ожидается, что ваше сообщение типа 1 будет 100 сообщений в минуту, тогда как, как ожидается, тип 2 будет 2 сообщения в минуту, это будетимеет смысл иметь отдельную очередь по следующим причинам: -

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

2. Это может произойти, если сообщение типа 2 (хотя и меньше) сидитв самом конце очереди и нужно дождаться обработки всех сообщений type1 для их очереди.

Answer 2

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