Apache Kafka для Python-разработчиков: от теории к практике

Основы архитектуры Apache Kafka: топики, партиции, брокеры и журнал событий

Добро пожаловать на курс «Apache Kafka для Python-разработчиков». Если вы привыкли работать с RabbitMQ или Redis Pub/Sub, то Kafka потребует от вас небольшого сдвига парадигмы. Это не просто очередь сообщений, это распределенная платформа потоковой передачи событий.

В этой первой статье мы разберем анатомию Kafka. Мы не будем писать код на Python прямо сейчас — прежде чем импортировать confluent-kafka или aiokafka, нам нужно понять, как эта система хранит и распределяет данные. Без этого понимания вы рискуете создать приложения, которые теряют сообщения или не масштабируются.

Журнал событий (The Log): Сердце Kafka

Чтобы понять Kafka, нужно понять концепцию журнала (Log). В базах данных журнал транзакций (WAL — Write Ahead Log) используется для восстановления состояния. Kafka берет эту идею и делает её центральной архитектурной единицей.

Журнал — это упорядоченная последовательность записей, в которую данные добавляются только в конец (append-only). Записи в журнале неизменяемы. Вы не можете отредактировать сообщение, которое уже записано, вы можете только добавить новое.

Почему это важно для Python-разработчика? Потому что операции записи в конец файла и последовательного чтения — это одни из самых быстрых операций на диске. Это позволяет Kafka обрабатывать миллионы сообщений в секунду даже на обычном оборудовании.

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

Где — это константная временная сложность, означающая, что время выполнения операции добавления сообщения не зависит от текущего размера журнала (количества уже записанных данных).

Топики (Topics)

В Kafka данные организованы в топики. Топик — это логическая категория или имя канала, в который публикуются сообщения. Если проводить аналогию с реляционными базами данных, топик похож на таблицу, а сообщения — на строки.

Примеры названий топиков в реальной системе:

user-registrations

payment-processed

logs-error

Топики в Kafka всегда поддерживают множество подписчиков. Это означает, что одно и то же сообщение, записанное в топик, может быть прочитано несколькими разными сервисами (Consumer Groups) независимо друг от друга.

Партиции (Partitions) и Смещения (Offsets)

Топик — это логическое понятие. Физически топик разбивается на партиции (Partitions). Партиция — это и есть тот самый журнал (Log), о котором мы говорили выше.

!Логическое разделение топика на партиции и структура смещений (offsets).

Зачем нужны партиции?

Масштабируемость: Один сервер (брокер) имеет ограничение по объему диска и пропускной способности. Разбивая топик на партиции, мы можем хранить разные партиции на разных серверах. Это позволяет топику хранить больше данных, чем помещается на один сервер.

Параллелизм: Партиция — это единица параллелизма в Kafka. Если у вас 3 партиции, вы можете запустить 3 консьюмера (читателя) одновременно, каждый из которых будет читать свою партицию.

Смещение (Offset)

Каждое сообщение внутри партиции получает уникальный порядковый идентификатор, который называется смещением (offset).

Важные правила про offset:

Offset уникален только в пределах одной партиции. Сообщение с offset 5 в Партиции 0 и сообщение с offset 5 в Партиции 1 — это разные сообщения.

Порядок сообщений гарантируется только в рамках партиции. Kafka не гарантирует глобальный порядок сообщений во всем топике, если партиций больше одной.

> В Kafka порядок гарантируется только внутри партиции. Если вам нужен строгий порядок всех сообщений (например, операции по банковскому счету), вы должны убедиться, что они попадают в одну и ту же партицию.

Брокеры (Brokers) и Кластер

Физически Kafka — это распределенная система, состоящая из серверов, которые называются брокерами.

Брокер (Broker): Это один сервер Kafka. Он принимает сообщения от продюсеров (Producers), присваивает им смещения (offsets) и сохраняет на диск. Также он обслуживает запросы на чтение от консьюмеров.

Кластер (Cluster): Группа брокеров, работающих вместе.

Каждый брокер в кластере идентифицируется уникальным числовым ID. Когда вы подключаетесь к кластеру из Python-кода, вам обычно достаточно указать адрес хотя бы одного брокера (bootstrap server), и клиентская библиотека автоматически узнает о существовании остальных.

Распределение партиций

Предположим, у нас есть топик с 3 партициями и кластер из 3 брокеров. В идеальном сценарии Kafka распределит их равномерно:

Брокер 1 хранит Партицию 0

Брокер 2 хранит Партицию 1

Брокер 3 хранит Партицию 2

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

Репликация (Replication)

Что произойдет, если Брокер 1 выйдет из строя? Мы потеряем Партицию 0? Чтобы этого не случилось, в Kafka существует механизм репликации.

При создании топика мы указываем фактор репликации (Replication Factor). Обычно он равен 3 для продакшн-систем.

Это значит, что каждая партиция имеет одну Leader-реплику и несколько Follower-реплик.

Leader: Все операции чтения и записи для конкретной партиции всегда идут через лидера.

Follower: Они просто пассивно копируют данные у лидера. Если лидер падает, один из фолловеров автоматически становится новым лидером.

!Распределение лидер-реплик и фолловер-реплик по брокерам для обеспечения отказоустойчивости.

Срок хранения данных (Retention)

В отличие от RabbitMQ, где сообщение удаляется сразу после того, как его прочитали, Kafka хранит сообщения в течение определенного времени (или до достижения определенного размера).

По умолчанию данные хранятся 7 дней (это настраивается параметром log.retention.hours). Это позволяет:

Перечитывать данные заново (Replay), если вы нашли баг в коде обработки.

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

Резюме

Для Python-разработчика Kafka выглядит как бесконечный поток данных, разбитый на файлы.

Топик — имя потока данных.

Партиция — физическая часть топика, обеспечивающая порядок и масштабируемость.

Смещение (Offset) — уникальный номер сообщения в партиции.

Брокер — сервер, хранящий данные.

Репликация — гарантия того, что ваши данные не пропадут при сбое сервера.

В следующей статье мы разберем роли Producer (Продюсера) и Consumer (Консьюмера), и узнаем, как именно Python-приложение взаимодействует с этой архитектурой.

Настройка локального окружения: запуск Kafka и Zookeeper (KRaft) с использованием Docker

В предыдущей статье мы изучили анатомию Kafka: топики, партиции, брокеры и журнал событий. Теперь пришло время перейти от теории к практике. Чтобы писать код на Python, нам нужен работающий кластер Kafka.

Разворачивать Kafka на «голом» железе или виртуальной машине вручную — занятие трудоемкое, требующее установки Java, настройки конфигурационных файлов и управления системными службами. Для разработки мы пойдем по пути наименьшего сопротивления и максимальной воспроизводимости: используем Docker.

В этой статье мы настроим локальное окружение двумя способами:

Классический (Legacy): Kafka + Zookeeper.

Современный (Modern): Kafka в режиме KRaft (без Zookeeper).

Zookeeper vs KRaft: Краткий экскурс

Долгое время (более 10 лет) Kafka не могла работать без Apache Zookeeper. Zookeeper — это отдельная распределенная система для координации и хранения метаданных. Брокеры Kafka использовали Zookeeper, чтобы узнать, кто является лидером партиции, какие брокеры живы, а какие вышли из строя.

Это создавало сложности: * Нужно поддерживать две разные системы. * Zookeeper становился «узким горлышком» при большом количестве партиций.

Начиная с версии 2.8 (и окончательно готовый к продакшену в версии 3.3+), появился режим KRaft (Kafka Raft). В этом режиме Kafka сама управляет своими метаданными, используя алгоритм консенсуса Raft. Это убирает зависимость от Zookeeper.

> Kafka без Zookeeper — это будущее платформы. Однако в существующих проектах вы еще долго будете встречать связку с Zookeeper, поэтому мы разберем оба варианта.

Подготовка

Убедитесь, что у вас установлены: * Docker Engine * Docker Compose

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

Вариант 1: Классическая установка (Kafka + Zookeeper)

В этом сценарии нам нужно запустить два сервиса. Создайте файл docker-compose-zk.yml со следующим содержимым:

Разбор конфигурации

* zookeeper: Слушает порт 2181. Параметр ALLOW_ANONYMOUS_LOGIN=yes разрешает подключение без пароля (допустимо только для локальной разработки). * kafka: * KAFKA_CFG_ZOOKEEPER_CONNECT: Указывает адрес Zookeeper. Обратите внимание, мы используем имя сервиса zookeeper, так как они находятся в одной сети Docker. * depends_on: Гарантирует, что Kafka начнет запускаться только после старта Zookeeper.

Вариант 2: Современная установка (KRaft)

Этот вариант проще, так как требует только одного контейнера. Создайте файл docker-compose.yml:

Алгоритм Raft и Кворум

В режиме KRaft используется алгоритм консенсуса Raft. Для обеспечения надежности в распределенной системе необходимо наличие кворума. Минимальное количество узлов для кворума рассчитывается по формуле:

Где: * — (Quorum) минимальное количество узлов, которые должны быть доступны для принятия решения (например, выбора лидера). * — (Nodes) общее количество узлов-контроллеров в кластере. * — операция округления вниз до целого числа. * — добавление единицы для обеспечения большинства.

Например, если у вас кластер из 3 контроллеров (), то для работы нужно , округляем до 1, плюс 1. Итого . Если упадут 2 узла, кластер остановится. В нашем Docker-примере у нас всего 1 узел, поэтому он сам себе кворум.

Самая большая боль: Listeners и Advertised Listeners

90% проблем при подключении Python-скрипта к Kafka в Docker связано с неправильным пониманием концепции Advertised Listeners.

Kafka — это распределенная система. Когда ваш Python-клиент подключается к брокеру (bootstrap server), брокер отвечает ему: «Привет, я Брокер №1, меня можно найти по адресу X».

Если Kafka работает внутри Docker, у нее есть два адреса:

Внутренний: (например, 172.18.0.3) — доступен другим контейнерам.

Внешний: (например, localhost) — доступен вашему Python-скрипту на хосте.

!Схема работы Advertised Listeners при пробросе портов.

В конфигурации выше мы использовали: * KAFKA_CFG_LISTENERS=PLAINTEXT://:9092 — Kafka слушает порт 9092 на всех интерфейсах внутри контейнера. * KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://localhost:9092 — Kafka говорит клиентам: «Чтобы связаться со мной, стучитесь на localhost:9092».

Если бы мы не указали ADVERTISED_LISTENERS, Kafka могла бы вернуть свой внутренний IP Docker-сети, к которому ваш скрипт с хост-машины не имеет доступа.

Запуск и проверка

Запустим вариант с KRaft:

Проверим, что контейнер запущен:

Вы должны увидеть статус Up. Теперь давайте создадим топик, используя утилиты, встроенные в контейнер Kafka. Это подтвердит, что кластер работает.

Заходим внутрь контейнера:

Создаем топик test-topic:

Примечание: Внутри контейнера мы обращаемся к localhost:9092, потому что для процесса внутри контейнера это локальный адрес.

Отправим сообщение (Producer):

Прочитаем сообщение (Consumer):

Откройте новый терминал, зайдите в контейнер и выполните:

Если вы увидели Hello Kafka from Docker!, поздравляю! Ваше локальное окружение готово.

Полезные UI-инструменты

Работать только через консоль полезно для понимания, но неудобно для ежедневной разработки. Рекомендую добавить в ваш docker-compose.yml один из UI-инструментов, например UI for Apache Kafka (бывший Kafka-UI).

Добавьте этот сервис к вашему Kafka:

После перезапуска (docker-compose up -d) вы сможете зайти в браузере на http://localhost:8080 и увидеть состояние кластера, создавать топики и просматривать сообщения в удобном интерфейсе.

Теперь, когда у нас есть работающий Kafka-брокер, в следующей статье мы наконец-то напишем наш первый Python-скрипт для отправки данных.

Разработка Producer на Python: асинхронная отправка сообщений, ключи партиционирования и гарантии доставки

В предыдущих статьях мы разобрали архитектуру Kafka (топики, партиции, брокеры) и подняли локальный кластер с помощью Docker. Теперь у нас есть работающая инфраструктура, но она бесполезна без данных. Пришло время научиться отправлять сообщения.

В экосистеме Python существует несколько библиотек для работы с Kafka. Самые популярные — это confluent-kafka (обертка над быстрой C-библиотекой librdkafka) и kafka-python (чистый Python). Однако, так как современный Python-бэкенд — это чаще всего асинхронный код (FastAPI, Aiohttp), мы сосредоточимся на библиотеке aiokafka. Она позволяет интегрировать отправку сообщений в asyncio цикл событий, не блокируя основной поток выполнения.

Анатомия сообщения

Прежде чем писать код, важно понять, что именно мы отправляем. Для Kafka сообщение — это не просто строка текста. Это структура, состоящая из нескольких частей:

Key (Ключ): Опциональное поле, определяющее, в какую партицию попадет сообщение.

Value (Значение): Само тело сообщения (payload).

Timestamp (Временная метка): Время создания сообщения.

Headers (Заголовки): Метаданные в формате «ключ-значение» (похоже на HTTP-заголовки).

Самое важное, что нужно запомнить: Kafka работает только с байтами. Брокер не знает, что вы отправляете JSON, XML или строку. Задача продюсера — сериализовать данные в байты перед отправкой.

Установка зависимостей

Для работы нам потребуется библиотека aiokafka. Установим её:

Простейший асинхронный Producer

Напишем скрипт, который подключается к нашему локальному брокеру и отправляет простое текстовое сообщение.

Обратите внимание на метод send_and_wait. Он отправляет сообщение и ждет подтверждения от брокера. В высоконагруженных системах чаще используют просто send (fire-and-forget) в комбинации с батчингом, но для надежности единичных отправок send_and_wait подходит лучше.

Ключи партиционирования (Partitioning Keys)

Одна из самых мощных концепций Kafka — это ключи. Если вы отправляете сообщение без ключа (key=None), продюсер распределяет сообщения по партициям циклически (Round Robin) или использует механизм «липких» партиций (Sticky Partitions), чтобы заполнять батчи эффективнее.

Однако, если вы укажете ключ, Kafka гарантирует, что все сообщения с одинаковым ключом попадут в одну и ту же партицию.

Зачем это нужно?

Вспомните первую лекцию: Kafka гарантирует порядок сообщений только в рамках партиции. Если вы обрабатываете транзакции пользователя, вам критически важно, чтобы событие «Списание средств» обработалось после события «Пополнение счета». Для этого вы должны использовать ID пользователя в качестве ключа.

Математика распределения

Как продюсер решает, в какую партицию отправить сообщение с ключом? Используется формула хеширования:

Где: * — номер выбранной партиции (целое число от 0 до ). * — результат хеш-функции от ключа (обычно используется алгоритм Murmur2). Хеш-функция преобразует произвольные данные в целое число. * — операция взятия остатка от деления на . * — общее количество партиций в топике.

Например, если у нас 3 партиции (), а хеш ключа «user_123» равен 100, то:

Сообщение отправится в Партицию №1.

[VISUALIZATION: Схема распределения сообщений по партициям. Слева изображен Producer, у которого есть три сообщения:

Реализация Consumer на Python: группы потребителей, коммит смещений (offsets) и ребалансировка

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

Сегодня мы займемся написанием Consumer (Потребителя). На первый взгляд, это кажется простой задачей: «читай сообщения из очереди». Однако Kafka — это не просто очередь. Механизмы масштабирования чтения через Consumer Groups (группы потребителей) и управление Offsets (смещениями) делают этот процесс гораздо интереснее и сложнее.

Мы продолжим использовать библиотеку aiokafka для написания асинхронного кода, который идеально вписывается в современные Python-микросервисы.

Группы потребителей (Consumer Groups)

Представьте, что у вас есть топик orders, в который поступает 10 000 заказов в секунду. Ваш Python-скрипт может обработать только 1 000 заказов в секунду. Если вы запустите один скрипт, очередь будет расти бесконечно. Вам нужно масштабирование.

В традиционных очередях (например, RabbitMQ) вы просто добавляете больше воркеров, и очередь сама раздает им задачи. В Kafka этот механизм реализован через Consumer Groups.

Consumer Group — это объединение нескольких консьюмеров, которые совместно читают один и тот же топик. Главное правило Kafka гласит:

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

Это обеспечивает гарантию порядка обработки внутри партиции и предотвращает дублирование обработки одного и того же сообщения разными воркерами одной группы.

Математика масштабирования

Эффективность вашей группы потребителей напрямую зависит от количества партиций в топике. Пусть — количество партиций, а — количество консьюмеров в группе.

Возможны три ситуации:

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

: Идеальный баланс. Каждый консьюмер читает ровно одну партицию. Максимальная эффективность.

: Количество консьюмеров больше количества партиций. Лишние консьюмеры будут простаивать (idle), так как им не достанется ни одной партиции.

Количество простаивающих консьюмеров можно выразить формулой:

Где:

— количество бездействующих потребителей.

— функция выбора максимального значения (исключает отрицательные числа).

— общее число потребителей в группе.

— общее число партиций в топике.

!Визуализация того, как Kafka распределяет партиции, если потребителей меньше, чем партиций.

Ребалансировка (Rebalancing)

Что произойдет, если один из ваших консьюмеров упадет с ошибкой MemoryError? Или если вы решите добавить два новых контейнера с консьюмерами, чтобы справиться с нагрузкой?

Произойдет процесс, называемый ребалансировкой.

Ребалансировка — это процесс перераспределения партиций между живыми членами группы потребителей. Это критически важный механизм для обеспечения отказоустойчивости.

Как это работает?

Один из брокеров назначается координатором группы (Group Coordinator).

Консьюмеры периодически отправляют координатору сигналы жизни (heartbeats).

Если координатор не получает heartbeat от консьюмера в течение времени session.timeout.ms, он считает консьюмера мертвым.

Координатор дает команду всем оставшимся консьюмерам: «Остановите чтение! Мы перераспределяем партиции».

Партиции заново назначаются активным участникам.

> Важно: Во время классической ребалансировки (

Продвинутые техники: сериализация данных (Avro/Protobuf), обработка ошибок и идемпотентность

В предыдущих статьях мы научились создавать базовых продюсеров и консьюмеров, отправлять строки и байты, а также масштабировать чтение с помощью групп потребителей. Однако в реальных продакшн-системах (особенно в финтехе или Big Data) отправка «сырых» JSON-строк — это путь к проблемам. Что если структура данных изменится? Что если сеть моргнет во время отправки платежа? Что делать с сообщением, которое «ломает» ваш парсер?

В этой статье мы перейдем на уровень Senior-разработчика и разберем три кита надежной архитектуры Kafka: строгую типизацию через схемы, гарантию доставки «ровно один раз» (Exactly-Once) и стратегии обработки сбоев.

Проблема «сырых» данных и JSON

Самый популярный формат обмена данными в Python — это JSON. Он удобен, читаем человеком и легко парсится. Но в контексте Kafka у него есть недостатки:

Избыточность: Вы каждый раз передаете названия полей ({"user_id": 123, "name": "Alice"}). Если у вас миллиард сообщений, эти названия полей занимают терабайты места.

Отсутствие контракта: Продюсер может начать отправлять поле age как строку, а консьюмер ожидает число. Это приведет к падению консьюмера.

Решение — использование бинарных форматов сериализации с поддержкой схем, таких как Apache Avro или Protobuf.

Schema Registry и Avro

Apache Avro — это система сериализации данных, где схема (структура данных) хранится отдельно от самих данных. В сообщение попадают только значения, что делает его очень компактным.

Но как консьюмер узнает схему, если она не передается с сообщением? Здесь на сцену выходит Schema Registry.

Schema Registry — это отдельный веб-сервис (обычно работающий рядом с Kafka брокерами), который хранит версии ваших схем.

Алгоритм работы с Schema Registry

Продюсер хочет отправить данные. Он берет схему данных и отправляет её в Schema Registry.

Registry возвращает уникальный ID этой схемы (например, число 42).

Продюсер сериализует данные в бинарный формат Avro и прикрепляет в начало сообщения этот ID (обычно первые 5 байт: 1 байт «магический», 4 байта — ID).

Консьюмер читает сообщение, видит ID=42.

Консьюмер идет в Schema Registry, скачивает схему №42 и с её помощью десериализует байты обратно в Python-объект.

!Диаграмма потока данных при использовании Schema Registry для сериализации сообщений.

Пример на Python (confluent-kafka)

Для работы с Avro лучше всего подходит библиотека confluent-kafka, так как она имеет встроенную поддержку Schema Registry.

Идемпотентность (Idempotence)

Одна из самых сложных проблем в распределенных системах — это дубликаты сообщений.

Представьте сценарий:

Продюсер отправляет сообщение «Списать 100 рублей».

Kafka записывает сообщение и отправляет подтверждение (ACK).

Сеть обрывается, и Продюсер не получает ACK.

Продюсер думает, что сообщение не дошло, и отправляет его снова (Retry).

В Kafka теперь две записи о списании 100 рублей.

Чтобы этого избежать, нужно включить идемпотентность.

> Идемпотентность — свойство операции, при котором повторное выполнение этой операции не меняет результат. .

В Kafka это включается одной настройкой в конфигурации продюсера: enable.idempotence=True (в современных версиях включено по умолчанию).

Как это работает математически?

Когда идемпотентность включена, каждому продюсеру присваивается уникальный идентификатор (PID — Producer ID), а каждому сообщению — порядковый номер (Sequence Number).

Брокер Kafka хранит последний успешный порядковый номер () для каждой пары (PID, Partition). Когда приходит новое сообщение с номером , брокер проверяет условие:

Где: * — порядковый номер (Sequence Number) нового пришедшего сообщения. * — порядковый номер последнего успешно записанного сообщения от этого продюсера в эту партицию. * — шаг инкремента, означающий, что сообщение является следующим строго по порядку.

Если , брокер понимает, что это дубликат, и просто игнорирует его, но отправляет продюсеру успешный ACK. Если , значит, какие-то сообщения были потеряны в пути, и брокер вернет ошибку нарушения порядка.

Обработка ошибок и Dead Letter Queue (DLQ)

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

Если вы просто выбросите исключение в цикле обработки, консьюмер остановится, и обработка всего топика встанет. Это недопустимо.

Паттерн Dead Letter Queue (DLQ)

DLQ (Очередь мертвых писем) — это специальный топик Kafka, куда консьюмер отправляет сообщения, которые он не смог обработать после нескольких попыток.

Алгоритм надежного консьюмера:

Прочитать сообщение.

Попытаться обработать.

Если ошибка временная (например, БД недоступна) — повторить (Retry).

Если ошибка постоянная (например, неверный формат данных) или лимит повторов исчерпан — отправить сообщение в топик my-service-dlq и сделать commit смещения в основном топике.

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

Стратегия повторов (Retry Backoff)

Не стоит повторять попытку мгновенно. Если база данных упала, 1000 запросов в секунду только усугубят ситуацию. Используйте экспоненциальную задержку (Exponential Backoff).

Формула расчета времени ожидания:

Где: * — время ожидания перед следующей попыткой (в секундах). * — функция выбора минимального значения, ограничивающая время ожидания верхним пределом. * — максимальное время ожидания (например, 60 секунд). * — начальное время ожидания (например, 1 секунда). * — номер текущей попытки (1, 2, 3...).

Пример: 1с, 2с, 4с, 8с, 16с... Это дает системе время на восстановление.

Резюме

Переход от «Hello World» к продакшн-системе на Kafka требует внедрения строгих инженерных практик:

Сериализация: Используйте Avro или Protobuf вместе со Schema Registry для экономии трафика и защиты от поломки контрактов данных.

Идемпотентность: Включайте enable.idempotence=True на продюсере, чтобы математически гарантировать отсутствие дубликатов ().

Обработка ошибок: Никогда не блокируйте консьюмер навечно. Используйте стратегии Retry с экспоненциальной задержкой и откладывайте проблемные сообщения в DLQ.

Эти техники делают ваши Python-микросервисы устойчивыми к сбоям сети, ошибкам в данных и перезапускам.