Backend Systems | balun.courses

Kafka не создавали для того, как её используют сегодня Партиции, оффсеты, репликацию и гарантии доставки намного проще понять, если сначала ответить на один вопрос: какую проблему вообще решали разработчики Kafka?

Когда команда LinkedIn создавала Kafka в 2010 году, она не думала про микросервисы или event-driven архитектуру. Задача была гораздо прозаичнее – передавать между внутренними системами огромные объёмы логов и пользовательских событий.

Именно под эту задачу проектировалась Kafka. Сообщения не удаляются после чтения, потому что один и тот же поток данных могут читать несколько систем. Оффсеты позволяют каждому потребителю самому определять, с какого места продолжить чтение. Партиции дают возможность масштабировать обработку, а репликация – не потерять данные при отказе узла. Если не знать, зачем всё это появилось, архитектура Kafka выглядит как набор механизмов, которые просто существуют. Но как только понимаешь исходную задачу, становится видно, почему эти механизмы вообще появились и почему они работают именно так. Поэтому в курсе «Kafka для разработчиков: тонкости и нюансы» мы начинаем с истории появления Kafka и принципов, которые легли в основу её архитектуры. После этого партиции, оффсеты и гарантии доставки уже не приходится запоминать – они становятся логичным следствием задачи, которую решали разработчики.

Вопрос про Kafka, который возникает почти на каждом менторстве

Рассказывает Андрей Серебрянский – ведущий разработчик в Яндекс

Когда я общаюсь с разработчиками на менторстве, рано или поздно возникает один и тот же вопрос: ⁉️Можно ли в Kafka сделать так, чтобы не было ни потерь, ни дублей сообщений? Обычно следом вспоминают термин exactly once и то, что в Kafka есть транзакции. Дальше я задаю встречный вопрос: Что именно вы хотите гарантировать? Что сообщение один раз запишется в Kafka? Что консюмер получит его только один раз? Что бизнес-логика обработает его один раз? Или что запись в базу данных после чтения из Kafka тоже произойдет ровно один раз? Обычно после этого становится понятно, что под exactly once разные разработчики понимают совершенно разные вещи. Kafka действительно во многих сценариях позволяет добиться exactly once обработки. Но это не означает, что любые дубли и потери автоматически исчезают после включения транзакций. Здесь много нюансов, и почти всегда приходится учитывать, как устроено само приложение и как взаимодействуют между собой брокер, консюмер и внешние системы. 💬 А как бы вы ответили на этот вопрос? Напишите свой вариант в комментариях)

Расследование production-инцидентов с помощью OpenTelemetry + AI • 29 июля, CР • 19:00 по мск Открытый урок для разработчиков и DevOps. Покажем observability-стек и продвинутые возможности Otel, которые помогают искать и чинить инциденты с помощью AI-агента Что будет на уроке: 1️⃣База по OpenTelemetry для понимания контекста 2️⃣Продвинутые инструменты Otel, которые передают агенту связный контекст инцидента вместо «тонны логов» 3️⃣Как этот контекст помогает AI расследовать инциденты и строить отчеты с анализом первопричин 4️⃣Устройство архитектуры и observability вокруг AI для наблюдения деградаций и качества решений агента Рассказывает Виталий Лихачев, SRE в TravelTech, который ты точно знаешь

Запись для всех зарегистрировавшихся

➡️Записаться на урок

Kafka или RabbitMQ? На собеседовании я отвечаю не так, как ожидают

Рассказывает Андрей Серебрянский, ведущий разработчик в Яндекс

Это один из тех вопросов, на который обычно ждут короткий ответ: «Для этого бери RabbitMQ, для этого – Kafka». За годы работы я пришел к другому выводу. Сам вопрос не совсем правильный. Когда сервисы начинают напрямую вызывать друг друга по API, рано или поздно кто-то перестает справляться с нагрузкой. Один сервис замедляется, за ним начинают ждать остальные, появляются таймауты, а затем и каскадные отказы. И RabbitMQ, и Kafka появились, чтобы решить именно эту проблему. Продюсер записывает сообщение в брокер, а консюмер забирает его тогда, когда готов. Сервисы перестают зависеть друг от друга, а система становится устойчивее. На этом сходство заканчивается. Представьте, что сервис неделю неправильно рассчитывал комиссию по операциям. Ошибку нашли, код исправили, теперь нужно заново обработать все события за последние несколько дней. В RabbitMQ это может оказаться проблемой. Сообщение прочитали, подтвердили обработку – оно исчезло из очереди. Чтобы обработать его еще раз, придется искать другой способ восстановить данные. В Kafka события продолжают храниться в течение retention-периода. Можно вернуть консюмер на нужный offset и заново пройти весь поток. Именно поэтому Kafka часто становится основой не только для обмена сообщениями между сервисами, но и для аналитики, стриминговой обработки данных и построения data-платформ. Есть и еще одно отличие, которое становится заметно по мере роста нагрузки. В Kafka данные разбиваются на партиции и распределяются между брокерами. Если через год поток сообщений вырос в несколько раз, систему можно масштабировать, добавив новые брокеры и партиции, а не упираться в одну перегруженную очередь.

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

Именно с этого начинается наш курс «Kafka для разработчиков: тонкости и нюансы». Не с producer API и не с настройки кластера, а с понимания того, почему Kafka устроена именно так и какие инженерные задачи решают топики, партиции, retention и offsets. Когда понимаешь эти принципы, многие архитектурные решения становятся очевиднее, а настройка Kafka перестает быть набором параметров из документации. ➡️ПЕРЕЙТИ НА САЙТ

Ищем кандидатов для съёмок mock-собеседований: PostgreSQL, Elasticsearch, Team Lead, DevOps, SRE Всем привет 🙌🏻 Хотим записать для YouTube-канала школы несколько новых mock-собеседований и ищем интересных кандидатов. В ближайшее время планируем провести mock-собеседования с вопросами по PostgreSQL и Elasticsearch, а также отдельные собеседования на позиции Team Lead, DevOps и SRE. Если хотите поучаствовать, напишите @widdfiiwgth. В сообщении сразу укажите, на какое направление вы откликаетесь, ваш общий опыт работы в IT, опыт в выбранной теме или роли, а также текущую должность и стек технологий❤️

PostgreSQL и тормозящие запросы: что делать, когда индексы есть, а толку – нет? • 20 июля, ПН • 19:00 по мск Открытый урок по PgSQL для разработчиков: частые ошибки с индексами, из-за которых тормозят запросы, и как это пофиксить Что будет на уроке: 1️⃣Почему PostgreSQL выбирает Seq Scan даже при наличии индекса, и когда это нормально 2️⃣Как читать EXPLAIN ANALYZE и за минуты находить причину медленного запроса 3️⃣ТОП-ошибок разработчиков, из-за которых индексы не работают или замедляют систему 4️⃣Пошаговый алгоритм анализа скорости запросов, который сразу можно применить в работе Рассказывает Олег Мифле, Team Lead разработки в Т-банке.

Запись для всех зарегистрировавшихся

➡️Записаться на урок

✖️Kafka не тормозит. Тормозит одно решение, которое принимают почти все команды Когда начинают жаловаться на производительность Kafka, проблема часто оказывается не в самой Kafka. Типичная история выглядит так. Команда запускает новый сервис, рассчитывает примерно на 5 тысяч сообщений в секунду и проектирует систему под эту нагрузку. Первое время всё работает без вопросов. Через год нагрузка вырастает до 50 тысяч сообщений в секунду, и начинаются задержки. Продюсеры пишут медленнее, консюмеры перестают успевать за потоком, ребалансы занимают всё больше времени. Дальше обычно идут привычные действия: добавляют брокеры, увеличивают ресурсы кластера, меняют настройки. Иногда это помогает, но нередко выясняется, что проблема появилась задолго до первых симптомов.

Например, в качестве partition key выбрали поле, которое распределяет сообщения крайне неравномерно. Или создали слишком мало партиций, потому что на старте их действительно хватало. Или сделали архитектуру консюмеров такой, что масштабировать её без переписывания уже не получится.

Все эти решения принимаются в момент, когда система ещё работает быстро. Поэтому кажется, что они удачные. Последствия становятся заметны только тогда, когда продукт начинает расти. Поэтому проектирование записи в Kafka – это не только выбор настроек продюсера. Нужно понимать, как будут распределяться сообщения, сколько партиций понадобится через год, где появятся узкие места и что произойдёт, если нагрузка вырастет в несколько раз. Этой теме мы посвящаем отдельный урок курса. Разбираем, как проектировать запись в Kafka с запасом по производительности, как выбирать количество партиций, какие компромиссы возникают при разных гарантиях доставки и какие ошибки проще не допустить, чем исправлять в работающей системе. Начинаем 8 сентября. ✔️ИЗУЧИТЬ ПРОГРАММУ КУРСА

Добро пожаловать!🫶🏻 Этот канал – про бэкенд-инженерию в продакшене.

Здесь мы разбираем Kafka, PostgreSQL, Redis, Elasticsearch, observability, распределенные системы и делимся опытом, который пригодится при разработке высоконагруженных сервисов и на технических собеседованиях.

Ниже собрали все материалы, с которых рекомендуем начать: 1️⃣Kafka 📺Видео • Что каждый разработчик должен знать про Kafka? • Как ответить на вопросы про Kafka на интервью? Полный разбор • Kafka vs RabbitMQ – в чем реальная разница? 📖 Статьи • Apache Kafka за 5 минут: зачем она нужна? • Топ вопросов по Kafka, которые спрашивают на собеседованиях • Отвечаем на популярные вопросы про Kafka Курс «Kafka для разработчиков: тонкости и нюансы» Глубокий курс про внутреннее устройство Kafka, лучшие практики, паттерны и антипаттерны для работы с highload-проектами. ИЗУЧИТЬ ПРОГРАММУ КУРСА 2️⃣Observability 📺 Видео • Что не так с твоими дашбордами в Grafana? • Как построить правильный дашборд для Golang-приложения? • Разбор метрик рантайма Go-приложений Курс по Observability Полная база по observability: метрики, логи, трейсы, Grafana, мониторинг, расследование инцидентов и лучшие практики – от небольших проектов до BigTech. ИЗУЧИТЬ ПРОГРАММУ КУРСА По мере выхода новых материалов будем дополнять этот закреп❤️ 💾Общий канал Balun Courses