2016-04-07 9 views

Antwort

4

die Strömung wird so etwas wie dieses:

  1. Sagen Sie Ihre aktuellen Offset 100 ist, aber aufgrund der Aufbewahrungsfrist der früheste Offset verfügbar ist 110
  2. Ihr Consumer sendet eine FetchRequest Anforderung von Nachrichten von Offset 100.
  3. Kafka gibt einen Fehler (OFFSET_OUT_OF_RANGE um genau zu sein) zurück.
  4. Ihr Kunde reagiert auf diesen Fehler, indem er eine OffsetRequest sendet, die angibt, auf welchen Wert er zurückgesetzt werden soll, sagen wir, in Ihrem Fall ist es EARLIEST.
  5. Kafka gibt eine OffsetResponse mit verfügbaren Offset, 110 in Ihrem Fall.
  6. Ihr Benutzer setzt den aktuellen Offset zwangsweise auf 110 und beginnt erneut, den Abruf zu starten.
+0

Danke für Ihre Freigabe. Eine Sache, die ich bestätigen muss ist, dass, wenn ich High-Level-API verwende, der obige Offset-Reset-Flow für den Kunden transparent ist und nicht vom Endbenutzer kontrolliert werden kann? –

+0

BTW, ich benutze alte Verbraucher mit High-Level-API. –

+1

@BrianLing Dies gilt sowohl für alte als auch für neue Verbraucher. Ich bin nicht ganz klar mit Ihrer ersten Frage, aber von dem, was ich verstanden habe - dieser Prozess wird nicht vom Endbenutzer kontrolliert und passiert automatisch und unter der Haube. Der Endbenutzer könnte nicht einmal wissen, dass der Offset zurückgesetzt wurde. – serejja

0

obwohl der Code aussah: (kafka 0.9 Verbraucher) gibt es resetStrategy definiert, wenn neue Verbraucher

public enum OffsetResetStrategy { 
    LATEST, EARLIEST, NONE 
} 

so erstellt wird, wenn außerhalb des Bereichs versetzt, als consmer weiterhin diese Politik

accoding Lesen
Verwandte Themen