Bewährte Methoden für Apache Kafka-Clients

Verfügbarkeit der Hersteller

• Legt festretries, dass der Producer angewiesen wird, während eines Broker-Failovers erneut zu versuchen, fehlgeschlagene Nachrichten zu senden. Für die meisten Anwendungsfälle empfehlen wir einen Wert von Integer Max oder einen ähnlich hohen Wert. Andernfalls wird die hohe Verfügbarkeit von Kafka beeinträchtigt.

• Legt festdelivery.timeout.ms, dass die Obergrenze für die Gesamtzeit zwischen dem Senden einer Nachricht und dem Empfang einer Bestätigung vom Broker angegeben wird. Dies sollte die geschäftlichen Anforderungen an die Gültigkeitsdauer einer Nachricht widerspiegeln. Stellen Sie das Zeitlimit so hoch ein, dass genügend Wiederholungsversuche möglich sind, um den Failover-Vorgang abzuschließen. Wir empfehlen für die meisten Anwendungsfälle einen Wert von 60 Sekunden oder höher.

• Stellen Sie request.timeout.ms das Maximum ein, das eine einzelne Anfrage warten soll, bevor ein erneutes Senden versucht wird. Für die meisten Anwendungsfälle empfehlen wir einen Wert von 10 Sekunden oder höher.

• Stellen Sie diese Option einretry.backoff.ms, um die Verzögerung zwischen Wiederholungsversuchen zu konfigurieren, um Stürme und Beeinträchtigungen der Verfügbarkeit zu vermeiden. Für die meisten Anwendungsfälle empfehlen wir einen Mindestwert von 200 ms.

• Stellen Sie diese Option einacks=all, um eine hohe Haltbarkeit zu konfigurieren. Dies sollte der serverseitigen Konfiguration von entsprechen RF=3 und sicherstellenmin.isr=2, dass alle Partitionen in ISR den Schreibvorgang bestätigen. Wenn ein einzelner Broker offline ist, ist das dermin.isr, das heißt. 2

Verfügbarkeit für Verbraucher

• Für neue oder neu erstellte Verbrauchergruppen auf latest anfänglich gesetzt. auto.offset.reset Dadurch wird das Risiko einer zusätzlichen Clusterlast vermieden, da das gesamte Thema behandelt wird.

• auto.commit.interval.msWird bei der Verwendung festgelegtenable.auto.commit. Wir empfehlen für die meisten Anwendungsfälle einen Mindestwert von 5 Sekunden, um das Risiko einer zusätzlichen Belastung zu vermeiden.

• Implementieren Sie die Ausnahmebehandlung in den Nachrichtenverarbeitungscode des Verbrauchers, um vorübergehende Fehler zu behandeln, z. B. einen Leistungsschalter oder einen Ruhezustand mit exponentiellem Back-Off. Andernfalls kann es zu Anwendungsabstürzen kommen, was zu einer übermäßigen Neuverteilung führen kann.

• Legen isolation.level Sie fest, wie Transaktionsnachrichten gelesen werden sollen:

  Wir empfehlen, standardmäßig immer read_uncommitted implizit einzustellen. Dies fehlt in einigen Client-Implementierungen.

  Wir empfehlen einen Wert von, read_uncommitted wenn Sie mehrstufigen Speicher verwenden.

• Legen Sie festclient.rack, dass das nächste Replikat gelesen wird. Wir empfehlen, die Einstellung auf den einzustellen, az id um die Kosten für den Netzwerkverkehr und die Latenz zu minimieren. Weitere Informationen finden Sie unter Reduzieren Sie die Kosten für den Netzwerkverkehr Ihrer Amazon MSK-Kunden mithilfe von Rack-Awareness.

Ungleichgewichte bei den Verbrauchern

• Auf session.timeout.ms einen Wert setzen, der größer ist als die Startzeit einer Anwendung, einschließlich eventuell auftretender Startjitter. Wir empfehlen für die meisten Anwendungsfälle einen Wert von 60 Sekunden.

• Hier wird genau festgelegtheartbeat.interval.ms, wie der Gruppenkoordinator einen Verbraucher als gesund einstuft. Wir empfehlen für die meisten Anwendungsfälle einen Wert von 10 Sekunden.

• Setzen Sie einen Shutdown-Hook in Ihrer Anwendung, um den Consumer auf SIGTERM sauber zu schließen, anstatt sich auf Sitzungs-Timeouts zu verlassen, um festzustellen, wann ein Verbraucher eine Gruppe verlässt. Kstream-Anwendungen können auf einen Wert von gesetzt internal.leave.group.on.close werden. true

• Auf group.instance.id einen bestimmten Wert innerhalb der Verbrauchergruppe gesetzt. Idealerweise ein Hostname, eine Task-ID oder eine Pod-ID. Wir empfehlen, diese Einstellung immer einzustellen, um ein deterministischeres Verhalten und eine bessere client/server Log-Korrelation bei der Problembehandlung zu gewährleisten.

• Stellen group.initial.rebalance.delay.ms Sie einen Wert ein, der einer durchschnittlichen Bereitstellungszeit entspricht. Dadurch werden kontinuierliche Neugewichte während der Bereitstellung verhindert.

• Stellen Sie die Verwendung partition.assignment.strategy von Sticky Assignors ein. Wir empfehlen entweder StickyAssignor oderCooperativeStickyAssignor.

Leistung des Produzenten

• Legt festlinger.ms, wie lange ein Hersteller auf die Befüllung einer Charge wartet. Kleinere Chargen sind für Kafka rechenintensiv, da sie zu mehr Threads und Vorgängen gleichzeitig führen. I/O Wir empfehlen die folgenden Werte.

  Ein Mindestwert von 5 ms für alle Anwendungsfälle, einschließlich niedriger Latenz.

  Für die meisten Anwendungsfälle empfehlen wir einen höheren Wert von 25 ms.

  Wir empfehlen, in Anwendungsfällen mit niedriger Latenz niemals den Wert Null zu verwenden. (Ein Wert von Null verursacht in der Regel Latenz, unabhängig vom I/O-Overhead).

• Wird batch.size zur Steuerung der Batchgröße festgelegt, die an den Cluster gesendet wird. Wir empfehlen, diesen Wert auf einen Wert von 64 KB oder 128 KB zu erhöhen.

• buffer.memoryWird gesetzt, wenn größere Chargengrößen verwendet werden. Für die meisten Anwendungsfälle empfehlen wir einen Wert von 64 MB.

• Legt festsend.buffer.bytes, dass der TCP-Puffer gesteuert wird, der zum Empfangen von Bytes verwendet wird. Wir empfehlen den Wert -1, damit das Betriebssystem diesen Puffer verwalten kann, wenn ein Producer in einem Netzwerk mit hoher Latenz läuft.

• Stellen Sie compression.type ein, um die Komprimierung von Batches zu steuern. Wir empfehlen entweder lz4 oder zstd, einen Producer in einem Netzwerk mit hoher Latenz auszuführen.

Leistung für Verbraucher

• Legt festfetch.min.bytes, ob die Mindestabrufgröße gültig ist, um die Anzahl der Abrufe und die Clusterlast zu reduzieren.

  Wir empfehlen für alle Anwendungsfälle einen Mindestwert von 32 Byte.

  Für die meisten Anwendungsfälle empfehlen wir einen höheren Wert von 128 Byte.

• Stellen Sie fetch.max.wait.ms ein, um festzulegen, wie lange Ihr Verbraucher wartet, bis fetch.min.bytes ignoriert wird. Wir empfehlen für die meisten Anwendungsfälle einen Wert von 1000 ms.

• Wir empfehlen, dass die Anzahl der Verbraucher mindestens der Anzahl der Partitionen entspricht, um eine bessere Parallelität und Stabilität zu gewährleisten. Bei Themen mit geringem Durchsatz entscheiden Sie sich möglicherweise dafür, weniger Verbraucher als die Anzahl der Partitionen zu verwenden.

• Legt festreceive.buffer.bytes, dass der TCP-Puffer gesteuert wird, der zum Empfangen von Bytes verwendet wird. Wir empfehlen den Wert -1, damit das Betriebssystem diesen Puffer verwalten kann, wenn ein Consumer in einem Netzwerk mit hoher Latenz läuft.

Client-Verbindungen

Der Lebenszyklus von Verbindungen verursacht auf einem Kafka-Cluster Rechen- und Speicherkosten. Zu viele Verbindungen, die gleichzeitig hergestellt werden, verursachen eine Belastung, die sich auf die Verfügbarkeit eines Kafka-Clusters auswirken kann. Diese Beeinträchtigung der Verfügbarkeit kann oft dazu führen, dass Anwendungen noch mehr Verbindungen herstellen, was zu einem kaskadierenden Ausfall führt, der zu einem vollständigen Ausfall führt. Eine hohe Anzahl von Verbindungen kann erreicht werden, wenn sie mit einer angemessenen Geschwindigkeit hergestellt werden.

Wir empfehlen die folgenden Abhilfemaßnahmen, um hohe Verbindungsaufbauraten zu bewältigen:

• Stellen Sie sicher, dass Ihr Mechanismus zur Anwendungsbereitstellung nicht producers/consumers auf einmal neu gestartet wird, sondern vorzugsweise in kleineren Batches.

• Auf der Anwendungsebene sollte der Entwickler sicherstellen, dass ein zufälliger Jitter (zufälliger Ruhezustand) ausgelöst wird, bevor er einen Admin-Client, Producer-Client oder Consumer-Client erstellt.

• Bei SIGTERM sollte beim Schließen der Verbindung ein zufälliger Schlafmodus ausgeführt werden, um sicherzustellen, dass nicht alle Kafka-Clients gleichzeitig geschlossen werden. Der zufällige Schlaf sollte innerhalb des Timeouts liegen, bevor SIGKILL eintritt.

  Beispiel Beispiel A (Java)

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

  Beispiel Beispiel B (Java)

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

• Auf der Anwendungsebene sollte der Entwickler sicherstellen, dass Clients pro Anwendung nur einmal in einem Singleton-Muster erstellt werden. Wenn Sie beispielsweise Lambda verwenden, sollte der Client im globalen Bereich und nicht im Methodenhandler erstellt werden.

• Wir empfehlen, die Anzahl der Verbindungen zu überwachen, damit sie stabil bleibt. Die creation/close Verbindung/Schicht ist bei Bereitstellungen und Broker-Failover normal.

Kennzahlen für Hersteller

• Byte-Rate

• Senderate von Rekorden

• Durchschnittswert der Datensätze pro Anfrage

• Acks-Latenz-Avg

• Latenz-Durchschnitt anfragen

• Anforderungs-Latenz-Max

• Rekordfehlerrate

• Wiederholungsrate bei Rekordversuchen

• Fehlerrate

Kennzahlen für Verbraucher

• Rate der verbrauchten Datensätze

• Rate der verbrauchten Byte

• Abrufrate

• Rekord-Lag-Max

• Rekordfehlerrate

• Fehlerrate beim Abrufen

• Umfragerate

• Durchschnitt der Rebalance-Latenz

• festschreiben

Allgemeine Metriken

• Rate beim Schließen einer Verbindung

• Geschwindigkeit beim Herstellen einer Verbindung

• Anzahl der Verbindungen