Очереди сообщений

В подкасте Podlodka вышел выпуск про менеджеры очередей. Зашли с основных понятий и дальше по всем аспектам до антипаттернов проектирования. Рассказывал Владимир Перепелица, архитектор и продакт-менеджер из Tarantool.

До сих пор не сталкивался ни с Kafka, ни RabbitMQ, поэтому мне было интересно послушать. Что-то из выпуска записал (как мог):

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

⌘

В целом, чем-то похоже на базы данных: тоже запись и чтение. Иногда даже отдельные бд используют как очередь — в Яндекс GO используют Mongo в сервисе репликации данных от источников в DWH.

Отличие от баз данных: чтение — модифицируащая операция. Получатель сообщения подтверждает факт получения и брокер удаляет это сообщения у себя.

⌘

Антипаттерны — когда лучше не использовать очереди:
⁃ очереди добавляют латенси к работе как асинхронный инструмент по своей идее;
⁃ когда данные нужны прям сейа и нет смысла ждать (например посмотреть баланс в приложении: лучше сразу отдать ошибку, если не грузится)

⌘

За чем следить во время работы:
⁃ работа под нагрузкой. При тестах всё может «летать», а под нагрузкой иногда появляются рекурсивные самозапросы и система сама себя дидосит.
⁃ длина очереди — она должна быть во вненяемых пределах. Очередь по определению ограничена (в конечном счёте — ресурсами системы).

⌘⌘⌘

Владимир там рассказывает ещё больше и, конечно, точнее, чем я, поэтому рекомендую послушать весь выпуск, если релевантно:

в iTunes и Overcast

#послушано