Три года назад я свято верил, что Kafka — это волшебная труба, в которую можно засунуть любую задачу и забыть о проблемах. Достаточно накидать продюсеров, поднять пару консьюмеров, и данные сами потекут куда надо, быстро и надёжно. Первый серьёзный продюсерный контур на реальной нагрузке снял с меня эту иллюзию примерно за неделю. Сегодня хочу честно рассказать, где я спотыкался, что в итоге помогло и что я советую тем, кто только заходит в мир событийной архитектуры.
Начну с дублей, потому что именно они бьют больнее всего. В Kafka по умолчанию нет никакой магии exactly-once на уровне всей вашей системы, и это надо принять как аксиому. Я долго жил в уверенности, что если включить идемпотентного продюсера и транзакции, то проблема исчезнет. Она не исчезает: сеть рвётся после того, как брокер записал сообщение, но до того, как продюсер получил подтверждение, и вы честно отправляете его повторно. Спасает не вера в настройки, а идемпотентная обработка на стороне консьюмера: уникальный ключ события, таблица обработанных идентификаторов и вставка с проверкой на дубликат в одной транзакции с бизнес-логикой. Скучно, зато работает.
Второй урок — про порядок и партиции. Я как-то искренне удивился, почему заказы одного клиента иногда обрабатываются не по порядку. Оказалось, ключ партиционирования у меня был случайным, и события одного пользователя разлетались по разным партициям. Порядок гарантируется только внутри партиции, и это не ограничение, а инструмент. Как только я начал осмысленно выбирать ключ, часть странных багов исчезла сама собой. Отдельно скажу про перебалансировку: если консьюмерная группа часто перекидывает партиции между инстансами, вы теряете и порядок, и время. Не давайте консьюмеру умирать по таймауту из-за долгой обработки — выносите тяжёлые операции в отдельный слой.
Третья боль — задержки и лаг. Первое время мы мерили здоровье кластера по количеству сообщений в секунду и радовались графикам. Потом выяснилось, что у одной группы лаг растёт часами, а мы просто не смотрели на него. С тех пор у меня правило: лаг по каждой группе и каждой партиции — это метрика первого класса, рядом с алертами на ошибки. И ещё: задержка бывает разная. Есть та, что копится из-за медленного консьюмера, а есть та, что возникает из-за ретраев и блокировок внутри обработчика. Это совершенно разные болезни, и лечатся они по-разному. Пока не разложишь задержку на составляющие, будешь лечить симптом.
Четвёртый вывод — про ретраи и мёртвые письма. Бесконечные ретраи красивы в теории и разрушительны на практике: одно ядовитое сообщение способно заблокировать всю партицию и остановить поток. У нас такое случилось из-за кривого формата данных от одного старого сервиса. Спаслись тем, что ввели лимит попыток, отдельный топик для проблемных сообщений и обязательный разбор этого топика по расписанию. Мёртвое письмо без разбора — это просто отложенная авария, только вы о ней ещё не знаете.
Пятое, о чём почти никто не думает на старте, — это схема событий и совместимость. Пока сервисов два, можно менять формат когда угодно. Когда их двадцать, любое поле превращается в контракт. Я прошёл через неделю боли, когда один разработчик переименовал поле, а упали три команды, которые об этом не знали. Схему надо версионировать, менять только обратно совместимым способом и держать реестр схем, а не полагаться на память коллег.
Что бы я посоветовал тем, кто сейчас проектирует свою первую событийную систему? Не начинайте с кластера из семи брокеров и сложной топологии. Возьмите минимальную конфигурацию, но сразу заложите три вещи: идемпотентную обработку, осмысленные ключи партиционирования и мониторинг лага. Добавьте разбор мёртвых писем и договоритесь о правилах изменения схем до того, как это понадобится. И честно ответьте себе на вопрос, действительно ли вам нужен Kafka, а не простая очередь задач. Kafka мощная, но она не прощает небрежности — зато когда всё настроено, она держит нагрузку, о которой раньше можно было только мечтать.
А как у вас было с первым знакомством? Расскажите, какая иллюзия про Kafka рассыпалась у вас первой — дубли, порядок, лаг или что-то совсем неожиданное? Очень интересно сравнить опыт и, может быть, собрать из комментариев народный чек-лист для новичков.
Начну с дублей, потому что именно они бьют больнее всего. В Kafka по умолчанию нет никакой магии exactly-once на уровне всей вашей системы, и это надо принять как аксиому. Я долго жил в уверенности, что если включить идемпотентного продюсера и транзакции, то проблема исчезнет. Она не исчезает: сеть рвётся после того, как брокер записал сообщение, но до того, как продюсер получил подтверждение, и вы честно отправляете его повторно. Спасает не вера в настройки, а идемпотентная обработка на стороне консьюмера: уникальный ключ события, таблица обработанных идентификаторов и вставка с проверкой на дубликат в одной транзакции с бизнес-логикой. Скучно, зато работает.
Второй урок — про порядок и партиции. Я как-то искренне удивился, почему заказы одного клиента иногда обрабатываются не по порядку. Оказалось, ключ партиционирования у меня был случайным, и события одного пользователя разлетались по разным партициям. Порядок гарантируется только внутри партиции, и это не ограничение, а инструмент. Как только я начал осмысленно выбирать ключ, часть странных багов исчезла сама собой. Отдельно скажу про перебалансировку: если консьюмерная группа часто перекидывает партиции между инстансами, вы теряете и порядок, и время. Не давайте консьюмеру умирать по таймауту из-за долгой обработки — выносите тяжёлые операции в отдельный слой.
Третья боль — задержки и лаг. Первое время мы мерили здоровье кластера по количеству сообщений в секунду и радовались графикам. Потом выяснилось, что у одной группы лаг растёт часами, а мы просто не смотрели на него. С тех пор у меня правило: лаг по каждой группе и каждой партиции — это метрика первого класса, рядом с алертами на ошибки. И ещё: задержка бывает разная. Есть та, что копится из-за медленного консьюмера, а есть та, что возникает из-за ретраев и блокировок внутри обработчика. Это совершенно разные болезни, и лечатся они по-разному. Пока не разложишь задержку на составляющие, будешь лечить симптом.
Четвёртый вывод — про ретраи и мёртвые письма. Бесконечные ретраи красивы в теории и разрушительны на практике: одно ядовитое сообщение способно заблокировать всю партицию и остановить поток. У нас такое случилось из-за кривого формата данных от одного старого сервиса. Спаслись тем, что ввели лимит попыток, отдельный топик для проблемных сообщений и обязательный разбор этого топика по расписанию. Мёртвое письмо без разбора — это просто отложенная авария, только вы о ней ещё не знаете.
Пятое, о чём почти никто не думает на старте, — это схема событий и совместимость. Пока сервисов два, можно менять формат когда угодно. Когда их двадцать, любое поле превращается в контракт. Я прошёл через неделю боли, когда один разработчик переименовал поле, а упали три команды, которые об этом не знали. Схему надо версионировать, менять только обратно совместимым способом и держать реестр схем, а не полагаться на память коллег.
Что бы я посоветовал тем, кто сейчас проектирует свою первую событийную систему? Не начинайте с кластера из семи брокеров и сложной топологии. Возьмите минимальную конфигурацию, но сразу заложите три вещи: идемпотентную обработку, осмысленные ключи партиционирования и мониторинг лага. Добавьте разбор мёртвых писем и договоритесь о правилах изменения схем до того, как это понадобится. И честно ответьте себе на вопрос, действительно ли вам нужен Kafka, а не простая очередь задач. Kafka мощная, но она не прощает небрежности — зато когда всё настроено, она держит нагрузку, о которой раньше можно было только мечтать.
А как у вас было с первым знакомством? Расскажите, какая иллюзия про Kafka рассыпалась у вас первой — дубли, порядок, лаг или что-то совсем неожиданное? Очень интересно сравнить опыт и, может быть, собрать из комментариев народный чек-лист для новичков.