Когда использовать расширенный протокол очереди сообщений, такой как RabbitMQ? [закрыто]

Может кто-нибудь объяснить мне, в каких случаях я должен рассмотреть использование AMQP, например, RabbitMQ? Каковы плюсы и минусы?

design message-queue

— ВБД
источник

Есть несколько хороших ответов на аналогичный вопрос о переполнении стека: Реальное ли использование JMS / очередей сообщений?

— Ган

Вы можете посмотреть ниже ссылку. У этого есть широкое описание: stackoverflow.com/a/51377756/3073945

— Md. Sajedul Karim

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

Если вы поставите очередь между веб-службой и системой учета, вы сможете:

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

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

— Виталий Олегович
источник

1) Чем A связан с B лучше, чем A связан с C и C связан с B?

— Чарли

2) Почему бы не поставить очередь в систему учета? Зачем вводить новую подвижную часть черного ящика, которая нуждается в дополнительной настройке?

— Чарли

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

— Виталий Олегович

Я ошибаюсь для 1. Если очередь помещается в веб-службу или очередь помещается в приложение, то остается одна связь. Однако, если очередь является внешней по отношению к обоим, теперь у вас есть в два раза больше связи и на 50% больше систем для управления / точек отказа. Если выбрана сторонняя очередь, у вас также будет этот новый пакет для изучения и настройки, и он, вероятно, будет обременен бесчисленными функциями, которые вам не интересны, функциями, которые были добавлены, чтобы сделать очередь универсальной и полезной для гораздо больше ситуаций, чем ваша собственная.

— Чарли

@Charlie, по-видимому, один брокер сообщений будет использоваться в нескольких системах. Или был бы один прокси для брокера. (В нашем случае мы используем одно устройство обмена сообщениями, которое может обрабатывать миллионы сообщений в секунду для всех наших систем). Это фактически создает большую развязку, потому что сообщение генерируется одной системой, и любая заинтересованная система может получить это сообщение и выполнить соответствующую логику. Единственная связь - с самой очередью.

— Майкл Браун

Помимо обеспечения буфера между веб-службой и другой серверной службой, очереди сообщений могут использоваться для более сложных сценариев. Rabbit MQ (и другие зрелые продукты очереди сообщений, также называемые MOM - Message-Oriented Middleware) можно настроить для маршрутизации и распространения сообщений в соответствии с другими правилами.

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

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

Это лишь некоторые из сценариев, включенных MOM.

— Майкл Браун
источник