Гарантии: at-most-once и at-least-once

У консьюмера есть два шага на каждое событие: подтвердить позицию — CommitMessages — и выполнить работу — обработчик. Порядок шагов и есть гарантия. Коммит до обработки даёт at-most-once: событие считается доставленным в момент подтверждения, и падение после коммита теряет его навсегда, зато дубликаты невозможны. Обработка до коммита даёт at-least-once: событие считается доставленным после успешной работы, падение возвращает его к следующему запуску, зато окно между работой и подтверждением оставляет шанс дубликата. Названия честные: «не более одного раза» и «не менее одного раза» — прочие обещания брокер не даёт. Из формулы следуют и привычные паттерны: at least once kafka требует идемпотентности обработчика — умения пережить повтор, at-most-once требует готовности терять. Нет варианта без цены: окно между шагами нельзя закрыть, его можно только сместить — к потерям или к дубликатам. Проверьте свой текущий код: где между FetchMessage и CommitMessages стоит обработчик — та гарантия у вас и работает, независимо от того, задумывали ли вы её.

Контракт «не более одного раза» уместен там, где событие дёшево, а повтор вреден. Телеметрия и метрики: потеря точки на графике не замечается, а двойной инкремент искажает статистику. Логи и нотификации с дедупликацией на стороне приёмника. Потоки, где событие — сигнал, а не факт: «пересчитай кэш» дважды — то же самое, что один раз. И особый случай — потоки, где дубликат дороже потери не потому, что данные дешёвые, а потому, что приёмник сам идемпотентен: событие несёт полный снимок состояния, и повторная обработка записывает то же значение. Заметьте, что ReadMessage с группой из восьмого урока — это уже at-most-once: самокоммит внутри вызова подтверждает позицию до вашей обработки, о чём документация предупреждает прямо. Для быстрых и безопасных обработчиков это компактная реализация контракта без лишних строк. Опасность не в API, а в недоговорённости: когда автор кода не формулировал гарантию, at-most-once оказывается на платежах — и потери всплывают в дежурном чате. Граница легко проверяется вопросом к владельцу потока: что произойдёт, если это событие никогда не случится? Если ответ «ничего страшного» — контракт ваш.

Поменяйте два вызова местами — и контракт перевернётся. Fetch, обработка, коммит: подтверждение фиксирует только сделанную работу, падение возвращает события к следующему запуску. Цена — окно дубликатов: процесс, умерший между успешной обработкой и коммитом, оставляет событие незакрытым, и после рестарта оно приедет снова. Поэтому at least once kafka живёт в паре с идемпотентностью — умением обработчика выдать один и тот же результат на повтор. Практика простая: у события есть уникальный идентификатор — ключ сообщения или поле в Value, — и обработчик перед дорогим действием проверяет, не выполнялось ли оно уже. Хранителем проверки становится ближайшее надёжное хранилище: уникальный индекс в Postgres, набор Redis, таблица обработанных событий. Списание по заказу становится upsert-ом с ключом события вместо слепого INSERT, письмо — записью в таблице отправок с уникальным ограничением. Ключ дедупликации не обязан жить в Value: kafka.Message несёт Headers, и идемпотентный маркер удобно ехать там, рядом с трассировочными, не смешиваясь с полезной нагрузкой. Заметьте, что дубликаты — не авария, а штатный режим контракта: они приходят при каждом рестарте и ребалансе, и система должна их глотать молча, а не писать в дежурный чат.

Вопрос «а как сделать ровно один раз» приходит первым, и честный ответ — из консьюмера такого примитива не собрать. Проблема фундаментальна: обработка — это ваш внешний эффект, коммит — запись на брокере, и атомарной транзакции между ними не существует; падение между шагами всегда оставляет либо потерю, либо дубль. Протокол Kafka умеет транзакции продюсера, и консьюмер может читать только закоммиченные транзакционные записи: в kafka-go это поле IsolationLevel в ReaderConfig, где ReadUncommitted — значение по умолчанию, а ReadCommitted фильтрует незакрытые транзакции. Но это о целостности чтения чужих транзакций, а не о exactly-once обработки. Рабочая альтернатива — эмуляция: идемпотентный обработчик на at-least-once плюс хранитель факта выполнения. Там, где нужен строгий exactly-once на внешнем эффекте, факт совершения действия записывают в ту же базу, что и бизнес-результат, в одной транзакции: списание и запись «событие 42 обработано» атомарны средствами Postgres, а Kafka остаётся каналом доставки с повторами. Так exactly-once переносится из брокера, где он недостижим, в транзакцию базы, где он честный.

Решение сводится к двум числам: во сколько обойдётся потерянное событие и во сколько — повторное. Платежи, биллинг, аудит — потеря необратима и дорога, повтор отвешивается идемпотентностью: at-least-once и барьер на границе системы. Телеметрия, счётчики, логи — потеря незаметна, повтор искажает данные: at-most-once без лишних записей в хранилище. Между ними — серая зона событий, где оба исхода терпимы, и там решает простота: самокоммит ReadMessage короче ручной схемы на два вызова. Проверяйте решение тестом на смерть: убейте процесс между каждой парой строк кода и выпишите, что произойдёт с событием — таблица ниже собрана ровно по этой процедуре. И помните, что гарантия чтения не сильнее гарантии записи: WriteMessages с Async: true даст at-most-once ещё на входе в брокер — десятый урок покажет цену этого выбора. И не забудьте продюсерскую сторону: гарантия консьюмера ничего не стоит, если продюсер молча теряет сообщения на отправке, — ретраи и acks продюсера разбирает двенадцатый урок, а полная картина потерь от Writer до обработчика собирается в уроке про грабли продакшена.