Grundlag i Apache Kafka og strømbehandling · Lektion

Design til højt gennemløb

Lær arkitektoniske overvejelser og bedste praksis for opbygning af Kafka-baserede systemer, der håndterer enorme datamængder.

Lektion 1 af 413 trin

Design til højt gennemløb er en gratis Grundlag i Apache Kafka og strømbehandling-lektion på CoddyKit. Dette er lektion 1 af 4. Du kan læse alle 3 lektioner i dette læringsspor gratis i deres fulde længde — derefter låser CoddyKit PRO alle lektioner op samt praktiske øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Den er en del af læringsforløbet i Grundlag i Apache Kafka og strømbehandling, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. Grundlag i Apache Kafka og strømbehandling-kurset indeholder 4 lektioner i alt.

Hvad er høj gennemstrømning?

I Kafka betyder høj gennemstrømning, at dit system effektivt kan behandle en enorm mængde data pr. sekund eller minut. Det er afgørende for applikationer som analyse i realtid, indsamling af IoT-data og sammenlægning af logfiler, hvor data ankommer kontinuerligt med høj hastighed.

Hvis du designer med henblik på høj gennemstrømning, sikrer du, at din Kafka-klynge og dine applikationer kan håndtere spidsbelastninger uden forringet ydeevne, datatab eller betydelige forsinkelser.

Vigtige faktorer for gennemstrømning

Høj gennemstrømning i Kafka opnås ved at optimere flere indbyrdes forbundne komponenter. Tænk på det som en kæde – det svageste led begrænser den samlede hastighed.

  • Producenter: Hvor effektivt de sender data.
  • Brokere: Hvor hurtigt de gemmer og leverer data.
  • Forbrugere: Hvor hurtigt de læser og behandler data.
  • Infrastruktur: Netværksbåndbredde og hastigheden for disk-I/O.

Optimering af producenten: Samling i partier

Det er ineffektivt at sende meddelelser én ad gangen. Producenter kan samle meddelelser i partier og sende flere poster i en enkelt anmodning. Det reducerer netværksoverhead og forbedrer gennemstrømningen.

  • batch.size: Den maksimale størrelse i byte for et enkelt parti.
  • linger.ms: Den maksimale tid, en producent venter, før den sender et parti, selv hvis det ikke er fuldt.

Justering af disse indstillinger skaber en balance mellem latenstid (hvor hurtigt en meddelelse sendes) og gennemstrømning (hvor mange meddelelser der sendes over tid).

Eksempel på en producent med partier

Sådan konfigurerer du en producent til at samle meddelelser i partier. Bemærk indstillingerne batch.size og 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.");
        }
    }
}

Producentkomprimering og ACK'er

Ud over samling i partier har to andre producentindstillinger stor indflydelse på gennemstrømningen:

  • compression.type: Komprimering af data (f.eks. gzip, snappy, lz4) reducerer brugen af netværksbåndbredde og diskplads. Det gør det muligt at sende og gemme flere data, hvilket øger den effektive gennemstrømning.
  • acks: Styrer garantien for holdbarhed. acks=0 (send og glem) giver den højeste gennemstrømning, men den laveste holdbarhed. acks=1 (lederen kvitterer) er en god balance. acks=all (alle synkroniserede replikaer kvitterer) giver den højeste holdbarhed, men den laveste gennemstrømning.

Skalering af brokere: Partitionering og diske

Kafka-brokere er rygraden. Deres gennemstrømning afhænger i høj grad af:

  • Partitioner: Hver partition i et emne er en ordnet log. Flere partitioner giver større parallelitet ved både skrivning og læsning af data på tværs af brokere og forbrugere. Fordel partitionerne jævnt mellem brokere.
  • Disk-I/O: Kafka bruger disken intensivt. Brug af hurtige SSD'er og konfiguration af RAID 0 eller RAID 10 til datamapper forbedrer skrive- og læsehastighederne betydeligt, hvilket er afgørende for høj gennemstrømning.

Brokeres netværk og CPU

Du må ikke overse den underliggende hardware for dine brokere:

  • Netværk: Højhastighedsnetværksgrænseflader (f.eks. 10 Gigabit Ethernet) og tilstrækkelig båndbredde er afgørende. Brokere flytter konstant data mellem hinanden (replikering) og mellem sig selv og klienter.
  • CPU: Selvom Kafka er optimeret til sekventiel disk-I/O, kan CPU'en blive en flaskehals, især ved omfattende datakomprimering og -dekomprimering, SSL-kryptering eller komplekse ACL'er. Sørg for et tilstrækkeligt antal CPU-kerner.

Optimering af forbrugeren: Hentning i partier

Forbrugere har også fordel af samling i partier. I stedet for at spørge efter én post ad gangen henter forbrugere et parti poster.

  • max.poll.records: Det maksimale antal poster, der returneres i et enkelt kald til poll(). Behandling af flere poster pr. forespørgsel reducerer overheadet fra gentagne kald.
  • fetch.min.bytes: Den mindste datamængde (i byte), som forbrugeren venter på at modtage fra en broker, før den returnerer.
  • fetch.max.wait.ms: Den maksimale tid (i ms), som forbrugeren venter på, at fetch.min.bytes bliver opfyldt.

Eksempel på en forbruger med partier

En forbruger, der er konfigureret til at hente partier, henter flere poster pr. kald til poll(), hvilket forbedrer behandlingseffektiviteten.

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();
                }
            }
        }
    }
}

Parallel behandling hos forbrugeren

Selvom max.poll.records hjælper med hentningen, kan selve behandlingen af meddelelser blive en flaskehals. Sådan maksimerer du forbrugerens gennemstrømning:

  • Intern trådpulje: Implementer en trådpulje i din forbrugerapplikation. Når poll() returnerer et parti poster, sender du posterne til trådpuljen til parallel behandling.
  • Omhyggelig håndtering af offset: Hvis du behandler parallelt, skal du kun bekræfte offsets, efter at alle meddelelser i et parti (eller en bestemt delmængde) er behandlet korrekt. Ellers risikerer du datatab eller gentagen behandling.

Overvågning af målinger for gennemstrømning

Kontinuerlig overvågning er afgørende for at identificere flaskehalse i gennemstrømningen. Vigtige målinger, du bør holde øje med:

  • Producent: Anmodningshastighed, bytehastighed og anmodningslatenstid.
  • Forbruger: Hentehastighed, bytehastighed og forbrugerforsinkelse (det vigtigste for at identificere flaskehalse i behandlingen).
  • Broker: Disk-I/O (læsning/skrivning), netværks-I/O, CPU-udnyttelse og hukommelsesforbrug.
  • Netværk: Udnyttelse af båndbredde og pakketab.

Værktøjer som JMX, Prometheus/Grafana eller Confluent Control Center kan hjælpe med at visualisere disse målinger.

Udfordring: Optimering af gennemstrømning

Du har lært om forskellige strategier til at øge gennemstrømningen i Kafka-systemer. Hvilke af følgende handlinger vil generelt hjælpe med at øge den samlede gennemstrømning i en databehandlingskæde baseret på Kafka?

Opsummering: Design med henblik på gennemstrømning

Tillykke! Du har udforsket vigtige strategier til at designe Kafka-baserede systemer, der kan håndtere enorme datamængder med høj gennemstrømning.

  • Optimér producenter med samling i partier, komprimering og passende indstillinger for `acks`.
  • Skalér brokere ved at bruge tilstrækkeligt mange partitioner, hurtige diske og rigelige netværks- og CPU-ressourcer.
  • Justér forbrugere med hentning i partier, og implementer intern parallelisme til behandlingen.
  • Overvåg kritiske målinger for proaktivt at identificere og håndtere flaskehalse.

Det er afgørende at beherske disse teknikker for at bygge robuste og velfungerende dataplatforme i realtid.

Gratis at komme i gang

Lær Grundlag i Apache Kafka og strømbehandling med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser
12
Lektioner
48

Ofte stillede spørgsmål

Er lektionen “Design til højt gennemløb” gratis?

Ja — alle 3 lektioner i læringssporet Grundlag i Apache Kafka og strømbehandling, inklusive “Design til højt gennemløb”, kan læses gratis i deres fulde længde her på webstedet. Derefter låser CoddyKit PRO alle lektioner op samt interaktive øvelser med en indbygget kodeeditor og en AI-underviser døgnet rundt. Grundlag i Apache Kafka og strømbehandling-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Design til højt gennemløb”?

Lær arkitektoniske overvejelser og bedste praksis for opbygning af Kafka-baserede systemer, der håndterer enorme datamængder. Du øver dig i Grundlag i Apache Kafka og strømbehandling med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på Grundlag i Apache Kafka og strømbehandling?

Der kræves ingen tidligere erfaring. Grundlag i Apache Kafka og strømbehandling på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 1 af 4.

Hvor lang tid tager lektionen “Design til højt gennemløb”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne Grundlag i Apache Kafka og strømbehandling-lektion?

Ja. Alle Grundlag i Apache Kafka og strømbehandling-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

  1. Design til højt gennemløb
  2. Katastrofeberedskab og georeplikering
  3. Fremtidige tendenser inden for streambehandling
  4. Backpressure og flow control i stor skala
← Tilbage til Grundlag i Apache Kafka og strømbehandling