Bewährte Methoden für Kafka-Kunden

Verfügbarkeit durch den 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. Geschieht dies nicht, 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äftsanforderungen für die Gültigkeitsdauer einer Nachricht widerspiegeln. Stellen Sie das Zeitlimit so hoch ein, dass genügend Wiederholungsversuche zum Abschluss des Failover-Vorgangs möglich sind. Für die meisten Anwendungsfälle empfehlen wir einen Wert von 60 Sekunden oder höher.

• Auf das Maximum eingestelltrequest.timeout.ms, das eine einzelne Anfrage warten soll, bevor ein erneuter Sendeversuch unternommen wird. Für die meisten Anwendungsfälle empfehlen wir einen Wert von 10 Sekunden oder höher.

• Stellen Sie retry.backoff.ms diese Option ein, um die Verzögerung zwischen Wiederholungsversuchen zu konfigurieren, um Wiederholungsstürme und Auswirkungen auf die Verfügbarkeit zu vermeiden. Für die meisten Anwendungsfälle empfehlen wir einen Mindestwert von 200 ms.

• Auf hohe Haltbarkeit eingestelltacks=all. Dies sollte einer serverseitigen Konfiguration von entsprechen RF=3 und min.isr=2 sicherstellen, dass alle Partitionen den Schreibvorgang ISR bestätigen. Wenn ein einzelner Broker offline ist, ist das dermin.isr. 2

Verfügbarkeit für Verbraucher

• Für neue oder neu erstellte Verbrauchergruppen latest zunächst auf eingestelltauto.offset.reset. Dadurch wird das Risiko einer zusätzlichen Clusterlast vermieden, da das gesamte Thema verbraucht 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 innerhalb des Nachrichtenverarbeitungscodes des Verbrauchers, um vorübergehende Fehler zu behandeln, z. B. einen Stromausfall oder einen Standbymodus mit exponentiellem Back-off. Andernfalls kann es zu Anwendungsabstürzen kommen, was zu einer übermäßigen Neuverteilung führen kann.

• Legt festisolation.level, wie Transaktionsnachrichten gelesen werden sollen:

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

  Wir empfehlen den Wert von, read_uncommitted wenn Tiered Storage verwendet wird.

• Legt festclient.rack, dass ein Replikat-Lesevorgang verwendet wird, der am nächsten ist. Wir empfehlen die Einstellung auf, az id um die Kosten für den Netzwerkverkehr und die Latenz zu minimieren. Weitere Informationen finden Sie unter Reduzieren Sie die Netzwerk-Traffic-Kosten Ihrer MSK Amazon-Kunden mit Rack Awareness.

Neugewichte bei den Verbrauchern

• Auf session.timeout.ms einen Wert einstellen, der größer ist als die Startzeit einer Anwendung, einschließlich aller implementierten Startjitter. Für die meisten Anwendungsfälle empfehlen wir einen Wert von 60 Sekunden.

• Legt festheartbeat.interval.ms, wie der Gruppenkoordinator einen Verbraucher als gesund einschätzt. Für die meisten Anwendungsfälle empfehlen wir einen Wert von 10 Sekunden.

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

• Auf group.instance.id einen bestimmten Wert innerhalb der Nutzergruppe gesetzt. Idealerweise ein Hostname, eine Task-ID oder eine Pod-ID. Wir empfehlen, diese Einstellung immer einzustellen, um ein deterministischeres Verhalten und eine bessere Korrelation zwischen Client/Server-Protokollen bei der Fehlerbehebung zu erzielen.

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

• partition.assignment.strategySo eingestellt, dass Sticky Assignors verwendet werden. Wir empfehlen entweder StickyAssignor oderCooperativeStickyAssignor.

Leistung des Herstellers

• Legt festlinger.ms, wie lange ein Produzent darauf wartet, dass ein Stapel gefüllt ist. Kleinere Batches sind für Kafka rechenintensiv, da sie zu mehr Threads und I/O-Operationen gleichzeitig führen. Wir empfehlen die folgenden Werte.

  Ein Mindestwert von 5 ms für alle Anwendungsfälle bei 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 normalerweise unabhängig vom I/O-Overhead Latenz).

• Legt festbatch.size, dass die Batchgröße gesteuert wird, die an den Cluster gesendet wird. Wir empfehlen, diesen Wert auf einen Wert von 64 KB oder 128 KB zu erhöhen.

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

• Wird eingestelltsend.buffer.bytes, um den TCP Puffer zu steuern, 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 ausgeführt wird.

• Legen Sie compression.type fest, um die Komprimierung von Batches zu steuern. Wir empfehlen, entweder lz4 oder zstd, einen Producer in einem Netzwerk mit hoher Latenz laufen zu lassen.

Leistung für Verbraucher

• Legt festfetch.min.bytes, welche Mindestgröße für den Abruf gültig sein muss, 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.

• Legen Sie fetch.max.wait.ms fest, um zu bestimmen, wie lange Ihr Kunde warten wird, bis fetch.min.bytes ignoriert wird. Für die meisten Anwendungsfälle empfehlen wir einen Wert von 1000 ms.

• Wir empfehlen, dass die Anzahl der Benutzer mindestens der Anzahl der Partitionen entspricht.

• Wird eingestelltreceive.buffer.bytes, um den TCP Puffer zu steuern, der zum Empfangen von Bytes verwendet wird. Wir empfehlen den Wert -1, damit das Betriebssystem diesen Puffer verwalten kann, wenn ein Verbraucher in einem Netzwerk mit hoher Latenz ausgeführt wird.

Client-Verbindungen

Der Lebenszyklus von Verbindungen verursacht Rechen- und Speicherkosten auf einem Kafka-Cluster. Zu viele Verbindungen, die gleichzeitig hergestellt werden, führen zu einer Belastung, die sich auf die Verfügbarkeit eines Kafka-Clusters auswirken kann. Diese Beeinträchtigung der Verfügbarkeit kann häufig dazu führen, dass Anwendungen noch mehr Verbindungen herstellen und so zu einem kaskadierenden Ausfall führen, 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 alle Produzenten/Verbraucher auf einmal neu startet, sondern vorzugsweise in kleineren Batches.

• Auf der Anwendungsebene sollte der Entwickler sicherstellen, dass ein zufälliger Jitter (zufälliger Ruhemodus) ausgeführt wird, bevor er einen Admin-Client, Producer-Client oder Consumer-Client erstellt.

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

  Beispiel A (Java)

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

  Beispiel B (Java)

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

• Auf Anwendungsebene sollte der Entwickler sicherstellen, dass Clients nur einmal pro Anwendung 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 mit dem Ziel zu überwachen, stabil zu bleiben. Bei Bereitstellungen und Broker-Failover creation/close/shift ist die Verbindung normal.

Metriken für Hersteller

• Byterate

• record-send-rate

• records-per-request-avg

• acks-latency-avg

• request-latency-avg

• request-latency-max

• record-error-rate

• record-retry-rate

• Fehlerrate

Kennzahlen für Verbraucher

• records-consumed-rate

• bytes-consumed-rate

• Abrufrate

• records-lag-max

• record-error-rate

• fetch-error-rate

• Umfragerate

• rebalance-latency-avg

• Commit-Rate

Allgemeine Metriken

• connection-close-rate

• connection-creation-rate

• Anzahl der Verbindungen