Как устроена схема консюмер-продюсер в Kafka?
Что проверяют
Понимаете ли вы Kafka как распределённый лог, а не как обычную очередь. Проверочный вопрос обычно один: что определяет параллелизм чтения и где гарантируется порядок сообщений.
Как отвечать
Соберите картину из четырёх понятий:
- топик и партиции: топик делится на партиции, каждая это упорядоченный лог, куда записи только добавляются. Порядок гарантирован внутри партиции, а не в топике целиком;
- продюсер: выбирает партицию по ключу сообщения (одинаковый ключ всегда в ту же партицию, поэтому события одного заказа идут по порядку), либо распределяет равномерно, если ключа нет;
- консюмер и группа: партиция в один момент читается ровно одним консюмером группы. Отсюда правило: больше консюмеров, чем партиций, ускорения не даст, лишние простаивают. Разные группы читают один топик независимо, каждая со своим смещением;
- смещение (offset): позиция чтения хранится в Kafka, а не у клиента. Сообщение после чтения не исчезает, оно лежит до истечения срока хранения, поэтому группу можно перечитать с начала.
Дальше про надёжность. У продюсера acks=all ждёт подтверждения от синхронных реплик, acks=1 быстрее, но теряет данные при падении лидера. Идемпотентный продюсер убирает дубли при ретраях. У консюмера коммит смещения до обработки даёт потерю при падении, после обработки даёт повтор, поэтому обычно выбирают at-least-once и делают обработчик идемпотентным.
Упомяните ребаланс: консюмер отвалился или пришёл новый, и партиции перераспределяются, а обработка на это время встаёт. Отсюда требование не залипать в обработке дольше max.poll.interval.ms, иначе брокер сочтёт консюмера мёртвым, и группа зациклится на ребалансах.
Где спотыкаются
Обещают глобальный порядок в топике. Он есть только внутри партиции и только при ключе.
Считают, что сообщение удаляется после чтения. Kafka хранит лог по времени или по размеру, независимо от чтения.
Не знают про лаг консюмера. Это главная метрика здоровья, и вопрос «как поймёте, что не успеваете» идёт следом почти всегда.