ВВОДНАЯ В MESSAGE QUEUE

Давайте снова вспомним нашу пиццерию и заказы через приложение.

В каких ситуациях обычного синхронного запроса уже недостаточно?

1️⃣У нас есть пиковая нагрузка

Мы находимся в офисном квартале. Каждую пятницу около 17:00 соседние компании начинают массово заказывать еду сотрудникам. В результате в течение часа приходит в 50 раз больше заказов, чем обычно.

Что делать? Держать несколько серверов только ради этого пика? Но ведь в остальное время хватает и одного.

2️⃣Нельзя потерять заказ

Представьте, что клиент увидел в приложении сообщение: «Ваш заказ принят». Но в этот момент сервис кухни перезагрузился, потому что уборщица тетя Галя случайно задела шваброй провод. В итоге информация до кухни не дошла, а клиент уверен, что пиццу уже готовят.

Такой сценарий недопустим.

3️⃣Один заказ — это не одна операция

На самом деле после нажатия кнопки «Заказать» начинается целая цепочка действий:
⬛проверить наличие ингредиентов;
⬛рассчитать время доставки;
⬛оценить загрузку кухни;
⬛подобрать курьера;
⬛списать оплату;
⬛и многое другое.
Причем некоторые операции намного тяжелее остальных. Например, расчет времени доставки может использовать сложные алгоритмы построения маршрутов и работать в несколько раз дольше проверки ингредиентов. Возможно, ему вообще понадобится отдельное железо или GPU.

Было бы здорово выполнять такие задачи независимо друг от друга.

4️⃣Клиенту не нужен мгновенный ответ

На самом деле пользователю совсем не обязательно сразу получать окончательный результат. Достаточно увидеть сообщение: «Ваш заказ обрабатывается». А уже через несколько секунд приложение может прислать: «Заказ принят. Курьер будет через 28 минут.» или «К сожалению, кухня сейчас перегружена. Попробуйте оформить заказ позже.»

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

Именно здесь появляется Message Queue.

Что меняется?

1️⃣Запрос от клиента становится очень легким. Сервис не пытается выполнить всю работу сразу. Он просто кладет сообщение в очередь и отвечает клиенту: «Заказ принят в обработку.» На этом соединение можно закрыть.

2️⃣Пиковые нагрузки становятся не страшны. Consumer разбирает сообщения в своем темпе. Да, в часы пик ответ может прийти немного позже, зато вам не нужно постоянно держать огромный парк серверов.

3️⃣Сообщения не теряются. Если сообщение попало в очередь, оно будет ждать обработки. Например, пока повар не нажмет в приложении кнопку: «Берем заказ №123 в работу.» Только после этого сообщение считается успешно обработанным.

4️⃣Микросервисы начинают работать независимо. Каждый сервис может читать свою очередь и выполнять только свою часть работы. Проверка ингредиентов, расчет доставки, поиск курьера — все это происходит параллельно. И если сервис расчета доставки внезапно перезапустился, остальным сервисам не придется выполнять свою работу заново.

Это была вводная история о Message Queue и ответ на вопрос, зачем вообще могут быть нужны очереди сообщений.

Если было полезно — ставьте 🔥

#бабанюра_программирует