Не менее одного раза разрешает повторную обработку. Для повторяемого внешнего действия отдельно проверяют его идемпотентность или согласование результата с позицией.
Практический смысл
Почему это важно
Подтверждение брокера, сохранённая позиция чтения и списанный платёж — разные события. Если описать их одним словом «доставлено», после сбоя легко повторить списание или пропустить необработанный заказ.
Доказательная часть
Что подтверждено
Kafka рассматривает три модели: не более одного раза допускает потерю при избежании повтора, не менее одного раза допускает повтор, а ровно один раз требует координации фиксируемого результата. Надёжность отправки и обработка потребителем разбираются отдельно.
Граница применимости: Модель семантики доставки Apache Kafka 4.0 при указанных условиях сохранности и обработки.
Сквозная гарантия требует согласовать входное сообщение, позицию потребителя и результат. Транзакции брокера сами по себе не делают атомарным произвольный внешний платёж или запись в другую систему.
Граница применимости: Kafka 4.0, обработка с внешним приёмником; участие приёмника должно быть доказано отдельно.
Подтверждение публикации в Kafka относится к записи на стороне брокера согласно настройкам производителя. Оно не подтверждает, что потребитель уже выполнил и сохранил деловой результат сообщения.
Граница применимости: Kafka 4.0; разные границы публикации и обработки.
Если потребитель сохраняет позицию до обработки сообщения, сбой между этими шагами может пропустить действие после перезапуска: позиция уже указывает, что сообщение пройдено.
Граница применимости: Kafka 4.0, порядок фиксации смещения и обработки в модели не более одного раза.
Если действие выполнено, а позиция ещё не сохранена, сбой допускает повторную обработку того же сообщения. Такой порядок поддерживает модель не менее одного раза, но требует защиты результата от дублей.
Граница применимости: Kafka 4.0, отказ потребителя между эффектом и фиксацией смещения.
Идемпотентный производитель Kafka устраняет дубли своих повторных отправок в журнал брокера. Он не координирует произвольный код потребителя с фиксацией его позиции и внешним результатом.
Граница применимости: Kafka 4.0, различие идемпотентной публикации и сквозной обработки.
Порядок записей Kafka задаётся внутри раздела темы. Гарантия порядка в одном разделе и гарантия отсутствия потерь или повторных эффектов отвечают на разные вопросы; общий порядок между всеми разделами из этого не следует.
Граница применимости: Kafka 4.0, порядок журнала раздела и границы семантики доставки.
При acks=0 производитель Kafka не ждёт ответа брокера на отправку. Передача записи в сетевой буфер считается отправкой, но не доказывает, что брокер её получил. Производитель не узнаёт таким подтверждением о потере записи; настройка retries не исправляет отсутствие ответа.
Граница применимости: Apache Kafka 4.0, нетранзакционный производитель с enable.idempotence=false и acks=0; речь об отправке, не об обработке.
При acks=1 лидер раздела записывает сообщение в свой локальный журнал и отвечает без ожидания копий у последователей. Если после ответа лидер погибнет до репликации записи, подтверждённое сообщение может быть потеряно. Само наличие нескольких назначенных реплик этого окна не закрывает.
Граница применимости: Apache Kafka 4.0, нетранзакционный производитель с enable.idempotence=false и acks=1; отказ лидера до копирования записи.
При acks=all лидер ждёт подтверждения записи от всего текущего ISR — набора синхронизированных реплик раздела, включая себя. Это не обязательно все назначенные реплики и не просто большинство. Подтверждение репликации также не означает обязательный fsync этой записи на каждом накопителе.
Граница применимости: Apache Kafka 4.0, подтверждение репликации журнала при acks=all; состав ISR и модель отказа хранения проверяются отдельно.
При acks=all параметр min.insync.replicas задаёт минимальное число реплик в ISR для успешной записи, включая лидера. Это порог допуска: если ISR меньше него, успешного подтверждения нет. Порог не заменяет число назначенных копий и не приказывает ждать ровно столько ответов — acks=all по-прежнему относится ко всему текущему ISR.
Граница применимости: Apache Kafka 4.0, min.insync.replicas при acks=all; сравнение с неизменным ISR для конкретной отправки и числом назначенных реплик.
Граница терминов
Не путать
Ровно один раз относится к фиксируемому результату в названной области. За пределами транзакционной записи Kafka, например у платёжного API, действует собственный контракт приёмника.
Перед спецификацией
Что проверить
- Нарисуйте последовательность публикации, обработки, внешнего эффекта и фиксации позиции.
- Подпишите, что именно подтверждает каждый ответ в этой последовательности.
- Назовите допустимые потери и повторы на каждом переходе.
- Проверьте сбой непосредственно до и после сохранения позиции.
- Выделите внешние действия, не участвующие в транзакции брокера.
- Укажите, где нужен порядок одного раздела, а где требуется другое согласование.
- Подтвердите защиту делового результата повтором одного и того же сообщения.
- Зафиксируйте acks и enable.idempotence; для acks=0/1 отдельно учтите отсутствие идемпотентного режима и окно потери публикации.
- Сверьте число назначенных реплик, текущий ISR и min.insync.replicas; испытайте потерю лидера и нехватку ISR при выбранном acks.
Открытые основания
Первоисточники
Apache Kafka 4.0 Design
Apache Software Foundation · Apache Kafka 4.0 documentation
Определяет log ordering, producer idempotence, delivery semantics и scope exactly-once processing.
Открыть первоисточникApache Kafka 4.0: Producer Configs
Apache Software Foundation · документация Apache Kafka 4.0, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Сверить transactional.id, связь с enable.idempotence и продолжение транзакционного протокола между сеансами производителя.
Открыть первоисточникHTTP Semantics
Internet Engineering Task Force · RFC 9110, June 2022
Определяет stateless HTTP, origin server, intermediaries, target URI и security significance полей authority и Host.
Открыть первоисточникStripe API Reference: Idempotent requests
Stripe · справочник Stripe API, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Сверить POST с ключом идемпотентности: параметры, сохранение ответа после начала выполнения и удаление ключей не раньше 24 часов.
Открыть первоисточник