Herausforderung 1: System B ist nicht erreichbar, z. B. aufgrund eines Wartungsfensters oder wegen Netzwerkproblemen. System A hat aber nicht die Kapazität, Nachrichten so lange zu puffern, bis B wieder verfügbar ist.

Herausforderung 2: System A könnte System B mit unzähligen Nachrichten überhäufen und System B damit in die Knie zwingen (DoS).

Ein Topic in Kafka bezeichnet die logische Instanz, zu der Nachrichten gesendet werden können und von welcher gelesen werden kann. Nachrichten werden als Records bezeichnet. Widmen wir uns aber zunächst den Topics: Sie sind der eigentliche Kernbestandteil von Kafka. Haben wir zum Beispiel Sensordaten von Maschinen, die wir von A nach B bringen wollen, könnten wir ein Topic sensor_data erzeugen. Unser Topic besteht dabei aus mehreren Partitionen, die konkrete Anzahl ist konfigurierbar. Eine Erläuterung über den Sinn von Partitionen erfolgt später im Text. Im einfachen Fall haben wir einen Kafka Broker auf einem Server mit drei Partitionen. 

Der Producer, hier die Maschinen, entscheiden welche Datensätze in welche Partition geschrieben werden. In einigen Anwendungsfällen kann das relevant sein, oft jedoch genügt es, die Partitionen mittels Round-Robin-Verfahren einfach gleichmäßig auszulasten.

Innerhalb der Partition ist eine Nachricht als Offset gekennzeichnet. Dies ist eine aufsteigende Zahl, die jede Nachricht innerhalb einer Partition eindeutig identifiziert. In Abb.6 wurden im Topic insgesamt 20 Nachrichten gespeichert. Die nächsten Nachrichten werden nun entweder mit dem Offset "7" in Partition 1 oder 3 gespeichert oder als "6" in Partition 2.

Kafka speichert die eingehenden Nachrichten übrigens immer auf der Festplatte, Kafka ist also kein "In-Memory"-System, aber dennoch hoch performant. Da die Festplattenauslastung steigt, je länger das System läuft, müssen Nachrichten von Zeit zu Zeit auch wieder gelöscht werden. Um den Speicherbedarf kontrollierbar zu halten, bietet Kafka drei Cleanup Policies:

• Retention-Time: Die ältesten Daten werden frühestens nach einer frei definierbaren Zeit gelöscht.
• Retention-Size: Die ältesten Daten werden frühestens gelöscht, sobald der Speicherbedarf der Nachrichten eine definierte Größe erreicht hat.
• Log-Compaction: Es werden nur Nachrichten gelöscht, deren Schlüssel mehrfach vorkommt und niemals die neueste Nachricht mit dem Schlüssel.

Standardmäßig wird die Retention-Time verwendet und Nachrichten werden nach sieben Tagen gelöscht.

Um Nachrichten aus dem Topic zu lesen wird die Consumer API verwendet. Ein wichtiges Faktum ist hier, dass die Nachrichten nicht per Push-Verfahren an die Consumer geliefert werden, sondern dass die Consumer die Nachrichten aktiv beim Topic abholen. Dies ist auch bei anderen Messaging-Systemen gängige Praxis, da der Consumer auf diese Weise die Nachrichten in der Geschwindigkeit lesen kann, in der er diese auch verarbeiten kann. Consumer sind außerdem in der Lage, nicht nur die neueste, nicht gelesene Nachricht abzuholen, sondern jede Nachricht die sich noch in der Partition und damit auf der Festplatte befindet, und die noch nicht durch die Cleanup Policies entfernt wurde.

Das wichtigste Thema dabei ist die Entscheidung, wie die Nachrichten analog der anfangs definierten Differenzierung zu behandeln sind: Sollen die Nachrichten eher queue- oder eher topic-artig werden? Kafka bietet hier mit dem Konzept der Consumer Groups beide Möglichkeiten.

Jeder Consumer kann zu einer Consumer Group gehören. Dabei wird jede Nachricht im Kafka Topic von einer Consumer Group nur insgesamt einmal gelesen. Sprich: Haben zwei Consumer die gleiche Consumer Group und lesen beide aus dem gleichem Topic, lesen beide niemals die gleiche Nachricht, sondern immer verschiedene Nachrichten. In der Praxis sind diese beiden Consumer keine unterschiedlichen Programme, sondern z. B. zwei Threads eines Programmes oder ein auf einem Hadoop-Cluster deployter Job. Ein typischer Anwendungsfall wäre hier die Lambda-Architektur [3], bei der alle Daten sowohl vom Speed-Layer als auch vom Batch-Layer für die In-Memory-Verarbeitung gelesen werden. 

Abb.7 verdeutlicht die Verteilung der Nachrichten (symbolisiert durch die drei Briefumschläge) an zwei Consumer-Applikationen die in jeweils zwei Threads laufen. Dabei hat jede Applikation eine eigene Consumer Group.

Damit kommen wir nun auch zurück zu den Partitionen. Wir erinnern uns: Ein Topic besteht aus mehreren Partitionen und Producer bestimmen die Verteilung der Daten zwischen den Partitionen. Da wir nun wissen, dass es mehrere Consumer innerhalb einer Consumer Group gibt (es sei denn, man implementiert eine nicht geclusterte Single-Thread-Applikation), stellt sich die Frage, aus welchen Partitionen die Consumer lesen. Ein Consumer kann aus mehreren Partitionen lesen, eine Partition hingegen kann nur von exakt einem Consumer einer Consumer Group gelesen werden.

Betrachten wir das Beispiel in Abb.8. Wir haben ein Topic mit drei Partitionen und eine Applikation, die in vier Threads läuft, welche sinnvoller Weise alle die gleiche Consumer Group haben (da die Applikation andernfalls Nachrichten mehrfach aus dem Topic abholen würde). Da wir nun aber nur drei Partitionen haben, wird Thread 4 nicht mehr bedient und erhält somit keine Daten. Analog verhält sich der umgekehrte Fall: Hätten wir hier nur zwei Threads, würde ein Thread die Daten aus Partition 1 bekommen und der andere die Daten aus Partition 2 und 3. Letzterer würde also – vorausgesetzt der Producer hat die Daten gleichmäßig über die Partitionen verteilt – doppelt so viele Daten bekommen wie der andere. Kafka hat hierfür eine Lösung parat: Es ist möglich, zur Laufzeit die Anzahl der Partitionen eines Topics zu erhöhen.