Комментарии 14
Былью, в смысле от Кафки в итоге отказались?
Так как параметр retries имеет значение по умолчанию Integer.MAX_VALUE (2147483647), количество повторных отправок сообщения можно регулировать, меняя только delivery.timeout.ms.
Кто-то мешает задать другое значение?
Кмк по этой теме нелишним будет упоминание паттерна 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 стала былью