Так уж получилось что как держатель профессии системного анализа я не раз в ходе занятий со студентами, собеседований, и а��сесментов сталкивался с проблемой непонимания базовых принципов и ценностей работы сервисов очередей. Люди не понимают ни как оно работает ни для чего нужно. И раз уже до ИТ мне посчастливилось почти 10 лет отслужить в армии то пример, который очень зашел даже далеким от ИТ людям, со временем родился сам собой.
Итак, вводные данные: военная столовая, мы — проектировщики системы (командиры). Помимо вас в задаче имеется погреб с картошкой и необходимость ее почистить. Для этого у нас есть почти неограниченное количество не особо сообразительных исполнителей — солдат, которым можно поручить эту работу. Согласно нашим вводным солдаты, как и информационные системы, не умеют и не должны сами принимать решения, они делают только то, что мы им поручили.
Этап 1. Разделение зон ответственности сервисов
На первом этап мы выделяем по одному солдату на два участка работы: первый будет приносить картошку из погреба, а второй — чистить то, что принес первый и сбрасывать в кастрюлю для варки. Запускаем процесс, смотрим что получилось:
Если бы солдаты были айтишниками они конечно тут же узнали типичное синхронное взаимодействие между сервисами. И мы с вами отчетливо видим проблему: солдат, который чистит картошку, является узким местом: слишком медленно обрабатывает запросы, и в результате второй успевает покурить, а иногда и вовсе забыть про запрос.
Этап 2. Масштабирование
Видя проблему первое, что приходи в голову неопытным командирам — «Надо накинуть еще людей» (горизонтальное масштабирование) и возможно — как то оптимизировать чистильщика чтобы работал побыстрее — «Накинуть люлей чистильщику, выдать ему наконец острый нож» (вертикальное масштабирование).
Делаем это упражнение и узким местом становится носильщик. Пытаемся таким же образом оптимизировать носильщика и накинуть ресов уже ему, но так как вся картошка разная и все люди работают в разном темпе — сбалансировать работу не получается. Кто то все равно простаивает.
Говоря айтишным языком, у нас есть несколько оптимизированных экземпляров приложения, которые работают параллельно. Плюс еще добавился прокси‑сервер: сержант‑балансировщик, который следит кому из чистильщиков можно отдать картошку, а также смотрит чтобы не несли гнилую (первичная валидация запросов переходит в область полномочий прокси). Проблема стала менее очевидной, время простоя рабочих сократилось, но не ушло совсем. Помимо этого в системе стало много экземпляров приложения, за которыми надо следить, кормить, и обслуживать. Мониторинг системы становится сложнее.
Этап 3. Сервис очередей
Самый умный из командиров находит старый ржавый таз и ставит его между носильщиками и чистильщиками. Модель взаимодействия меняется: теперь носильщики ничего не ждут и складывают принесенную картошку в таз, освободившийся чистильщик тоже ничего не ждет, и просто берет из таза новую картошку. Сержант из распределителя работы превращается в систему мониторинга, задачей которой является следить за тем, что пропускная способность системы позволяет почистить всю картошку к обеду.
Как вы уже наверное поняли, роль сервиса очередей у нас тут играет тот самый таз. Сообщения в очереди — картошка. Носильщики начинают называться умным словом «продюсер», а чистильщики — «консьюмер».
Теперь поговорим айтишным языком как же можно еще оптимизировать процесс, чтобы он шел быстрее:
Увеличиваем размер сообщения: носильщики начинают носить картошку из погреба не по одной, а сразу ведрами. Это называется умным словом «массив».
Выдаем чистильщику электрический станок для чистки, в который он может загрузить сразу все ведро или даже три. Это уже «Batch processing».
Этап 4. Анализ рисков
Что же может пойти не так:
Мы с вами в армии. Если солдаты оставили картошку в тазу и ушли спать, то утром они найдут пустой таз, из которого всю картошку украли. Это называется «Retention time». В реальной жизни он используется для того, чтобы таз не переполнялся, так как обработанные сообщения из Kafka никуда не деваются, просто условно помечаются как обработанные. Это позволяет, например, при необходимости об��аботать сообщение еще раз после ошибки.
Таз могут опрокинуть. Для этого картошка делится на несколько тазов. Да и брать картошку для чистки удобнее каждому чистильщику из своего таза. Это называется «партиции». Если один таз опрокинут — работа не встанет пока будут собирать картошку из него обратно. Если один из чистильщиков уйдет отдохнуть - из его таза картошка будет распределена по другим.
Таз может опустеть. Количество картошки в тазу называется «Consumer lag». И если он слишком сильно растет — таз может либо начать переполняться и терять сообщения (картошка посыпалась на пол, по умному — Retention bytes). Надо за этим следить и заранее масштабировать чистильщиков или освобождать носильщиков.
Этап 5. Какие есть возможности?
Какой-нибудь умный командир может потребовать доставать из таза картошку, например, по цвету.
Надо помнить, что сервис очередей это не база данных, и все что там лежит — достается так, как отдает очередь
Можно сделать так, чтобы картошку чистили разные группы людей. Это называется «Консьюмер‑группа». Например, если синяя картошка идет на жарку, а белая на варку — разные консьюмер группы могут по разному обрабатывать сообщения.
Если очень хочется — можно настроить партиционирование по разным тазам в зависимости от цвета картошки. Тогда консьюмерам не придется думать о том, как ее сортировать - каждый будет получать из таза только картошку своего цвета.
