Apache Kafka uitgelegd
In dit artikel wordt kort uitgelegd hoe apache kafka onder water in elkaar zit. Handig voor nieuwe gebruikers om kort alle informatie bij elkaar te hebben, of voor bestaande gebruikers die een refresher nodig hebben van de internals.
Basics
Kafka is een geclusterde messaging bus die het mogelijk maakt om grote hoeveelheden aan messages af te handelen. Binnen Kafka wordt per topic een commit log bijgehouden. Producers kunnen aan een topic messages toevoegen en consumers kunnen deze nieuwe messages ophalen als ze aangeven de topic te willen volgen. Een node binnen een Kafka cluster wordt een broker genoemd.
Topics en partitions
Een topic is een categorie of onderwerp waar messages naar gepubliceerd worden. Voor elk topic wordt een gepartitioneerde log bijgehouden die er ongeveer zo uit ziet:
De samenvoeging van deze partities maakt een complete topic log. Elke partitie is een geordende lijst met messages, waarover alle messages van een topic worden verdeeld.
Het gebruik van deze partities maakt het ook makkelijker om de load te balancen over consumer groups. Dit wordt later verder uitgelegd.
Messages
Elke message krijgt een offset toegewezen die de message uniek maakt binnen een partitie en de volgorde van de messages bijhoudt. Aan de hand van deze offset worden ook messages opgehaald door consumers.
Messages worden voor een vaste tijd bijgehouden. Deze tijd kan geconfigureerd worden. Ook als de message door alle consumers is opgehaald zal hij tot de vastgestelde tijd bewaard worden. Daarna zal hij verwijderd worden om ruimte vrij te maken.
Distributie van messages
De partities worden over de brokers verspreid zodat elke server zijn deel van de data en requests kan afhandelen. Elke partitie wordt over een instelbare hoeveelheid brokers gerepliceerd om de fouttolerantie te verlagen.
Elke partitie heeft een “leader” binnen de cluster die alle read en write requests afhandelt, terwijl zijn “followers” passief de partitie repliceren. Als een leader wegvalt zal een nieuwe broker zijn plek als leader innemen.
Producers
Kafka brokers hebben altijd de metadata beschikbaar over waar leaders van een partitie te vinden zijn. Een producer bepaalt zelf naar welke partitie hij zijn informatie stuurt, nadat hij de metadata over de partitie leaders heeft opgehaald bij een broker. Het bepalen naar welke partitie de message wordt gestuurd kan op verschillende manieren gebeuren. Het kan gedaan worden door bijvoorbeeld een round-robin pool, of door een semantische partitie functie.
Om samen te vatten:
Topics zijn te vinden binnen het gehele Kafka cluster, en niet op specifieke brokers.
Topics zijn opgesplitst in partities. Dit zijn delen van de commit log. Elke partitie staat op een broker die is aangeduid als de leader.
Naast een leader zijn er ook een aantal followers, die een kopie van de partitie bijhouden. Zij handelen echter geen reads en writes af, maar zijn er enkel voor het geval de leader wegvalt, waarna ze zijn plek innemen.
Een broker bevat meerdere partities.
Stap voor stap zal het opslaan van een nieuwe message als volgt gaan:
- De producer haalt bij zijn bekende broker de lijst met metadata over partition leaders op.
- De producer bepaalt aan de hand van een partition key of algoritme naar welke partitie hij zijn message stuurt.
- Het message komt aan bij de broker en wordt daar gepersisteerd op disk.
- De broker stuurt de message naar alle replica’s die er bestaan van de partitie.
- De replica’s sturen een bevestiging dat de message is toegevoegd.
Vanaf hier wordt het afhankelijk van de synchronisatievorm hoe het verder verloopt.
6a. Als de primary-backup replicatie wordt gebruikt, wanneer alle replica’s hebben laten weten dat de message succesvol is opgeslagen, zal de broker een bevestiging naar de producer sturen. Als een van de replica’s faalt zal hij uit de lijst met replica’s worden gegooid. Hij kan deze lijst weer terug joinen als hij weer terug up to date is.
6b. Met de quorum-based aanpak wacht de broker tot een bepaald aantal van de replica’s up to date is. Dit aantal replica’s veranderd niet als er replica’s uitvallen. Als er dus te weinig replica’s up zijn, zal de message nooit doorgevoerd worden.
Zookeeper
De rol van Zookeeper is het beheren van een cluster van Kafka nodes. Zookeeper houdt ook informatie bij over de locaties van partities, en de bijbehorende leaders. Ook handelt Zookeeper het kiezen van een nieuwe leader broker af.
Hiernaast houdt Zookeeper de verbindingen van consumers met brokers bij. Zookeeper zorgt ervoor dat consumers binnen een consumer group verdeeld worden over de partities van een topic en dat consumers opnieuw verdeeld worden bij het wegvallen van een consumer of broker.
Consumers
Binnen Kafka bestaan er consumer groups. Een consumer group is een logische consumer van berichten. Een consumer binnen deze group is een instantie of thread van deze logische consumer. Alle consumers binnen een consumer group krijgen berichten binnen. Elke consumer binnen een consumergroup krijgt een partitie toegewezen van een topic. Dit houdt ook in dat er niet meer consumers binnen een consumer group kunnen zitten dan dat er partities zijn van het topic.
Het is handig om te weten dat messages binnen een partitie gesorteerd zijn op offset. Als een topic over meerdere partities verdeeld is, zijn de messages alleen binnen deze partitie geordend. Als het belangrijk is dat alle messages op volgorde blijven, kan er dus maar een partitie aangemaakt worden. Dit zal het echter onmogelijk maken om parallel te werken.