Гарантии доставки сообщений в Kafka✈️

В распределенных системах часто приходится выбирать: в каких сценариях можно позволить себе потерю или задержку сообщения, а где важно гарантировать его обработку без повторов.

В Kafka есть несколько уровней гарантий доставки: At Most Once, At Least Once и Exactly Once. От выбора уровня зависит поведение системы при сбоях, баланс между производительностью и надежностью, а также требования к идемпотентности обработки.

Предлагаю разобрать подробно, что означает каждая гарантия и где её целесообразно применять.

✅At Most Once (Не более одного раза)
Это гарантия, при которой сообщение отправляется только один раз, и если оно потерялось, повторной доставки не будет. Такой подход исключает дублирование, но допускает потерю данных.

Как это работает в Kafka?
⭕️Продюсер отправляет сообщение, не дожидаясь подтверждения от брокера (acks=0).
⭕️Брокер не гарантирует сохранение, т.е. сообщение может быть потеряно при сбое.
⭕️Консьюмер может использовать автофиксацию смещений (enable.auto.commit=true), что приведет к автоматическому коммиту даже до успешной обработки данных.

Но! Если консьюмер упадет после чтения сообщения, но до завершения обработки, это сообщение уже не будет доступно для повторной обработки.

Когда использовать?
Подходит для систем, где допустима небольшая потеря данных ради высокой пропускной способности, например:
⭕️сбор событий кликов на веб-сайтах;
⭕️телеметрия с IoT-устройств, где пропуски некритичны.

✅At Least Once (Как минимум один раз)
Гарантирует, что сообщение будет доставлено минимум один раз. Это исключает потерю сообщений, но допускает их дублирование.

Как это работает в Kafka?
⭕️Продюсер отправляет сообщение и ждет подтверждения от брокера (acks=1 или acks=all).
⭕️Консьюмер получает сообщение, обрабатывает его и только после успешной обработки коммитит смещение (manual commit).
⭕️Если консьюмер или процесс обработки упадет после выполнения бизнес-логики, но до комитта, консьюмер сможет запросить то же сообщение повторно.

Чтобы избежать искажений при повторной обработке, операции должны быть идемпотентными, т.е. повторное выполнение не должно изменять результат.

Когда использовать?
Подходит для систем, где потеря данных недопустима, а дублирование можно обработать:
⭕️обработка заказов или событий e-commerce;
⭕️системы мониторинга и логирования;
⭕️ETL-пайплайны, где данные могут быть дедуплицированы на следующем шаге.

✅Exactly Once (Ровно один раз)
Строгая гарантия, при которой сообщение обрабатывается ровно один раз, даже при сбоях или повторных доставках.

Как это работает в Kafka?
⭕️Продюсер включает идемпотентность (enable.idempotence=true), чтобы брокер игнорировал дубликаты сообщений.
⭕️Используются транзакции, объединяющие запись сообщений и фиксацию смещений в одну атомарную операцию.
⭕️После успешной транзакции коммит смещений и запись данных происходят одновременно, что исключает двойную обработку.

Консьюмер должен использовать isolation.level=read_committed, чтобы видеть только зафиксированные транзакции.

Когда использовать?
Идеален для критичных сценариев, где недопустимы ни потери, ни дублирование:
⭕️финансовые расчеты и платежные системы;
⭕️обработка заказов с жесткими гарантиями;
⭕️интеграции, где консистентность данных обязательна.

Зафиксируемся:
⭕️At Most Once - высокая скорость, но есть риск потери данных.
⭕️At Least Once - надежно, но возможны дубликаты.
⭕️Exactly Once - идеальная консистентность, но требует дополнительных усилий и ресурсов.

Источники:
📎Доставка сообщений и гарантии Kafka
📎Гарантированная доставка и хранение данных в Apache Kafka: внутренняя механика

©️что-то на инженерном

Разбираемся с TTL в Clickhouse

Представьте, что вы храните логи пользователей, которые активно используются только в течение первого месяца. Далее эти данные нужны только для редких запросов, и хранить их на быстром и дорогом SSD нецелесообразно.

С помощью TTL (Time-to-Live) в Clickhouse можно настроить автоматический перенос данных старше 30 дней в холодное хранилище, а в быстром доступе оставить агрегированные данные для статистики. Как это сделать расскажу ниже.

Что такое TTL?
TTL задает правило, по которому данные (строки или значения столбцов) автоматически обновляются или удаляются после истечения указанного времени, обычно связанного со столбцом типа Date, DateTime или DateTime64.

Важно: TTL-операции (удаление, обновление) выполняются не мгновенно. Они происходят во время фоновых операций слияния (merges) частей данных. Если части долго не сливаются, устаревшие строки могут сохраняться в таблице дольше указанного срока.

Виды TTL

🟣TTL для столбца задает правило для конкретного поля таблицы: через заданный интервал значение этого столбца заменяется на значение по умолчанию.

Если все значения столбца в части таблицы устарели, Clickhouse удалит этот столбец из части, экономя место. Такой подход полезен для частичной очистки данных, например, удаления чувствительных атрибутов (IP, имя пользователя) через сутки, но сохранения остальной информации.

Например:

ip_address String TTL event_time + INTERVAL 1 DAY;

➡️ Через сутки IP-адрес будет заменен на значение '' (пустую строку).

Или

price Float64 TTL event_time + INTERVAL 1 MONTH GROUP BY product_id SET price = avg(price);

➡️ Через месяц агрегируются данные по product_id.

🟣TTL для таблицы задает условие для удаления всех строк целиком. Например, хранение логов за 30 дней, по истечении которых устаревшие строки полностью удаляются. Это более простое и часто используемое правило управления историей данных.

Например:

TTL event_date + INTERVAL 30 DAY
TO VOLUME 'cold_storage'
DELETE;

➡️ Через 30 дней данные переместятся на том cold_storage, а после дальнейшего срока удалятся.

TTL для таблицы можно комбинировать с TTL для отдельных столбцов. Это удобно при хранении чувствительных данных, которые нужно анонимизировать раньше, чем удалять весь ряд.

Рекомендации по настройке TTL

⭐️Официальной докой рекомендуется всегда включать настройку ttl_only_drop_parts

Параметр ttl_only_drop_parts = 1 означает, что Clickhouse будет удалять только целые части данных, в которых все строки устарели по TTL, вместо попыток частичного удаления строк внутри части.
Это существенно облегчает процесс удаления и снижает нагрузку.

При таком подходе, особенно если партиции совпадают с единицами удаления по TTL (например, по дням), данные из отдельных дней не сливаются между собой, что позволяет эффективно и быстро удалять устаревшие части.

⭐️С включенной ttl_only_drop_parts можно уменьшить значение merge_with_ttl_timeout - интервала между слияниями с удалением устаревших частей, поскольку операция удаления становится проще и занимает меньше ресурсов.

Это снижает влияние TTL на производительность сервера и уменьшает время реакции на удаление устаревших данных.

По умолчанию составляет 14400 секунд (4 часа), но можно безопасно уменьшать, например, до 300-600 секунд.
При слишком низком значении могут возникать частые внеплановые слияния, что увеличит нагрузку на систему.

⭐️Принудительно запустить применение TTL можно командой:

ALTER TABLE my_table MATERIALIZE TTL;

⭐️Для моментального обновления данных без ожидания фоновых слияний можно использовать команду OPTIMIZE ... FINAL, но она тяжелая и не рекомендуется к частому применению.

Подробнее про TTL и больше примеров ➡️ в моей статье на Medium.

©️что-то на инженерном