May 12, 2017
Kafka Topic Architecture - Replication, Failover and Parallel Processing
This article covers some lower level details of Kafka topic architecture. It is a continuation of the Kafka Architecture article.
This article covers Kafka Topic’s Architecture with a discussion of how partitions are used for fail-over and parallel processing.
Kafka Topics, Logs, Partitions
Recall that a Kafka topic is a named stream of records. Kafka stores topics in logs. A topic log is broken up into partitions. Kafka spreads log’s partitions across multiple servers or disks. Think of a topic as a category, stream name or feed.
Topics are inherently published and subscribe style messaging. A Topic can have zero or many subscribers called consumer groups. Topics are broken up into partitions for speed, scalability, and size.
Kafka Topic Partitions
Kafka breaks topic logs up into partitions. A record is stored on a partition usually by record key if the key is present and round-robin if the key is missing (default behavior). The record key, by default, determines which partition a producer sends the record.
Kafka uses partitions to scale a topic across many servers for producer writes. Also, Kafka also uses partitions to facilitate parallel consumers. Consumers consume records in parallel up to the number of partitions.
The order guaranteed per partition. If partitioning by key then all records for the key will be on the same partition which is useful if you ever have to replay the log. Kafka can replicate partitions to multiple brokers for failover.
Kafka Topic Log Partition’s Ordering and Cardinality
Kafka maintains record order only in a single partition. A partition is an ordered, immutable record sequence. Kafka continually appended to partitions using the partition as a structured commit log. Records in partitions are assigned sequential id number called the offset. The offset identifies each record location within the partition. Topic partitions allow Kafka log to scale beyond a size that will fit on a single server. Topic partitions must fit on servers that host it, but topics can span many partitions hosted on many servers. Also, topic partitions are a unit of parallelism - a partition can only be worked on by one consumer in a consumer group at a time. Consumers can run in their own process or their own thread. If a consumer stops, Kafka spreads partitions across the remaining consumer in the same consumer group.
Kafka Architecture: Topic Partition Layout and Offsets
Kafka Topic Partition Replication
Kafka can replicate partitions across a configurable number of Kafka servers
which is used for fault tolerance. Each partition has a leader server and zero
or more follower servers. Leaders handle all read and write requests for a partition.
Followers replicate leaders and take over if the leader dies. Kafka uses also uses partitions for parallel consumer handling within a group. Kafka distributes topic log partitions over servers in the Kafka cluster. Each server handles its share of data and requests by sharing partition leadership.
Replication: Kafka Partition Leaders, Followers and ISRs.
Kafka chooses one broker’s partition’s replicas as leader using ZooKeeper.
The broker that has the partition leader handles all reads and writes of records for the partition. Kafka replicates writes to the leader partition to followers (node/partition pair). A follower that is in-sync is called an ISR (in-sync replica). If a partition leader fails, Kafka chooses a new ISR as the new leader.
Kafka Architecture: Kafka Replication - Replicating to Partition 0
The record is considered “committed” when all ISRs for partition wrote to their log. Only committed records are readable from consumer. Another partition can be owned by another leader on another Kafka Broker.
Kafka Architecture: Kafka Replication - Replicating to Partition 1
Kafka Topic Architecture in Review
What is an ISR?
An ISR is an in-sync replica. If a leader fails, an ISR is picked to be a new leader.
How does Kafka scale consumers?
Kafka scales consumers by partition such that each consumer gets its share of partitions. A consumer can have more than one partition, but a partition can only be used by one consumer in a consumer group at a time. If you only have one partition, then you can only have one consumer.
What are leaders? Followers?
Leaders perform all reads and writes to a particular topic partition. Followers replicate leaders.
How does Kafka perform failover for consumers?
If a consumer in a consumer group dies, the partitions assigned to that consumer is divided up amongst the remaining consumers in that group.
How does Kafka perform failover for Brokers?
If a broker dies, then Kafka divides up leadership of its topic partitions to the remaining brokers in the cluster.
Kafka Producer Architecture
Please continue reading about Kafka Architecture. The next article covers Kafka Producer Architecture with a discussion of how partitions are picked for records.
- What is Kafka?
- Kafka Architecture
- Kafka Topic Architecture
- Kafka Consumer Architecture
- Kafka Producer Architecture
- Kafka Architecture and low level design
- Kafka and Schema Registry
- Kafka and Avro
- Kafka Ecosystem
- Kafka vs. JMS
- Kafka versus Kinesis
- Kafka Tutorial: Using Kafka from the command line
- Kafka Tutorial: Kafka Broker Failover and Consumer Failover
- Kafka Tutorial
- Kafka Tutorial: Writing a Kafka Producer example in Java
- Kafka Tutorial: Writing a Kafka Consumer example in Java
- Kafka Architecture: Log Compaction
- Kafka Architecture: Low-Level PDF Slides
Check out our new GoLang course. We provide onsite Go Lang training which is instructor led.Tweet
Apache Spark Training
AWS Cassandra Database Support
Kafka Support Pricing
Cassandra Database Support Pricing
Advantages of using Cloudurable™
Cloudurable™| Guide to AWS Cassandra Deploy
Cloudurable™| AWS Cassandra Guidelines and Notes
Free guide to deploying Cassandra on AWS
Kafka Tutorial PDF
Kubernetes Security Training
ElasticSearch / ELK Consulting
InfluxDB/TICK Training TICK Consulting