На странице собраны вопросы по Kafka — от проверки базовых принципов до практического применения и архитектурных решений. В подборке чаще встречаются темы: kafka, backend, api.
Kafka не гарантирует общий порядок между разными партициями и топиками. При отсутствии связанной записи событие лучше надёжно отложить и повторить после зависимости, а не терять или игнорировать FK.
Kafka делает акцент на сохранённом журнале событий, партициях и offsets, RabbitMQ — на маршрутизации и доставке через очереди. Это различие модели, а не правило «один быстрый, другой надёжный».
Для PostgreSQL Debezium получает поток через logical decoding и replication slot, преобразует изменения строк в события и передаёт их в Kafka. Обычно сначала выполняется согласованный начальный snapshot.
Покажите жизненный цикл заявки: событие входа, обработку каждым сервисом, промежуточные состояния и финальное решение. Конкретные топики и правила одобрения нужно брать из реального проекта.
Kafka прежде всего хранит распределённый журнал с offsets и повторным чтением, а RabbitMQ предоставляет маршрутизацию и очереди сообщений. Выбор зависит от модели потребления и требований, не только от скорости.
Если commit offset выполнен до надёжной обработки, обычное продолжение группы пропустит сообщение. При сохранённом логе можно переобработать нужный диапазон offsets, контролируя дубликаты.
Не подтверждайте предположение о FastAPI без фактов. Опишите прежний поток запросов и данных, а затем объясните, что изменилось после добавления событий и Kafka.
Типовой поток: склад публикует изменения в Kafka, каталог обновляет модель чтения и кеш Redis, а frontend получает данные через API. Реальная схема и формула популярности зависят от проекта.
RabbitMQ часто удобен для очередей рабочих задач и гибкой маршрутизации, Kafka — для сохраняемого потока событий с независимыми потребителями и replay. Выбор зависит от требований, а не только объёма.
Kafka хранит события в распределённом журнале, позволяя независимым потребителям читать и перечитывать поток. Её сильные стороны — масштабирование потока и replay, цена — эксплуатация и сложность контрактов.
Push отправляет данные потребителю по инициативе брокера, pull позволяет потребителю запрашивать порции. Управление потоком нужно в обоих случаях; сама модель не определяет весь расход памяти брокера.
В обычном топике Kafka чтение всеми группами само по себе не удаляет сообщение. Его хранение определяется политикой retention или compaction, независимо от offsets потребителей.