Comments 11
Штука интересная, но чувствую, что в ногу выстрелить очень легко. Евенты могут зациклить друг друга. Как в больших проектах этого избегают?
Чтобы избежать повторной обработки одного и того же сообщения, каждому событию назначается уникальный идентификатор. На стороне обработчика выполняется проверка по этому идентификатору — обычно через быстрое (горячее) хранилище, например Redis — было ли сообщение уже обработано.
Важно учитывать, что риск зацикливания может возникнуть при использовании политик доставки At Most Once и At Least Once. В таких случаях ответственность за обеспечение идемпотентности и защиту от повторной генерации событий ложится на саму бизнес-логику приложения.
Извините, но эти хорошо структурированные списочки вызывают смутные сомненья... — у меня одного?
Exactly once невозможна. Почитайте про задачу "Двух генералов" https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/
Здравствуйте, спасибо за статью. Просматривал листинги и пытался сам себе ответить на вопрос, "а зачем тут фастапи то"?
Идея в целом понятна, но в таком случае может лучше взять faust-streaming?
Я думаю эта ссылка обязана быть в контексте такой статьи: https://github.com/ag2ai/faststream/
Статья крутая. Пару важных нюансов: 1. шаблоном будет не publisher-subscriber а producer-consumer. Тут важно само отношение между субъектами. Consumer сам ходит за сообщения, которые где-толежат, а сабскрайберу их приносят. 2. Сама по себе кафка не поддерживает exactly once. Правильно будет сказать что поддерживается только в том случае если вы ответы публикуете обратно в кафку.
Если бы еще рассмотрели вопросы про задержавшиеся сообщения и порядок сообщений то статья была бы на уровня три выше.
Для тех, кто знаком с FastAPI, есть удобный фреймворк для работы с очередями FastStream - https://faststream.airt.ai/latest/faststream/
Есть возможность использовать не только Kafka, но и Redis, RabbitMQ, Nats и тд
Event-Driven архитектура на FastAPI: через паттерн Pub/Sub