Le migliori pratiche per i clienti Kafka

Disponibilità dei produttori

• Impostato retries per indicare al produttore di riprovare a inviare messaggi non riusciti durante il failover del broker. Consigliamo un valore intero massimo o un valore elevato simile per la maggior parte dei casi d'uso. In caso contrario, l'elevata disponibilità di Kafka verrà interrotta.

• Imposta delivery.timeout.ms per specificare il limite superiore per il tempo totale tra l'invio di un messaggio e la ricezione di una conferma dal broker. Ciò dovrebbe riflettere i requisiti aziendali relativi alla durata di validità di un messaggio. Imposta il limite di tempo sufficientemente alto da consentire un numero sufficiente di tentativi per completare l'operazione di failover. Si consiglia un valore pari o superiore a 60 secondi per la maggior parte dei casi d'uso.

• Impostato request.timeout.ms al valore massimo, una singola richiesta deve attendere prima di tentare un nuovo invio. Consigliamo un valore pari o superiore a 10 secondi per la maggior parte dei casi d'uso.

• Imposta retry.backoff.ms per configurare il ritardo tra i tentativi per evitare tempeste di tentativi e impatto sulla disponibilità. Consigliamo un valore minimo di 200 ms per la maggior parte dei casi d'uso.

• Imposta acks=all per configurare una durabilità elevata; questo dovrebbe essere in linea con una configurazione lato server di RF=3 e min.isr=2 garantire che tutte le partizioni riconoscano la scrittura. ISR Durante un singolo broker offline, questo è ilmin.isr, cioè. 2

Disponibilità dei consumatori

• Impostata latest inizialmente auto.offset.reset per gruppi di consumatori nuovi o ricreati. In questo modo si evita il rischio di aggiungere carico al cluster consumando l'intero argomento.

• Impostato auto.commit.interval.ms quando si utilizzaenable.auto.commit. Si consiglia un valore minimo di 5 secondi per la maggior parte dei casi d'uso per evitare il rischio di carico aggiuntivo.

• Implementa la gestione delle eccezioni all'interno del codice di elaborazione dei messaggi del consumatore per gestire errori transitori, ad esempio un interruttore automatico o una sospensione con back-off esponenziale. In caso contrario, si possono verificare arresti anomali dell'applicazione, con conseguente riequilibrio eccessivo.

• Imposta isolation.level per controllare la modalità di lettura dei messaggi transazionali:

  Per impostazione predefinita, consigliamo di impostare sempre in read_uncommitted modo implicito. Questo non è presente in alcune implementazioni client.

  Quando si utilizza lo storage su più livelli, read_uncommitted si consiglia un valore pari a.

• client.rackImpostare per utilizzare la lettura della replica più vicina. Si consiglia di impostare su per ridurre az id al minimo i costi e la latenza del traffico di rete. Consulta Riduci i costi del traffico di rete dei tuoi MSK consumatori Amazon con la consapevolezza dei rack.

I consumatori si riequilibrano

• Imposta su session.timeout.ms un valore maggiore del tempo di avvio di un'applicazione, incluso qualsiasi jitter di avvio implementato. Consigliamo un valore di 60 secondi per la maggior parte dei casi d'uso.

• Imposta heartbeat.interval.ms per perfezionare il modo in cui il coordinatore del gruppo considera un consumatore sano. Consigliamo un valore di 10 secondi per la maggior parte dei casi d'uso.

• Imposta un gancio di spegnimento nell'applicazione per chiudere il consumatore senza problemiSIGTERM, anziché affidarti ai timeout delle sessioni per identificare quando un consumatore abbandona un gruppo. Le applicazioni Kstream possono impostare un valore di. internal.leave.group.on.close true

• Impostato group.instance.id su un valore distinto all'interno del gruppo di consumatori. Idealmente un nome host, un task-id o un pod-id. Consigliamo di impostarlo sempre per comportamenti più deterministici e una migliore correlazione tra log client/server durante la risoluzione dei problemi.

• Impostato su group.initial.rebalance.delay.ms un valore in linea con il tempo medio di implementazione. In questo modo si interrompono i ribilanciamenti continui durante l'implementazione.

• Impostato partition.assignment.strategy per utilizzare gli assegnatori permanenti. Consigliamo l'uno o l'altro. StickyAssignor CooperativeStickyAssignor

Prestazioni del produttore

• Impostato linger.ms per controllare la quantità di tempo che un produttore attende per il riempimento di un batch. I batch più piccoli sono costosi dal punto di vista computazionale per Kafka in quanto si traducono in più thread e operazioni di I/O contemporaneamente. Consigliamo i seguenti valori.

  Un valore minimo di 5 ms per tutti i casi d'uso, inclusa la bassa latenza.

  Consigliamo un valore più alto di 25 ms, per la maggior parte dei casi d'uso.

  Si consiglia di non utilizzare mai un valore pari a zero in casi d'uso a bassa latenza. (Un valore pari a zero in genere causa latenza indipendentemente dal sovraccarico di I/O).

• Impostato batch.size per controllare la dimensione del batch inviato al cluster. Si consiglia di aumentarlo a un valore di 64 KB o 128 KB.

• Impostato buffer.memory quando si utilizzano batch di dimensioni maggiori. Consigliamo un valore di 64 MB per la maggior parte dei casi d'uso.

• Impostato send.buffer.bytes per controllare il TCP buffer utilizzato per ricevere i byte. Consigliamo un valore pari a -1 per consentire al sistema operativo di gestire questo buffer quando si esegue un produttore su una rete ad alta latenza.

• Imposta compression.type per controllare la compressione dei batch. Consigliamo lz4 o zstd di eseguire un produttore su una rete ad alta latenza.

Prestazioni per i consumatori

• Impostato fetch.min.bytes per controllare la dimensione minima di recupero valida per ridurre il numero di recuperi e il carico del cluster.

  Consigliamo un valore minimo di 32 byte per tutti i casi d'uso.

  Si consiglia un valore più alto di 128 byte per la maggior parte dei casi d'uso.

• Imposta fetch.max.wait.ms per determinare per quanto tempo il consumatore aspetterà prima che fetch.min.bytes venga ignorato. Consigliamo un valore di 1000 ms per la maggior parte dei casi d'uso.

• È consigliabile che il numero di utenti sia almeno uguale al numero di partizioni.

• Impostato receive.buffer.bytes per controllare il TCP buffer utilizzato per ricevere i byte. Consigliamo un valore pari a -1 per consentire al sistema operativo di gestire questo buffer quando si esegue un consumer su una rete ad alta latenza.

Connessioni client

Il ciclo di vita delle connessioni ha un costo computazionale e di memoria su un cluster Kafka. Troppe connessioni create contemporaneamente causano un carico che può influire sulla disponibilità di un cluster Kafka. Questo impatto sulla disponibilità può spesso portare le applicazioni a creare ancora più connessioni, causando così un errore a cascata, con conseguente interruzione completa. È possibile ottenere un numero elevato di connessioni se create a una velocità ragionevole.

Consigliamo le seguenti mitigazioni per gestire alti tassi di creazione di connessioni:

• Assicurati che il meccanismo di distribuzione delle applicazioni non riavvii tutti i produttori/consumatori contemporaneamente, ma preferibilmente in batch più piccoli.

• A livello di applicazione, lo sviluppatore deve assicurarsi che venga eseguito un jitter casuale (random sleep) prima di creare un client di amministrazione, un client di produzione o un client consumer.

• InoltreSIGTERM, quando si chiude la connessione, è necessario eseguire uno sleep casuale per garantire che non tutti i client Kafka vengano chiusi contemporaneamente. Il sonno casuale deve avvenire entro il timeout precedente al verificarsi. SIGKILL

  Esempio A (Java)

  sleepInSeconds(randomNumberBetweenOneAndX);
                          this.kafkaProducer = new KafkaProducer<>(this.props);

  Esempio B (Java)

  Runtime.getRuntime().addShutdownHook(new Thread(() -> {
      sleepInSeconds(randomNumberBetweenOneAndTwentyFive);
      kafkaProducer.close(Duration.ofSeconds(5));
  });

• A livello di applicazione, lo sviluppatore deve assicurarsi che i client vengano creati una sola volta per applicazione secondo uno schema singleton. Ad esempio, quando si utilizza lambda, il client deve essere creato in un ambito globale e non nel gestore del metodo.

• Consigliamo di monitorare il numero di connessioni con l'obiettivo di rimanere stabile. creation/close/shiftLa connessione è normale durante le implementazioni e il failover del broker.

Metriche del produttore

• byte-rate

• record-send-rate

• records-per-request-avg

• acks-latency-avg

• request-latency-avg

• request-latency-max

• record-error-rate

• record-retry-rate

• frequenza di errore

Metriche relative ai consumatori

• records-consumed-rate

• bytes-consumed-rate

• frequenza di recupero

• records-lag-max

• record-error-rate

• fetch-error-rate

• tasso di sondaggio

• rebalance-latency-avg

• tasso di commissione

Metriche comuni

• connection-close-rate

• connection-creation-rate

• numero di connessioni