Обзор архитектуры Kafka

Ever wondered how massive companies handle huge streams of data? That's where Apache Kafka shines! It's a powerful, distributed streaming platform.

In this lesson, we'll peel back the layers to understand Kafka's core architecture. We'll explore its main components and how they work together.

At the heart of a Kafka cluster are brokers. Think of them as individual Kafka servers. A Kafka cluster is made up of one or more brokers.

• Store Data: Brokers receive and store messages (called events).
• Serve Clients: They handle requests from producers (apps sending data) and consumers (apps reading data).
• Distributed: For reliability and scalability, Kafka typically runs with multiple brokers.

When you have multiple brokers, they form a Kafka cluster. This cluster works together as a single, highly available system.

If one broker fails, others can take over its responsibilities, ensuring that data processing continues without interruption. This is key for robust systems.

For brokers to work together effectively, they need a coordinator. That's where Apache ZooKeeper comes in.

ZooKeeper manages and coordinates the Kafka brokers. It keeps track of:

• Which brokers are alive and available.
• Topic configurations and partitions.
• Controller election (which broker is the 'leader').

It acts as the central source of truth for the cluster's metadata.

In Kafka, data is organized into topics. A topic is a category or feed name to which records are published. Think of it like a folder for specific types of messages.

For example, you might have a user_signups topic for new user registrations and a product_views topic for user browsing activity.

To handle large volumes of data and enable parallel processing, topics are divided into partitions.

• Each partition is an ordered, immutable sequence of records.
• Data in a partition is appended to a log.
• Partitions are distributed across brokers, allowing for horizontal scaling.

This means multiple consumers can read from different partitions of the same topic simultaneously.

On disk, each partition is stored as a log. This log is further broken down into segments.

• A segment is a physical file on the broker's filesystem.
• New messages are always appended to the active segment.
• Older segments can be deleted or compacted based on retention policies.

This log-structured storage is highly optimized for sequential writes and reads, making Kafka very performant.

Kafka's core design relies on the concept of an immutable commit log. Once a message is written to a partition, it cannot be changed.

New messages are always appended to the end. This simple yet powerful principle is fundamental to Kafka's consistency and durability guarantees.

Applications interact with the Kafka cluster using clients:

• Producers: Applications that publish (send) messages to Kafka topics.
• Consumers: Applications that subscribe to topics and process the messages.

These clients don't interact directly with each other, only with the Kafka brokers. This creates a highly decoupled system.

Kafka achieves high fault tolerance through replication. Each partition can have multiple copies (replicas) spread across different brokers.

• One replica is the leader, handling all read/write requests for that partition.
• Others are followers, which passively replicate the leader's data.

If the leader fails, ZooKeeper helps elect a new leader from the followers, ensuring continuous service.

Great job! In this lesson, we explored the foundational architecture of Apache Kafka.

• Brokers form the distributed cluster, storing and serving data.
• ZooKeeper acts as the vital coordinator for the cluster.
• Data is organized into topics, which are split into partitions for scalability.
• Partitions are stored as immutable logs on disk.
• Producers send messages, and consumers read them.
• Replication ensures fault tolerance and high availability.

This distributed design makes Kafka incredibly robust and scalable for real-time data streaming!