28:00 Для чего топик retry? сами же сказали, что сообщение проблемное. Какие могут быть кейсы, что сначала не обработалось, а потом вдруг обработалось? Почему не сразу DLQ? 2.DLQ не обязательно ручной разбор, может быть приложение Обработчик ошибок. 3.Зачем сами сообщения пересылать в DLQ топик? достаточно topic-partition, offset сообщения. По нему можно вычитать. 4.30:00 зачем поломанные сообщения постоянно гонять по сети? Что если по каким то причинам сообщение все равно не может быть обработано, так и будет по кругу летать?

@user-nw5mh3re3t

3 ай бұрын

1. Если сообщение проблемное и у вас ошибка, которая например говорит, что сообщение не проходит по json схеме, то в таком случае нет смысла класть в retry, можно сразу в DLQ. Какой может быть кейс когда сообщение не обработалось, а потом обработалось - может к примеру быть недоступна база данных. Может быть много кейсов, почему такое случается, например ночные работы на проме, неудачно подключили выгрузку из БД в корпоративное хранилище, либо «слетел» план какого нибудь критичного sql запроса (у нас в этом приложении много сложных и высоконагруженных sql запросов), либо просто решили переехать на другую бд, либо по какой то причине упала репликация через patroni. После восстановления доступности сообщения из retry топика будут обработаны автоматически. 2. DLQ не обязательно ручной разбор. Если есть время и возможности, можно сделать как вы говорите. Тут есть много вариантов, как можно поступить, все зависит от того, на сколько вы готовы тратить время вашей команды (или команд) на автоматизацию и упрощение этого процесса. 3. Вы не всегда являетесь владельцем топика, из которого читаете данные, если работаете в крупной организации. Может быть такое, что вы например один из 20 его потребителей, поэтому вы не можете просто прийти и переделать этот топик как вам удобно. На мой взгляд это правильно, в этом же и фишка кафки - один или несколько поставщиков данных и много потребителей, кому интересны эти данные, те и подключаются к этому топику. Плюс таких топиков (из которых вы читаете) может быть несколько. Поэтому одним из преимуществ идеи с топиками retry и DLQ является то, что у вас единая логика работы с ошибками и вы не зависите от поставщиков и источников данных. Если же ваш вопрос про чтение из retry топика, который вы создаете сами, то возможно и можно применить вашу стратегию, надо только поподробней в ней разобраться, интересно как она будет работать в условиях что у нас несколько consumer на разных кластерах, объединенных в consumer group и читающих данный топик. 4. Частично ответил на ваш вопрос в пункте 1 - очень удобно, что работоспособность после инфраструктурных проблем восстанавливается автоматически. Стоит ли ради этого во время таких проблем гонять сообщения по сети - вопрос философский). Мне кажется, почему бы и нет, если грамотно ограничить скорость чтения из retry топика. Что же касается сообщений, которые некорректны сами по себе - именно в нашей реализации сделано так, что какое бы сообщение не было некорректное, оно в любом случае будет записано в БД в специальном ошибочном статусе, а DLQ топика нет вообще. Мы пробовали для теста (на тестовых стендах) даже невозможные кейсы - отправляли в кафку вместо json кучу нечитаемых символов, и такое сообщение все равно обрабатывалось и записывалось в специальном ошибочном статусе. Поэтому сообщений, которые до бесконечности летают туда сюда по сети, у нас нет.

32:30 1.Patroni просто мастер-слейв? синх или асинх репликация? Это важно. 2.Кафка разделена между DC, как? Растянутая или зеркалированная? 3.Сколько ZooKeeper? 4.Используется ли KRaft и почему да/нет?

@user-nw5mh3re3t

3 ай бұрын

1. Master-standby синхрон. synchronous_mode: true synchronous_mode_strict: false 2,3. Система подключена к разным конфигурациям Кафка кластеров. Для внутренних задач используется кластер конфигурацией 3 ЦОД по 2 сервера Кафка с настроенным rack awareness и 5 zookeeper. Без зеркалирования. 4. Пока нет, т.к. надо поднимать версию, это дело времени.