Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Kafka ist nicht nur ein Autor

Kafka ist nicht nur ein Autor

Kafka ist als Heilsbringer für asynchrone Kommunikation in aller Munde. Aber was steckt wirklich dahinter? Wir zeigen, wie Kafka funktioniert und wo Gemeinsamkeiten und Unterschiede zu vorhandenen Queueing-Lösungen liegen. Wir stellen dar, in welchen Anwendungsfällen diese Eigenschaften einen Mehrwert liefern.

Flah-Uddin Ahmad ist bei Hermes Germany als Solution Architect tätig.
Mit seinem Team bewertet er IT-Innovationen auf ihre Einsatzmöglichkeiten bei Hermes, hat einen Überblick über die IT-Landschaft, entwickelt Zielarchitekturen und unterstützt bei deren Umsetzung. Aktueller Schwerpunkt: Kafka im Kontext ereignisorientierter Architektur

Hermes Germany GmbH

March 28, 2019
Tweet

More Decks by Hermes Germany GmbH

Other Decks in Technology

Transcript

  1. Inhalt 01 Ein kurzer Überblick über Hermes Germany 02 Was

    ist überhaupt Apache Kafka? 03 Wer nutzt alles Kafka? 04 Anwendungsmöglichkeiten von Kafka 05 Wie wird Kafka bei Hermes verwendet? 06 Kernkonzepte von Kafka 07 Unterschiede zwischen Kafka und Queueing-Lösungen 08 Live Demo
  2. Hermes Germany ist einer der größten Paket-Logistiker Deutschlands. • Gegründet

    1972 • Wir stellen derzeit etwa 400 Millionen Pakete pro Jahr zu • Wir stellen uns mit 250 IT-Spezialisten den Herausforderungen der Logistik • Wir sind Teil der Otto-Gruppe • Neben Privatkunden sind unsere Hauptkunden Otto, Amazon, H&M und Zalando
  3. Was ist überhaupt Apache Kafka? 7 Verteilte Streaming Plattform Drei

    Haupteigenschaften • Publish / Subscribe • Fehlertoleranz • Garantierte Reihenfolge Aktuelle Version 2.1.1 (Feb 15, 2019) Entwickelt in Scala / Java
  4. Historie von Kafka 8 Entwickelt von LinkedIn • Open Source

    seit 2011 • Seit 2012 Teil der Apache Foundation Confluent • Gegründet im Jahr 2014 • Fokussiert sich auf die Weiterentwicklung von Kafka
  5. Kafka als Messaging System 15 Message Queue Lastverteilung Kein Multi-Subscriber

    Publish / Subscribe Multi Subscriber Keine Lastverteilung Kafka vereint beide Vorteile => Consumer Groups
  6. Kafka als Storage System 16 • Jedes Messaging System, das

    ohne Kopplung Nachrichten erzeugen und lesen kann • Alle Daten werden in Kafka auf die Festplatte geschrieben und für die Ausfallsicherheit repliziert • Kafka bietet für Producer ein Acknowledgement an => Persistierung erfolgreich • Kafka verhält sich gleich egal, ob auf dem Server 50KB oder 50TB persistenter Daten liegen • Kafka kann als verteiltes, hoch performantes Dateisystem mit niedriger Latenz und Replizierung angesehen werden
  7. Kafka für Stream Processing 17 • Es reicht nicht aus

    Datenströme lesen, schreiben und speichern zu können • Der Zweck ist die Echtzeit-Verarbeitung von Streams • Ein Stream Processor in Kafka ist alles was: 1. Kontinuierliches Lesen von Daten aus einem Input-Topic 2. Manipulation der gelesenen Daten in beliebiger Form 3. Schreiben der modifizierten Daten in einen Output-Topic
  8. Kafka hat 4 Kern-APIs 23 • Producer API • Consumer

    API • Streams API • Connector API
  9. Apache ZooKeeper 24 • Koordinator für verteilte Systeme • Managt

    das Kafka Cluster • Kafka läuft nicht ohne Aufgaben • Leadership election • Broker & Topic • Service discovery • Topologie • Neuer Broker gejoined • Broker nicht länger erreichbar • Neues Topic oder Topic gelöscht ZooKeeper Cluster
  10. Topics & Partitions 25 • Topics sind eine Kernabstraktion in

    Kafka • Topic = Stream von Records • Ein Topic hat einen eindeutigen Namen im Cluster • Topics sind immer Multi-Subscriber fähig • Jedes Topic in Kafka besteht aus mindestens einer Partition • Jede Partition ist geordnet und eine unveränderbare Sequenz von Records • Jedem Record wird eine sequentielle ID innerhalb der Partition zugewiesen => Offset
  11. Persistence & Retention 26 • Kafka persistiert alle Records für

    einen definierten Zeitraum => Cleanup Policies • Dabei spielt es keine Rolle, ob ein Record consumed wurde oder nicht • Kafka schreibt alle Daten auf die Festplatte • Cleanup Policies • Retention-Time • Retention-Size • Log-Compaction
  12. Log-Compaction Guarantees 27 • Consumer, die mit dem Head mithalten,

    können alle Records sehen • Die Zeitspanne für die Komprimierung kann festgelegt werden • Ordnung bleibt bestehen • Nachrichten werden nur gelöscht • Offset eines Records bleibt immer gleich
  13. Producer 28 • Veröffentlichen Daten in einem Topic ihrer Wahl

    • Senden die Daten direkt zu dem Partition Leader • Jeder Broker kann mitteilen, wer der Leader ist • Producer sind dafür verantwortlich, die Partition für ihre Records auszuwählen • Über einen Key • Random • Round-Robin (Standard)
  14. Consumer 29 • Sind Teil einer Consumer Group • Geben

    den Topic an, welchen sie konsumieren möchten • Partitionen eines Topics werden auf die Consumer in einer Consumer Group aufgeteilt • Eine Partition wird genau einem Consumer zugeordnet
  15. Consumer 31 Was passiert, wenn wir mehr Consumer als Partitionen

    haben? Was passiert, wenn wir mehrere Consumer Groups haben?
  16. Skalierbarkeit durch Partitionierung & Ausfallsicherheit durch Replizierung 33 Producer Kafka

    Cluster Broker 1 Broker 2 Broker 3 Topic 1 Partition 0 Partition 1 Partition 2 Topic 1 Partition 0 Partition 1 Partition 2 Topic 1 Partition 0 Partition 1 Partition 2
  17. Unterschiede zwischen Kafka und Queueing-Lösungen 36 Vergleichsthemen Apache Kafka Message

    Queue Modell Consumer Groups Publish / Subscribe oder Queueing Persistierung Message Retention Time to Live bis Konsumierung Reihenfolge der Nachrichten Fest auf Partitionsebene Fest für genau einem Consumer Verteilungsprinzip Pull Push Skalierbarkeit Design Prinzip Add On Anwendungsmöglichkeit Vielseitig Begrenzt Logik / Intelligenz Dumb Pipes & Smart Endpoints Smart Broker
  18. Live Demo Cloud 38 OTC Docker (AppAgile) Web App Java

    Spring Producer Kafka Cluster Java Spring Consumer