Из каких основных компонентов состоит Apache Kafka?

А, ну вот, слушай, смотри, сейчас я тебе на пальцах, блядь, объясню, что это за зверь такой — Apache Kafka. Представь себе огромную, ёбаную, распределённую трубу для сообщений, только умную. Не просто трубу, а целый нефтепровод для данных, где всё летит с овердохуища скоростью и не теряется. Архитектура, в принципе, логичная, если не тупить.

1. Broker (Брокер) — это, по сути, один сервак в этой системе. Но один сервак — это пиздец как ненадёжно, поэтому их всегда дохуя. Они собираются в кластер, и если один, сука, накроется медным тазом, остальные подхватят. Отказоустойчивость, масштабируемость — вот это всё.

2. Topic (Топик) — это как бы канал, куда льются данные. Ну, типа «новости_спорт» или «заказы_с_сайта». Продюсеры в него плюют сообщения, а консьюмеры из него хлебают. Просто именованная очередь, только круче.

3. Partition (Партиция) — а вот тут начинается магия. Чтобы не создавать одну огромную, неповоротливую очередь, топик, блядь, режут на партиции. Это как параллельные дорожки на хайвее. Сообщения в каждой партиции идут строго по порядку, а между партициями — похуй, порядок не гарантирован. Зато можно читать и писать в несколько потоков — производительность зашкаливает.

4. Producer (Продюсер) — это тот, кто эти сообщения создаёт и закидывает в топик. Приложение какое-нибудь, которое орёт: «Эй, Kafka, держи запись о новом пользователе!».

5. Consumer (Консьюмер) — обратная сторона. Это приложение, которое подписывается на топик и, как голодный зверь, выгребает оттуда сообщения для обработки. «О, новое событие, надо его в базу записать!».

6. Consumer Group (Группа консьюмеров) — а это, блядь, гениально. Чтобы обрабатывать данные из топика быстрее, можно набросать кучу одинаковых консьюмеров в одну группу. Kafka сама, хитрая жопа, распределит партиции топика между ними. Одна партиция — один консьюмер в группе. Добавил консьюмеров — масштабировал чтение. Убрал — Kafka перераспределит. Красота!

7. ZooKeeper / KRaft — а вот это мозги всей операции.

• ZooKeeper — это такой отдельный, ёпта, менеджер-зануда, который в старых версиях всё помнил: кто в кластере, где что лежит, кто кому что может. Без него раньше Kafka вообще не жила.
• KRaft — а это новая фишка, чтобы избавиться от этого зануды. Теперь Kafka сама, своим умом, договаривается между брокерами, кто главный и где метаданные. Стало проще, блядь, развернуть — один меньше компонент тащить.

Ну и чтобы не быть голословным, вот тебе кусочек кода на Go, как продюсер сообщение отправляет. Смотри, ничего сложного:

package main

import (
    "fmt"
    "github.com/IBM/sarama"
)

func main() {
    config := sarama.NewConfig()
    config.Producer.Return.Successes = true
    producer, err := sarama.NewSyncProducer([]string{"localhost:9092"}, config)
    if err != nil {
        panic(err)
    }
    defer producer.Close()

    msg := &sarama.ProducerMessage{
        Topic: "my-topic",
        Value: sarama.StringEncoder("Hello, Kafka!"),
    }

    partition, offset, err := producer.SendMessage(msg)
    if err != nil {
        panic(err)
    }

    fmt.Printf("Message is stored in topic(%s)/partition(%d)/offset(%d)n", "my-topic", partition, offset)
}

Вот, отправил сообщение в топик my-topic, а оно, сука, приземлилось в конкретную партицию и заняло конкретную позицию (offset). Всё, записано навечно в лог, пока срок хранения не вышел или ты его вручную не удалил. Красота, в общем.