Фиксация позиции перед действием допускает пропуск; фиксация после действия допускает повтор. Безопасность делового результата не выводится только из порядка этих двух шагов.
Почему это важно
Сбой после списания, но до сохранения позиции — обычное окно повтора. Результат нужно защищать на стороне действия, а позицию продвигать только за действительно обработанные записи.
Что подтверждено
Модель не менее одного раза допускает повтор сообщения, когда его успешная обработка не подтверждена. Это свойство протокола при сбоях, а не само по себе доказательство неисправности брокера.
Граница применимости: Kafka 4.0; сообщение сохраняется и потребитель может продолжить обработку согласно контракту системы.
Если потребитель выполнил действие и упал до сохранения позиции, после перезапуска то же сообщение может быть обработано снова. При внешнем списании это создаёт риск второго списания.
Граница применимости: Kafka 4.0, обработка перед фиксацией смещения; внешний эффект не включён в общую атомарную запись.
Фиксация позиции до успешного действия закрывает окно повтора ценой другого риска: сбой может оставить действие невыполненным, а сообщение — уже пройденным. Такая перестановка не сохраняет гарантию не менее одного раза для обработки.
Граница применимости: Kafka 4.0; сравнение порядка обработки и фиксации смещения.
Повтор отправки после потерянного подтверждения тоже может создать дубль, если производитель не использует подходящую идемпотентную публикацию. Защита только от перезапуска потребителя не охватывает этот источник повторов.
Граница применимости: Kafka 4.0, неоднозначный результат публикации и идемпотентный производитель.
Сохранение результата и входной позиции в одной транзакции внешней системы позволяет согласовать обработанное действие с продвижением чтения. Две независимые записи — «эффект» и «уже обработано» — оставляют окно сбоя между ними.
Граница применимости: Kafka 4.0, кооперация внешнего приёмника с потребителем; приёмник должен действительно поддерживать общую атомарную запись.
Идемпотентное действие может выполняться повторно без нового предполагаемого эффекта. Поэтому повторная доставка сама по себе ещё не означает повторное деловое изменение, но идемпотентность конкретного действия нужно установить.
Граница применимости: Сопоставление модели доставки Kafka 4.0 и определения идемпотентности RFC 9110.
Если повтор сообщения вызывает Stripe API, одного прежнего ключа недостаточно после удаления его сохранённого результата. Срок возможного повтора сообщения нужно сопоставить со сроком защиты у платёжного приёмника.
Граница применимости: Сопоставление повторной обработки Kafka и POST-запросов Stripe с ключом идемпотентности; после границы хранения ключа требуется сверка результата.
В конфигурации потребителя Kafka enable.auto.commit по умолчанию равен true: позиции периодически фиксируются в Kafka в фоновом порядке. auto.commit.interval.ms задаёт интервал такой фиксации, по умолчанию 5000 мс.
Граница применимости: Конфигурация потребителя Apache Kafka 4.0; интервал не объявлен точным сроком срабатывания независимо от прогресса клиентского цикла.
enable.auto.commit=false отключает автоматическую фиксацию позиций, но не делает внешний эффект и ручной commit одной транзакцией. Сбой после платежа до успешного commit допускает повтор; commit до завершения платежа допускает пропуск. Уменьшение auto.commit.interval.ms в автоматическом режиме также не устраняет разрыв между этими независимыми действиями.
Граница применимости: Вывод из конфигурации потребителя и порядка обработки Kafka 4.0: внешний платёж и позиция не участвуют в общей атомарной записи.
Не путать
Не менее одного раза допускает повтор обработки. Ровно один раз связывает фиксируемый результат с входной позицией в заданной области; внешнее действие нуждается в собственном доказанном участии.
Что проверить
- Проверьте сохранность сообщения и условия возобновления потребителя.
- Воспроизведите сбой после действия и до фиксации позиции.
- Убедитесь, что позиция не проходит мимо ещё не завершённого действия.
- Проверьте потерю подтверждения публикации отдельно от сбоя потребителя.
- Свяжите результат с отметкой обработки атомарно либо докажите идемпотентность действия.
- Сопоставьте максимальный срок повтора со сроком хранения ключа приёмника.
- После неоднозначного платежа проверяйте исход до создания нового намерения списания.
- Проверьте enable.auto.commit и auto.commit.interval.ms вместе с продолжением poll во время асинхронной обработки; фиксируйте фактическую позицию, а не предполагайте срабатывание по одному таймеру.
- При ручной фиксации проверяйте её исход и обе стороны окна сбоя между внешним эффектом и commit; отключение автоматики не доказывает обработку ровно один раз.
Первоисточники
Apache Kafka 4.0 Design
Apache Software Foundation · Apache Kafka 4.0 documentation
Определяет log ordering, producer idempotence, delivery semantics и scope exactly-once processing.
Открыть первоисточник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 часов.
Открыть первоисточникApache Kafka 4.0: Consumer Configs
Apache Software Foundation · документация Apache Kafka 4.0, страница открыта 7 сентября 2026 года
Открыт редактором 7 сентября 2026 года, заголовок документа сверен. Сверить isolation.level=read_committed, last stable offset и задержку чтения из-за незавершённых транзакций.
Открыть первоисточник