Schaut man sich Kafka im Detail an, wird der Aufbau schnell komplex. Dort gibt es dann Broker, Partitionen, Replica, Leader, Follower und die aus Teil 1 schon bekannten Topics. Aber der Reihe nach: Kafka selbst läuft auf sogenannten Brokern, oft auch Nodes genannt, wobei ein Broker im Prinzip ein Kafka Server ist. Ab zwei oder mehr Brokern spricht man auch von einem Broker Cluster bzw. Kafka Cluster.
Kafka Cluster
Im Prinzip speichern die Broker die Nachrichten oder Daten einfach nur, sodass die Consumer sich diese dann abholen können. Diese Daten werden dazu in Topics unterteilt, sodass nicht jeder Consumer jede Nachricht bedenken muss. Der Producer bestimmt dabei, welche Nachricht in welchem Topic landet. Die Topics müssen dafür vorher manuell erstellt werden.
Interessant wird es, wenn man betrachtet wie die Broker die Nachrichten speichern. Dazu werden die Topics in Partitionen unterteilt. Die gespeicherten Nachrichten in jeder Partition sind nach zeitlichem Eingang sortiert und diese Reihenfolge ist unveränderbar. Die zeitliche Reihenfolge der Nachrichten ist dabei nur per Partition, nicht aber pro Topic sichergestellt. Es sei denn ein Topic hat nur eine Partition. Zur Identifizierung bekommt jede Nachricht eine eindeutige ID, das sogenannte Offset. Dadurch können Consumer ganz gezielt bestimmte Nachrichten abfragen. (siehe Abbildung 2)
Kafka speichert alle Nachrichten über einen einstellbaren Zeitraum und da es eine konstante Skalierung in Bezug zur Datenmenge aufweist, ist auch das Speichern großer Datenmengen über einen längeren Zeitraum kein Problem, zumindest nicht für Kafka.
Ein großer Vorteil der Partitionen ist es, dass die Datenmenge eines Topics größer werden kann als die Speicherkapazität des Brokers. Dies ist in Abbildung 1 in Topic 1 veranschaulicht.
Ausfallsicherheit
Um die Ausfallsicherheit zu gewährleisten, können von den Topics bzw. von den Partitionen Kopien, sogenannte Replicas, erstellt werden. Das ergibt natürlich nur Sinn, wenn es mindestens so viele Broker wie Replicas gibt. Unter allen Brokern, die Kopien einer Replica haben, wird mit Hilfe von Zookeeper bestimmt, wer der Leader wird. Da in Zookeeper die Informationen über den Aufbau des Clusters gespeichert werden. Der Leader bekommt die Nachrichten von den Producern und wird von den Consumern angefragt, wenn sie Nachrichten haben wollen. Außerdem sorgt er dafür, dass die Follower aktuelle Kopien des Leaders haben. In Abbildung 1 sind die Leader die grün umrahmten Partitionen und die schwarzen sind die Follower. Die Partitionen aus Topic 1 haben dabei nichts mit denen aus Topic 2 zu tun.
Consumer
Der letzte hier noch nicht weiter erläuterte Teil von Kafka sind die Consumer. Alle Anwendungen, die Nachrichten von Kafka empfangen, werden als Consumer bezeichnet. Es ist möglich, dass ein einzelner Consumer alle Nachrichten aus einem bestimmten Topic oder aber nur aus bestimmten Partitionen eines Topics lesen kann. Letzteres Szenario entspräche dann eher einer klassischen Message Queue. Mit dem Unterschied, dass auch in diesem Fall der Consumer Nachrichten mehrmals lesen könnte und nicht zwangsweise die Nachrichten in der Reihenfolge lesen muss wie sie auf den Partitionen gespeichert sind.
Dieses Szenario hat allerdings ein Problem. Angenommen wir haben einen Producer, der schneller Nachrichten an das Topic sendet, als unser Programm verarbeiten kann. In diesem Fall würde unser Consumer weiter und weiter beim Konsumieren der Nachrichten zurückfallen und ein merkbarer Lag zwischen Senden und Empfangen würde entstehen, der nicht mehr aufgeholt werden könnte. Hier hätte man jetzt zwei Möglichkeiten. Entweder man optimiert den Consumer (Bessere Hardware oder besserer Code) oder aber man schaltet einen zweiten Consumer dazu, der parallel zum Ersten auch Nachrichten empfangen kann. Um Letzteres implementieren zu können, gibt es bei Kafka die sogenannten Consumer Groups.
Consumer Groups
Ein Consumer kann einer Consumer Group beitreten, die immer einem Topic zugeordnet ist. Innerhalb einer solchen Consumer Group werden eine oder mehrere Partitionen genau einem Consumer zugeordnet. Das heißt ein Consumer kann mehreren Partitionen zugeordnet sein, eine Partition aber immer nur genau einem Consumer. Der Vorteil hierbei liegt in der Parallelität. Je mehr Partitionen ein Topic hat, desto mehr Nachrichten können parallel von einer Consumer Group empfangen werden.
Ein weiterer Vorteil Kafkas ist es, dass während der Laufzeit Consumer die Consumer Group verlassen oder hinzukommen können. Jedes Mal wenn dies passiert führt Kafka ein sogenanntes rebalancing aus und verteilt die Partitionen auf alle verfügbaren Consumer. Dabei ist die Parallelität durch die Anzahl der Partitionen beschränkt. Gibt es mehr Consumer als Partitionen, sind diese überschüssigen Consumer solange im Leerlauf.
Im normalen Use Case von Kafka gibt es daher viele Producer (Datenproduzierende Systeme), die in viele verschiedene Topics schreiben. Diese Topics werden dann von Consumern abgerufen, und die Daten werden analysiert, verarbeitet und abgespeichert. Kafka erlaubt hierzu eine extrem hohe Durchsatzrate, kann aber auch als Puffer dienen, falls bei den Consumern mal etwas schief läuft.
