De basis van Apache Kafka en streamverwerking · Les

Ontwerpen voor hoge doorvoer

Leer architectuurprincipes en best practices voor het bouwen van systemen op basis van Kafka die enorme datavolumes aankunnen.

Les 1 van 413 stappen

Ontwerpen voor hoge doorvoer is een gratis De basis van Apache Kafka en streamverwerking-les op CoddyKit. Dit is les 1 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject De basis van Apache Kafka en streamverwerking. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus De basis van Apache Kafka en streamverwerking bevat in totaal 4 lessen.

Wat is hoge doorvoer?

In Kafka betekent hoge doorvoer dat je systeem efficiënt een enorme hoeveelheid gegevens per seconde of minuut kan verwerken. Dit is essentieel voor toepassingen zoals realtimeanalyse, het verzamelen van IoT-gegevens en het samenvoegen van logboeken, waarbij continu grote hoeveelheden gegevens binnenkomen.

Door te ontwerpen voor hoge doorvoer zorg je ervoor dat je Kafka-cluster en toepassingen piekbelastingen aankunnen zonder verslechterde prestaties, gegevensverlies of aanzienlijke vertragingen.

Belangrijke factoren voor doorvoer

Een hoge doorvoer in Kafka bereiken betekent dat je verschillende onderling verbonden onderdelen optimaliseert. Zie het als een keten: de zwakste schakel bepaalt de totale snelheid.

Producers: Hoe efficiënt ze gegevens verzenden.
Brokers: Hoe snel ze gegevens opslaan en beschikbaar maken.
Consumers: Hoe snel ze gegevens lezen en verwerken.
Infrastructuur: Netwerkbandbreedte en snelheid van schijf-I/O.

Producer optimaliseren: batching

Berichten één voor één verzenden is inefficiënt. Producers kunnen berichten bundelen en meerdere records in één verzoek verzenden. Dit vermindert de netwerkoverhead en verbetert de doorvoer.

batch.size: De maximale grootte in bytes van één batch.
linger.ms: De maximale tijd die een producer wacht voordat deze een batch verzendt, ook als de batch nog niet vol is.

Door deze waarden aan te passen breng je latentie (hoe snel een bericht wordt verzonden) en doorvoer (hoeveel berichten in een bepaalde tijd worden verzonden) met elkaar in balans.

Voorbeeld van een producer met batching

Zo configureer je een producer voor batching. Let op de instellingen batch.size en linger.ms.

import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerRecord;
import java.util.Properties;

public class HighThroughputProducer {

    public static void main(String[] args) {
        Properties props = new Properties();
        props.put("bootstrap.servers", "localhost:9092");
        props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");

        // High throughput settings
        props.put("batch.size", 65536); // 64 KB batch size
        props.put("linger.ms", 10);    // Wait up to 10 ms for more records
        props.put("compression.type", "snappy"); // Compress batches
        props.put("acks", "1");         // Acks=1 for good balance

        try (KafkaProducer<String, String> producer = new KafkaProducer<>(props)) {
            for (int i = 0; i < 1000; i++) {
                String message = "Hello Kafka Throughput - " + i;
                producer.send(new ProducerRecord<>("throughput-topic", "key-" + i, message));
            }
            System.out.println("1000 messages sent to throughput-topic.");
        }
    }
}

Producercompressie en ACK's

Naast batching hebben nog twee andere producerinstellingen grote invloed op de doorvoer:

compression.type: Door gegevens te comprimeren (bijvoorbeeld met gzip, snappy of lz4) gebruik je minder netwerkbandbreedte en schijfruimte. Daardoor kunnen meer gegevens worden verzonden en opgeslagen, wat de effectieve doorvoer verhoogt.
acks: Bepaalt de garantie voor duurzaamheid. acks=0 (verzenden zonder op bevestiging te wachten) biedt de hoogste doorvoer, maar de laagste duurzaamheid. acks=1 (de leader bevestigt) biedt een goede balans. acks=all (alle synchrone replica's bevestigen) biedt de hoogste duurzaamheid, maar de laagste doorvoer.

Broker schalen: partities en schijven

Kafka-brokers vormen de ruggengraat. Hun doorvoer hangt sterk af van:

Partities: Elke topicpartitie is een geordend logboek. Meer partities maken meer parallellisme mogelijk bij het schrijven en lezen van gegevens door brokers en consumers. Verdeel partities gelijkmatig over de brokers.
Schijf-I/O: Kafka gebruikt de schijf intensief. Het gebruik van snelle SSD's en het configureren van RAID 0 of RAID 10 voor gegevensmappen verbetert de schrijf- en leessnelheid aanzienlijk. Dit is essentieel voor een hoge doorvoer.

Netwerk en CPU van brokers

Vergeet de onderliggende hardware van je brokers niet:

Netwerk: Snelle netwerkinterfaces (bijvoorbeeld 10 Gigabit Ethernet) en voldoende bandbreedte zijn van het grootste belang. Brokers verplaatsen voortdurend gegevens tussen elkaar (replicatie) en met clients.
CPU: Hoewel Kafka is geoptimaliseerd voor sequentiële schijf-I/O, kan de CPU een knelpunt worden, vooral bij intensieve gegevenscompressie en -decompressie, SSL-versleuteling of complexe ACL's. Zorg voor voldoende CPU-kernen.

Consumer optimaliseren: batches ophalen

Ook consumers profiteren van batching. In plaats van telkens één record op te vragen, halen consumers een batch records op.

max.poll.records: Het maximale aantal records dat in één aanroep van poll() wordt teruggegeven. Meer records per poll verwerken vermindert de overhead van herhaalde aanroepen.
fetch.min.bytes: De minimale hoeveelheid gegevens (in bytes) die de consumer van een broker wil ontvangen voordat deze gegevens teruggeeft.
fetch.max.wait.ms: De maximale tijd (in ms) die de consumer wacht totdat aan fetch.min.bytes is voldaan.

Voorbeeld van een consumer met batching

Een consumer die is geconfigureerd om batches op te halen, haalt per aanroep van poll() meer records op, waardoor de verwerking efficiënter wordt.

import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.apache.kafka.clients.consumer.KafkaConsumer;
import java.time.Duration;
import java.util.Collections;
import java.util.Properties;

public class HighThroughputConsumer {

    public static void main(String[] args) {
        Properties props = new Properties();
        props.put("bootstrap.servers", "localhost:9092");
        props.put("group.id", "throughput-group");
        props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
        props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");

        // High throughput settings
        props.put("max.poll.records", 500); // Fetch up to 500 records at once
        props.put("fetch.min.bytes", 1048576); // Wait for 1MB of data
        props.put("fetch.max.wait.ms", 500); // Or wait 500ms

        try (KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props)) {
            consumer.subscribe(Collections.singletonList("throughput-topic"));

            while (true) {
                ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
                if (!records.isEmpty()) {
                    System.out.println("Received " + records.count() + " records.");
                    // Process records (e.g., in a thread pool for parallelism)
                    records.forEach(record -> {
                        // System.out.println("Processing record: " + record.value());
                    });
                    consumer.commitSync();
                }
            }
        }
    }
}

Parallelle verwerking door consumers

Hoewel max.poll.records helpt bij het ophalen van gegevens, kan de daadwerkelijke verwerking van berichten een knelpunt vormen. Zo maximaliseer je de doorvoer van consumers:

Interne threadpool: Implementeer een threadpool binnen je consumer-toepassing. Wanneer poll() een batch records teruggeeft, stuur je deze records naar de threadpool voor parallelle verwerking.
Zorgvuldig offsetbeheer: Als je parallel verwerkt, zorg er dan voor dat je offsets pas vastlegt nadat alle berichten in een batch (of een specifieke subset) succesvol zijn verwerkt. Anders loop je het risico op gegevensverlies of opnieuw verwerken.

Doorvoermetrieken controleren

Continue monitoring is essentieel om knelpunten in de doorvoer te herkennen. Belangrijke metrieken om in de gaten te houden:

Producer: Verzoekfrequentie, bytesnelheid en verzoeklatentie.
Consumer: Ophaalfrequentie, bytesnelheid en consumentenachterstand (het belangrijkste kenmerk om knelpunten in de verwerking te herkennen).
Broker: Schijf-I/O (lezen/schrijven), netwerk-I/O, CPU-gebruik en geheugengebruik.
Netwerk: Benutting van bandbreedte en pakketverlies.

Tools zoals JMX, Prometheus/Grafana en Confluent Control Center kunnen helpen om deze metrieken zichtbaar te maken.

Uitdaging: doorvoer optimaliseren

Je hebt verschillende strategieën geleerd om de doorvoer van Kafka-systemen te verhogen. Welke van de volgende acties zou over het algemeen helpen om de totale doorvoer van een op Kafka gebaseerde gegevenspijplijn te verhogen?

Beantwoord dit in de interactieve les

Samenvatting: ontwerpen voor doorvoer

Gefeliciteerd! Je hebt belangrijke strategieën verkend om op Kafka gebaseerde systemen te ontwerpen die enorme hoeveelheden gegevens met een hoge doorvoer kunnen verwerken.

Optimaliseer producers met batching, compressie en geschikte `acks`-instellingen.
Schaal brokers door voldoende partities, snelle schijven en voldoende netwerk- en CPU-capaciteit te gebruiken.
Stem consumers af met batches ophalen en implementeer interne parallelle verwerking.
Controleer kritieke metrieken om knelpunten proactief te herkennen en aan te pakken.

Deze technieken beheersen is essentieel voor het bouwen van robuuste en goed presterende realtimegegevensplatforms.

Gratis beginnen

Leer De basis van Apache Kafka en streamverwerking met een AI-tutor — gratis

Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.

Cursussen: 12
Lessen: 48

Gratis beginnen met leren Bekijk de volledige cursus

Veelgestelde vragen

Is de les “Ontwerpen voor hoge doorvoer” gratis?

Ja — je kunt hier op het web alle 3 lessen van het leerpad De basis van Apache Kafka en streamverwerking, waaronder “Ontwerpen voor hoge doorvoer”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus De basis van Apache Kafka en streamverwerking bevat in totaal 4 lessen.

Wat leer ik in “Ontwerpen voor hoge doorvoer”?

Leer architectuurprincipes en best practices voor het bouwen van systemen op basis van Kafka die enorme datavolumes aankunnen. Je oefent met De basis van Apache Kafka en streamverwerking door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.

Heb ik ervaring nodig om met De basis van Apache Kafka en streamverwerking te beginnen?

Ervaring vooraf is niet nodig. De basis van Apache Kafka en streamverwerking op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 1 van 4.

Hoe lang duurt de les “Ontwerpen voor hoge doorvoer”?

De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.

Kan ik code schrijven en uitvoeren in deze les over De basis van Apache Kafka en streamverwerking?

Ja. Elke les over De basis van Apache Kafka en streamverwerking bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.

Alle lessen in deze cursus

← Terug naar De basis van Apache Kafka en streamverwerking