Ответ
Архитектура Apache Kafka строится из нескольких взаимосвязанных компонентов:
-
Брокер (Broker)
- Что это: Отдельный сервер (нода) в кластере Kafka. Хранит данные, обрабатывает запросы на запись и чтение.
- Зачем: Кластер состоит из нескольких брокеров для обеспечения масштабируемости, отказоустойчивости и распределения нагрузки. Каждый брокер идентифицируется уникальным ID.
-
Топик (Topic)
- Что это: Логическая категория или канал, в который публикуются сообщения. Аналог таблицы в БД или темы в очереди.
- Зачем: Позволяет разделять данные по типам событий (например,
user-registrations,payment-events).
-
Партиция (Partition)
- Что это: Топик физически делится на одну или несколько упорядоченных, неизменяемых последовательностей записей — партиций.
- Зачем: Обеспечивает параллелизм и масштабирование. Разные партиции топика могут обслуживаться разными брокерами. Порядок гарантируется только в пределах одной партиции.
- Репликация: Каждая партиция реплицируется на несколько брокеров (один лидер для записи/чтения, остальные — follower-ы для отказоустойчивости).
-
Продюсер (Producer)
- Что это: Клиентское приложение, публикующее (пишущее) сообщения в топики Kafka.
- Зачем: Определяет, в какую партицию топика отправить сообщение (по ключу или round-robin).
-
Пример (Java):
Properties props = new Properties(); props.put("bootstrap.servers", "broker1:9092,broker2:9092"); props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer"); props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer"); try (Producer<String, String> producer = new KafkaProducer<>(props)) { ProducerRecord<String, String> record = new ProducerRecord<>("my-topic", "user123", "{"event":"login"}"); producer.send(record); // Асинхронная отправка }
-
Консьюмер (Consumer)
- Что это: Клиентское приложение, читающее сообщения из топиков.
- Зачем: Консьюмеры объединяются в группы (Consumer Groups). Каждая партиция топика потребляется только одним консьюмером из группы, что позволяет масштабировать обработку.
-
ZooKeeper / KRaft (Контроллер)
- Что это: Служба управления метаданными кластера (до версии Kafka 3.0+ — Apache ZooKeeper, в новых версиях — встроенный Raft-консенсус KRaft).
- Зачем: Отвечает за выбор лидера партиций, отслеживание состояния брокеров, конфигурацию ACL. Важно: В актуальных версиях Kafka стремится к полному отказу от ZooKeeper в пользу KRaft.
Взаимосвязь: Продюсеры пишут данные в партиции топиков на брокерах. Консьюмеры читают эти данные, отслеживая свою позицию (offset). Координацией всего процесса управляет контроллер (ZooKeeper/KRaft).
Ответ 18+ 🔞
Так, слушай, давай разберём эту вашу Кафку, а то некоторые думают, что это такой писатель зарубежный. Нет, это система, где всё летит с такой скоростью, что волосы на жопе встают дыбом.
Представь себе огромный сортировочный центр для данных, только вместо посылок — сообщения, а вместо грузчиков — демоны цифрового ада. Вот как оно устроено, по косточкам:
1. Брокер (Broker) Это, блядь, отдельный сервак, кирпичик в стене. Как один чувак в толпе. Он хранит данные, принимает и отдаёт их. Но один он — лох, сдохнет под нагрузкой. Поэтому их всегда овердохуища — целый кластер. У каждого свой ID, чтобы не путать, кто есть хуй с горой.
2. Топик (Topic)
Ну это типа темы для разговора. Нельзя же всё в одну кучу валить! Хочешь говорить про регистрации пользователей — заведи топик user-registrations. Про платежи — payment-events. Как раздел на форуме, только сообщения не стираются, а копятся, как грехи.
3. Партиция (Partition) А вот тут начинается магия, ёпта! Каждый топик нарезается на куски — партиции. Это чтобы не один поток данных был, а несколько параллельных. Порядок сообщений гарантируется только в рамках одной партиции! Запомни это, как «Отче наш». Хочешь строгий порядок для всех событий по ключу «user123» — отправляй все его события в одну партицию. Иначе будет пиздец и бардак. А ещё каждая партиция реплицируется на несколько брокеров. Один — лидер (он всем рулит), остальные — его подпевалы (фолловеры), на случай если лидера прибьют. Отказоустойчивость, мать её.
4. Продюсер (Producer) Это тот, кто орет в этот ваш канал. Приложение, которое пишет сообщения. Его задача — решить, в какую именно партицию топика запихнуть своё ценное сообщение. По ключу или просто по кругу. Вот смотри, как он орет на Java:
Properties props = new Properties();
props.put("bootstrap.servers", "broker1:9092,broker2:9092");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
try (Producer<String, String> producer = new KafkaProducer<>(props)) {
ProducerRecord<String, String> record =
new ProducerRecord<>("my-topic", "user123", "{"event":"login"}");
producer.send(record); // Отправил и забыл, асинхронно, блядь
}5. Консьюмер (Consumer) А это — уши системы. Приложение, которое слушает, что наговорили продюсеры. Консьюмеры не одиночки, они любят тусоваться группами (Consumer Groups). И вот главное правило, чтоб оно тебе в сраку чих-пых: одну партицию топика слушает только один консьюмер из группы! Так они между собой нагрузку делят. Добавил консьюмеров в группу — обработка ускорилась. Красота!
6. ZooKeeper / KRaft (Контроллер) Мозг, дирижёр, главный по тарелочкам. Раньше для этого нужен был отдельный зоопарк — Apache ZooKeeper, который был такой же сложный и капризный, как мартышлюшка. Он следил, кто лидер, какие брокеры живы, где что лежит. Но потом Кафка возмужала и говорит: «Нахуй этого посредника!». И в версиях 3.0+ появился свой внутренний контроллер на Raft-консенсусе — KRaft. Теперь Кафка сама себе и голова, и хвост. Стремление, блядь, к независимости.
Как это всё вместе ебётся? Продюсеры орут в топики, сообщения ложатся в партиции на брокерах. Консьюмеры, сбившись в стаи, читают эти сообщения, аккуратно отмечая, где остановились (offset). А над всей этой вакханалией, как хитрая жопа, парит контроллер (ZooKeeper или KRaft) и следит, чтобы лидеры не сбежали, а реплики не отстали. Вот и вся архитектура, не боги горшки обжигают.