Comments 14
Былью — в смысле кафка (несмотря на всю изначальную боль) в итоге воплотилась в жизнь.
Нет, мы продолжаем работать с Кафкой. В заголовке хотелось обыграть схожесть слов бЫль и бОль, так как наш путь к гарантированной доставке был непростым.
Так как параметр retries имеет значение по умолчанию Integer.MAX_VALUE (2147483647), количество повторных отправок сообщения можно регулировать, меняя только delivery.timeout.ms.

Кто-то мешает задать другое значение?
Если Вы имеете ввиду другое значение для параметра retries, то да, его можно задать. Но, как и отмечено в статье, можно регулировать количество повторных отправок значением параметра delivery.timeout.ms. В некоторых случаях это будет удобнее за счет того, что Producer сделает максимальное число повторных отправок за указанный интервал времени и Вам не нужно будет подбирать значение для retries самостоятельно.

Кмк по этой теме нелишним будет упоминание паттерна Transaction Outbox и самостоятельного управления оффсетами на стороне Consumer

Но ведь это exactly once запись в кафку, как вы гарантируете exactly once чтение? В статье в целом мало информации о консьюмере, почему в нем нельзя было обеспечить exactly once по тому же ключу?
Также в случае acks = -1 кластер становится фактически недоступен при выхода из строя одной из нод, как вы с этим боретесь?

Спасибо за интересные вопросы! Попробую ответить на них по порядку.

Но ведь это exactly once запись в кафку, как вы гарантируете exactly once чтение? В статье в целом мало информации о консьюмере, почему в нем нельзя было обеспечить exactly once по тому же ключу?

Мы пытались выжать максимум из средств, которые предоставляет сама Кафка, поэтому на Consumer в первую очередь настраиваем isolation.level = read_committed. Этого достаточно для внутренней коммуникации внутри нашей системы.
Если я правильно понял часть вопроса с ключем, то такое поведение можно получить используя какой-либо внешний источник для хранения данных, с которым будет работать сервис, читающий из Кафки. Этот сервис будет считывать сообщение из топика, проверять наличие полученного ключа во внешнем источнике данных и обрабатывать сообщение, если полученный ключ уникальный. Хотя, это будет больше похоже на идемпотентную обработку данных. В нашей системе мы используем похожий механизм на граничных сервисах, так как не можем управлять Producer-ами сторонних систем.

Также в случае acks = -1 кластер становится фактически недоступен при выхода из строя одной из нод, как вы с этим боретесь?

Наша команда не занимается управлением кластера Кафки, но я попробую ответить на Ваш вопрос. Сочетание количества брокеров, фактора репликации и значения параметра min.insync.replicas нашего кластера позволяют нам пережить до 3х падений узлов. Вы можете подробнее разобраться в том, как кластер переживает падение узлов прочитав отличную статью от коллег. Кроме того, у нас настроен мониторинг статусов партиций и ответственные за кластер люди смогут во время вмешаться.

Выжать максимум — это не совсем достичь "exactly once") При ребалансировке consumer group незакоммиченные оффсеты будут вычитаны другим назначенным потребителем группы. Это можно, в принципе, порешать кастомным ассайнором, но оно же убъет отказоустойчивость. Вся бОль распределенных систем в том, что не существует гарантированной одноразовой доставки и жесткой целостности данных. Kafka в данном случае не нарушает законов.

Если честно, то от статьи ожидал большего. По сути, это пересказ документации по настройке exactly-once. Хотелось бы услышать больше, как Kafka справляется с ролью mq, для которой она подходит всётаки ограниченно. Какие были проблемы и решения. Может быть пришлость менять архитектуру или подходы.


Насчёт exactly-once в Kafka мои личные наблюдения, что сильно полагаться на него не стоит. Приложения с поддержкой at-least-once семантикой в итоге имеют меньше проблем и можно добиться куда более высокой производительности. Exactly-once имеет смысл при процессинге kafka — > kafka да и то далеко не всегда.

Зависит от того паттерна, с которым используют MQ. Заменять очередь на персистентный лог стоит разве что при наличии более, чем одного потребителя из очереди сообщений. Иначе это превращается в лютый кэш транспортного уровня с большими накладными расходами (инфраструктура и управление) на его организацию.

Народ, кто-то имел опыт использования кластера kafka на распределенных ДЦ?
Only those users with full accounts are able to leave comments. Log in, please.