Idempotent Consumer

Сценарий 1: Сбой после обработки, до ack
  1. Consumer получил сообщение
  2. Обработал (записал в БД)
  3. Сбой перед отправкой ack
  4. Сообщение возвращается в очередь
  5. Другой consumer получает то же сообщение
  6. Обрабатывает снова → дубликат

Сценарий 2: Сбой сети
  1. Consumer получил сообщение
  2. Обработал
  3. Отправил ack
  4. Ack потерялся в сети
  5. Брокер не получил ack
  6. Отправляет сообщение снова → дубликат

Сценарий 3: Retry от производителя
  1. Producer отправил сообщение
  2. Не получил подтверждение
  3. Отправил снова (с тем же idempotency key)
  4. Брокер получил два одинаковых сообщения

Exactly-Once:
  - Брокер гарантирует, что сообщение будет доставлено ровно один раз
  - Сложно, дорого, не все брокеры поддерживают

At-Least-Once + Idempotent Consumer:
  - Брокер гарантирует, что сообщение не потеряется (может быть доставлено несколько раз)
  - Consumer гарантирует, что повторная обработка безопасна
  - Проще, дешевле, работает везде

Алгоритм:
  1. Получить сообщение с уникальным идентификатором (idempotency key)
  2. Проверить в хранилище: ключ уже обработан?
  3. Если да → пропустить обработку, подтвердить
  4. Если нет → обработать, сохранить ключ, подтвердить

Таблица processed_events:
  - idempotency_key (PRIMARY KEY)
  - processed_at (timestamp)
  - result (json)

Алгоритм:
  - BEGIN TRANSACTION
  - SELECT * FROM processed_events WHERE idempotency_key = ?
  - Если есть → COMMIT (ничего не делаем)
  - Если нет → INSERT INTO processed_events...
  - Выполнить бизнес-логику
  - COMMIT

Преимущества: надёжно, транзакционно
Недостатки: медленно, нагрузка на БД

Команда: SETNX idempotency_key "processed" EX 86400

Алгоритм:
  - result = SETNX(key, "processed", TTL=24h)
  - Если result == 0 → ключ уже есть → пропускаем
  - Если result == 1 → ключа не было → обрабатываем

Преимущества: быстро
Недостатки: ключи могут потеряться (Redis не персистентен)

Kafka транзакции:
  - Producer: send(record) в транзакции
  - Consumer: read_committed (видит только зафиксированные)
  - Idempotent producer: enable.idempotence=true

Преимущества: встроено в брокер
Недостатки: только в Kafka, снижает производительность

Заголовки сообщения:
  - idempotency-key: 123e4567-e89b-12d3-a456-426614174000

Уникальность:
  - Разные операции → разные ключи
  - Одна операция → один ключ (даже при повторах)

Предсказуемость:
  - Клиент может сгенерировать ключ до отправки
  - При повторной отправке ключ тот же

Примеры:
  - UUID (v4): 123e4567-e89b-12d3-a456-426614174000
  - Составной: order-123-creation-attempt-1

Время хранения:
  - Не меньше, чем максимальное время между повторными попытками
  - Обычно 24 часа или 7 дней

Почему не вечно:
  - Ключей становится слишком много
  - Старые операции уже не повторятся

1. Получено сообщение "платёж 1000 рублей"
2. Проверить баланс
3. Списать 1000 рублей
4. Отправить подтверждение

Проблема:
  - Сообщение пришло дважды
  - Деньги списались дважды
  - Клиент потерял 1000 рублей

1. Получено сообщение с idempotency_key="pay-123"
2. SELECT * FROM payments WHERE idempotency_key = "pay-123"
3. Запись не найдена
4. Проверить баланс
5. Списать 1000 рублей
6. INSERT INTO payments (idempotency_key, amount, status) VALUES (...)
7. Отправить подтверждение

Если сообщение пришло второй раз:
  1. Получено сообщение с тем же ключом
  2. SELECT * FROM payments WHERE idempotency_key = "pay-123"
  3. Запись найдена
  4. Пропустить обработку
  5. Отправить подтверждение (уже было)

Подход:
  - Идемпотентность на стороне consumer
  - Хранилище: БД или Redis
  - Уникальный идентификатор в заголовках сообщения

Подход:
  - enable.idempotence=true (producer)
  - transactional API
  - Consumer: read_committed

Ограничения:
  - Идемпотентность в пределах одной партиции
  - Для глобальной идемпотентности нужно своё хранилище

Подход:
  - FIFO очередь (exactly-once в пределах очереди)
  - Или idempotent consumer с DynamoDB

FIFO очередь:
  - deduplicationId (аналог idempotency key)
  - Гарантирует, что сообщение с тем же ID не будет доставлено дважды

Ключи накапливаются:
  - 1 млн операций в день
  - Через год → 365 млн записей
  - Хранилище растёт бесконечно

TTL (Time To Live):
  - Хранить ключи 24 часа (или 7 дней)
  - Автоматическое удаление старых записей

Redis:
  - EXPIRE key 86400

База данных:
  - Поле created_at
  - Периодическая очистка: DELETE WHERE created_at < NOW() - INTERVAL '7 days'

Примеры неидемпотентных операций:
  - Отправка email (повтор отправит два письма)
  - Инкремент счётчика (повтор увеличит дважды)
  - Добавление в лог (повтор добавит две записи)

Что делать:
  - Сделать операцию идемпотентной по ключу
  - Email: проверять, отправляли ли уже это письмо
  - Счётчик: хранить не счётчик, а список событий (event sourcing)
  - Лог: добавить idempotency key в запись

Задача: Система платежей

Настройка:
  - Брокер: RabbitMQ
  - Гарантии: at-least-once (publisher confirms + manual ack)
  - Хранилище ключей: PostgreSQL

Очередь: payments.queue

Consumer:
  1. Получить сообщение с idempotency_key
  2. BEGIN;
  3. SELECT 1 FROM processed_payments WHERE idempotency_key = ? FOR UPDATE
  4. Если запись есть:
       COMMIT;
       ack();
       return
  5. INSERT INTO processed_payments (idempotency_key) VALUES (?)
  6. Выполнить платёж (списание денег)
  7. INSERT INTO payments (idempotency_key, amount, status) VALUES (...)
  8. COMMIT;
  9. ack();

TTL: 30 дней (очистка по расписанию)

Результат:
  - Платёж не может быть обработан дважды
  - Даже если сообщение пришло повторно
  - Даже если consumer упал после платежа, но до ack