Apache Kafka: Lessons learned
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/45778 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FrOSCon 201892 / 94
3
7
9
10
13
14
16
19
21
23
25
28
29
30
31
32
33
36
37
39
40
41
43
44
46
48
49
50
53
54
57
67
75
76
77
80
81
85
90
91
92
93
00:00
Apache <Programm>HTTPApache <Programm>Computing platformSoftwareXMLUMLLecture/Conference
00:43
APIMental calculationConfiguration spaceApache <Programm>SoftwareConfiguration spaceSlide ruleBlock (periodic table)XML
02:57
Computing platformPlatteXML
04:30
Binary fileClefPartition (number theory)RoutingDatabaseServer (computing)AlgorithmTable (information)InformationDiagram
06:08
Three-dimensional spaceServer (computing)Replication (computing)Partition (number theory)Lecture/Conference
07:05
Partition (number theory)Server (computing)Slide ruleTape driveHard disk driveDiagram
08:21
Partition (number theory)InternetSlide ruleLecture/ConferenceComputer animation
09:24
DatabasePartition (number theory)Lecture/Conference
10:48
Service (economics)LoginUpdateSpeciesSoftwareDatabaseLoginTape driveGateway (telecommunications)Web serviceOrder (biology)ACCESS <Programm>Event horizonPostgreSQLLogarithmAPIProzessorProgram flowchartLecture/Conference
13:26
APITape driveNetwork topologyGoogleEigenvalues and eigenvectorsDiagramProgram flowchart
15:11
makeEigenvalues and eigenvectorsMechanism designDrag (physics)Lecture/Conference
15:53
Version <Informatik>Limit (category theory)Version <Informatik>ClefConfiguration spacePartition (number theory)XMLComputer animation
16:45
Disk read-and-write headEmpennagePartition (number theory)Disk read-and-write headElectronic visual displayEckeLecture/ConferenceComputer animation
18:38
Disk read-and-write headEmpennageBitStructural loadPartition (number theory)Thread (computing)EmpennageLecture/ConferenceComputer animation
20:06
EmpennageDisk read-and-write headEmpennageConfiguration spaceComputer animationXML
20:56
E-bookSpoke-hub distribution paradigmVersion <Informatik>Computer animationLecture/Conference
21:55
Mental calculationConfiguration spaceConfiguration spaceZahlCalculatorsXML
23:39
SoftwareXML
24:29
CodeNumberStructural loadInterior (topology)XMLComputer animation
26:22
CodeString (computer science)Gastropod shellLogical constantCodeAPIComputer animationLecture/Conference
27:04
String (computer science)Hand fanSIMPL <Programmiersprache>APIBus (computing)Thread (computing)LimitierungsverfahrenPartition (number theory)Sample (statistics)String (computer science)Lecture/ConferenceComputer animation
29:59
ImplementationVideo game consoleDefault (computer science)ClefWeb serviceError messageProduct (category theory)DatabaseString (computer science)Configuration spaceLecture/Conference
33:09
PositionXMLLecture/Conference
34:01
Switch <Kommunikationstechnik>Queue (abstract data type)Thread (computing)Data storage deviceLecture/ConferenceXMLComputer animation
34:43
ProduktdatenbankGEMProduct (category theory)Web serviceMoment (mathematics)DatabaseVersion <Informatik>Grand Unified TheoryMAX <Programm>Maxima and minimaLecture/Conference
39:20
Server (computing)Slide ruleXMLComputer animationLecture/Conference
40:23
Factory (trading post)Interior (topology)Terminal equipmentmakeClefComputer animation
41:39
outputTerminal equipmentLecture/ConferenceMeeting/InterviewComputer animation
43:00
Pell's equationInterior (topology)Logic gateApache <Programm>Client (computing)Mono-FrameworkAPIString (computer science)Partition (number theory)Computer animation
44:26
BEEPString (computer science)CodeServer (computing)Firewall (computing)Source codeXML
45:40
Interior (topology)Thread (computing)Apache <Programm>PositionComputer animationXML
46:29
LIGA <Programm>Stylus (computing)InformationIP addressMAX <Programm>Version <Informatik>LeadKompaktheitServer (computing)Order (biology)Lecture/Conference
51:25
CodeAssembly languageBefehlsprozessorPropositional formulaWeb serviceLecture/ConferenceMeeting/Interview
55:05
openSUSEComputer animation
Transcript: German(auto-generated)
00:07
Okay, cool. Wir haben euch heute Apache Kafka mitgebracht, so ein bisschen, irgendwie wollen wir euch erzählen, was wir so in der letzten Zeit, in den letzten drei Jahren irgendwie an Apache Kafka kennengelernt haben
00:23
und was so die Problempunkte sind. Genau, das sind wir. Mein Name ist Holger Adam. Ich bin Software Engineer bei Rewe Digital, aktuell im Big Data Bereich, im Bereich Plattform Engineering. Also tatsächlich auch intensiv mit Kafka beschäftigt, bin jetzt seit zwei Jahren bei Rewe Digital
00:40
und treibe mich hauptsächlich mit Node.js, TypeScript und ein bisschen Scala rum und mit der Google Cloud. Genau, ich bin Andreas Kluth, ich bin auch Software Entwickler bei Rewe Digital, mache so das meiste auf der JVM, also irgendwie Kotlin, ja aber ein bisschen Scala, aber nicht so viel und genau,
01:04
betreibe noch irgendwie Bonn Agile mit, also falls jemand das kennt, in Bonn gibt es so eine kleine Software Entwickler Community und das mache ich jetzt irgendwie fünf Jahre oder so was mit als Koorganisator.
01:20
Genau, wir haben euch ein bisschen was mitgebracht und zwar ein paar Brezeln und ein paar Snickers, das heißt, wenn ihr irgendwie eine coole Frage habt oder eine coole Antwort, dann gibt es Frühstück und dann steigen wir eigentlich auch in die Agenda ein. Gesund oder Brezel? Genau, gesund oder Brezel.
01:44
Genau, die Agenda. Wir fangen an mit einer kleinen Einführung zu Kafka, die wird sehr kurz, also für die Leute, die Kafka vielleicht noch nicht benutzt haben. Es gibt wohl morgen noch einen Talk mit einer etwas umfangreicheren Kafka Einführung. Wir gehen ein bisschen schneller durch, wir erklären euch kurz, wozu wir bei Rewe Digital Kafka nutzen.
02:03
Dazu kommen dann die eigentlichen Themen, die Lessons. Der erste Block ist über die Konfiguration und den Broker. Das ist mein Teil. Der zweite Teil geht so ein bisschen in Consumer und Producer von Andreas. Ja, mache ich.
02:20
Okay, warte. Ich hoffe, der Bart raschelt nicht. Jetzt haben wir einen schöner. Ich darf nicht zu nah. Okay, cool. Noch ein bisschen runter muss das, glaube ich. Ist das so gut? Alles okay? Zu laut, zu leise? Jetzt besser. Der zweite Teil, die Java API,
02:40
die macht dann Andreas über die Consumer und Producer. Da gibt es auch so einige Überraschungen. Und am Ende für die umfangreicheren Fragen haben wir noch einen Q&A-Teil. Sonst, wenn ihr Fragen zu den Slides habt, die wir schnell beantworten können, einfach immer melden und dann versuchen wir euch dazu zu helfen. Genau. Lass uns irgendwie erst mal einsteigen
03:00
und irgendwie gucken, was Kafka ist. Kafka kann man sich halt so als... Also das Marketing-Buzzword, was irgendwie auf der Seite ganz groß drauf steht, ist, hey, das ist eine verteilte Streaming-Plattform. Das sagt mir relativ wenig. Also ich kann damit nichts anfangen. Und ist halt auch eigentlich... Na ja, sagen wir mal Quatsch.
03:22
Kafka ist im Endeffekt nicht mehr als irgendwie ein persistentes Log. Das heißt, ihr könnt da irgendwie Daten hinten dran schreiben. Es gibt da halt ein Stück Server-Software. Da könnt ihr Nachrichten hinschicken, die werden auf Platte geschrieben. Und auf der anderen Seite kann irgendjemand sagen, gib mir doch mal bitte alle Nachrichten,
03:42
die du halt irgendwie auf Platte geschrieben hast. Ein persistentes Log, so eine Art Writer-Head-Log, was man irgendwie von Postgres kennt. Man kann in Kafka nicht irgendwie einzelne Nachrichten löchen oder wahlfrei irgendwie auf die Daten zugreifen, Queries dagegen machen oder so was.
04:00
Sondern halt nur linear da drüber lesen. Und halt Daten, die einmal draufgeschrieben sind, bekommt man nicht so schnell da wieder runter. Das ist auf der einen Seite irgendwie ein Nachteil, auf der anderen Seite halt ein schönes Property. Und das unterscheidet das eigentlich sehr, sehr krass irgendwie von herkömmlichen Messaging-Systemen,
04:23
wo man halt eine Nachricht draufschmeißt. Die ist halt nicht persistent, sobald man die konsumiert, ist die halt weg. Das ist bei Kafka halt nicht so. Die Architektur von Kafka ist dann auch relativ einfach. Also das ist jetzt nicht so sophisticated wie AMQP oder so was,
04:42
dass da verschiedene Layer von irgendwie Cues sind und die können auch untereinander irgendwie Routing machen oder so was. Sondern es gibt so das Konzept vom Topic, das kann man sich so wie eine Tabelle oder einen Container vorstellen, da kann man halt Nachrichten reinschmeißen.
05:01
Nachrichten haben halt nichts anderes als ein Key und ein Value. Das heißt, da könnt ihr beliebige Binärdaten reinpusten, sei es irgendwie JSON oder irgendwas JSONB oder ein anderes Binärformat, was ihr halt lieber mögt. Wir haben uns irgendwie bei der REWE für JSON entschieden.
05:23
Die ganzen Topics sind in Partitionen unterteilt. Das ist halt nichts anderes als Sharding von der Datenbank. Also ich habe irgendwie einen Key, nach dem kann ich irgendwie partitionieren. Dann lasse ich dann irgendwie einen Algorithmus drauflaufen, der das Topic weiß, aus wie viel Partitionen es besteht.
05:44
Und dann kann irgendwie basierend auf den Schlüsseln irgendwie der Producer, also derjenige, der die Nachrichten schickt, entscheiden, auf welche Partitionen das dann darauf kommt. So, das Ganze ist im Hintergrund noch repliziert. Das ist vielleicht eine wichtige Information. Das heißt, um die Ausfallsicherheit zu gewährleisten,
06:03
haben die Kafka-Jungs sich gedacht, es ist halt eine coole Idee, das auf mehrere Server irgendwie zu verteilen und dann halt eine Nachricht nicht nur auf einem Server rumliegen zu haben, sondern die halt einfach zu kopieren auf mehrere Server. Jetzt haben wir irgendwie Topic, Partitionen Man muss sich irgendwie noch so eine dritte Dimension dahinter vorstellen,
06:22
halt hier Replikationen von den Partitionen, worüber wir noch kurz irgendwie sprechen sollten, so wie ein Consumer und Producer. Fee-Logik liegt halt bei normalen Message-Systemen halt in dem Message-Bus selber. Also wenn man so einen IBM MQ nimmt oder einen Active MQ oder sowas,
06:41
liegt halt ganz viel irgendwie in dem Broker selber. Während hier halt die ganze Logik in den Producern von den Konsumern von euch implementiert werden muss. Das heißt, so irgendwie was wie irgendwelche Semantiken kennt ihr halt nicht. Consumer ist halt die Seite, die irgendwie die Nachrichten abholt, Producer halt irgendwie, die die ablädt.
07:06
Jetzt schauen wir uns mal irgendwie so eine Partition im Detail an. Die Slide findet man halt irgendwie zu tausenden im Netz, beschreibt das aber ganz gut. Das ist halt dieser Stream von Nachrichten, den ich irgendwie erzählt hat oder das Log von Nachrichten.
07:21
Das heißt, da kann oben ein Producer irgendwie draufschreiben und auf der anderen Seite können halt irgendwie Consumer die Daten runterpollen. Das ist auch wieder irgendwie, konträr zu einem Message-System, was eher ein Push ist. Da pusht jemand die Nachrichten in euer System und ihr müsst halt pollen und sagen, okay, warte mal eine Sekunde und dann pollen wir nochmal.
07:44
Und dann bekommt ihr halt die Nachrichten. Zusätzlich müsst ihr euch noch um die Offsets kümmern. Das heißt, normalerweise bekommt ihr immer alle Daten von Kafka. Die bekommt ihr sehr schnell, also mit der vollen Leistung der Festplatte. Das kann halt bei einer SSD schon mal irgendwie
08:00
die Netzwerkkarte irgendwie voll auslasten oder wird höchstwahrscheinlich die Netzwerkkarte voll auslasten, weil ihr bekommt das halt auch von jeder Partition. Also die Partitionen werden dann halt auf verschiedene Server verteilt und dann kommen irgendwie fünf Server auf euch zu und die schicken euch mit jeweils irgendwie 90 Megabyte an Daten irgendwie zu und eure arme Java-Anwendung muss dann damit klarkommen.
08:26
Genau, das heißt, ihr managt halt selber, wo irgendwie ihr gerade beim Lesen seid. Das heißt, das ist halt kein Automatismus, der halt sagt, okay, das sind irgendwie jetzt die aktuellen Nachrichten, sondern ihr müsst euch merken, hey, ich habe schon 500 Nachrichten gelesen
08:41
und jetzt muss ich irgendwie die 600 lesen. Und das ist irgendwie der Keypoint. Das heißt, irgendwie auf den Marketing Slides von Kafka steht halt, wir können halt alles, wir können halt so Semantiken abbindeln wie at most once.
09:00
Das heißt, irgendwie vielleicht kommt irgendwie eine Nachricht an. At least once. Es kommt halt mindestens einmal die Nachricht an. Es kann die aber auch mehrmals ankommen. Das ist relativ gut noch zu realisieren. Kafka sagt aber halt auch, dass sie exactly once können. Da gibt es halt irgendwie andere Meinungen zu im Internet.
09:20
Also wenn man, ich glaube, Kyle Kingsbury sagt, nö, nö, können die auf jeden Fall nicht. Das halt, der nimmt halt relativ viele Datenbanken auseinander. Genau, die sagen halt, sie garantieren die Reihenfolge der Nachrichten beim Lesen. Das ist halt ein ganz cooles Property. Das heißt, wenn man irgendwie pro Partition sagen, die halt die Nachrichten, die du mir gibst,
09:41
die kann ich dir auch genauso wiedergeben in der Reihenfolge wie für Postkurs oder sowas. Klar, da würde man gar nicht drüber nachdenken. Aber für Kafka durch die Verteiltheit ist das halt ein ganz und die eventual consistency ist halt ein ganz nettes Property.
10:00
Und sie garantieren, dass wenn du was geschrieben hast, dann ist das auch irgendwann persistiert. Also vorausgesetzt, man schaltet das an. Das muss halt noch dazu sein. Und skaliert dann halt horizontal und kann halt extrem schnell. Also hört sich vielleicht ein bisschen irgendwie negativ an.
10:20
Aber wir sind halt total zufrieden mit was Kafka macht und vor allen Dingen mit der Performance. Der Keypoint ist halt, man muss wissen, was man tut. Und das ist nicht ganz so einfach. Wie benutzen wir Kafka? Wer hat hier Microservices in Produktion?
10:41
Wie kommunizieren die so? Kafka hervorragend und Revit MQ, OK. Wir bei Revit Digital haben das auch, wir haben sehr früh auf Microservices gesetzt und zwar nicht nur mit dem Ziel, die Software möglichst gut aufzahlen und skalieren zu können, sondern auch damit die Teams möglichst gut autonom arbeiten zu lassen,
11:02
sodass jedes Team tatsächlich auch soweit soweit geht, dass es ein Kafka-Topic selber anlegen und konfigurieren muss und da im Prinzip auch zu verantwortlich ist. Das zu betreiben. Und wir benutzen Kafka-Topics auf zwei Arten. Wir haben hier so ein Customer Service, der merkt sich einen Kunden
11:22
und hat auch eine eigene Datenhaltung. Sagen wir mal, das ist eine Postgres. Wir haben also nicht Kafka als primäre Datenhaltung, aber wir haben Kafka als Kommunikationsmedium. Und der sagt halt, hier sind Kunden und publiziert die auf so einem Topic, hat hier verschiedene Entitäten, schön mit Keys. Und ab da ist es ihm egal. Denn hier können beliebig viele Services dranhängen.
11:41
Die können auch mehr werden oder weniger und konsumieren dieses Topic. Was wir dadurch erreichen ist, dass wir nur noch auf Kafka uns verlassen müssen und der Customer Service nicht Dinge an Services direkt schicken muss oder ein Billings Service muss nicht per Rest anfragen und darauf hoffen, dass der Customer Service gerade kein Deployment durchmacht oder sowas. Das coole ist halt, die einzelnen Service können halt alle down gehen.
12:04
Das ist uns halt relativ egal. Also der Customer Service kann halt irgendwie nicht verfügbar sein. Trotzdem können die Service halt alle mit ihrer lokalen Datenhaltung halt weiterarbeiten. Auch unser Kafka Cluster kann halt irgendwie weggehen. Das ist halt auch nicht schlimm. Die Producer, also der Customer Service wird irgendwann
12:21
die Nachrichten nachschicken und der Login Service, die irgendwann konsumieren, beim Login Service vielleicht blöd. Aber beispielsweise Order Management ist halt nicht so schlimm, irgendwie wenn mal irgendwie fünf Minuten keine Orders durchgehen, weil wir prozessieren die halt nach. Also dann kommt halt die Mail, danke für Ihre Order halt, irgendwie später, wir sagen dem Kunden halt
12:42
auf der Confirmation Seite halt eh, hier, alles ist erst mal cool und irgendwann, wenn dann im Nachhinein irgendwas schiefläuft, schicken wir halt eine Mail hinterher und sagen, oh tut uns leid, aus irgendwelchen Gründen können wir deine Order nicht prozessieren, was halt total selten vorkommt, also. Genau.
13:01
In dem Fall wollen wir halt auf dem Topic aber auch alle Kunden behalten, das wäre halt irgendwie ungünstig, wenn wir die Kunden von 2017 vergessen, wenn wir 2018 haben. Der zweite Fall, da ist es ein bisschen anders, das sind die bekannten Access Logs oder Click Streams, oder was man halt so hat, wenn wir zum Beispiel API Gateway und das loggt einfach die Ressourcen Requests, wenn wir es nachher analysieren lassen wollen oder so.
13:23
Das ist halt ein kontinuierlicher Stream von Events und dann haben wir da Stream Prozessoren dran hängen, die das quasi live machen. Hier ist der Fall anders, das ist eine größere Datenmenge und wir haben hier zum Beispiel Kunden, auch wenn wir sehr viele Kunden gerne hätten, aber wir werden niemals die Größe von so einem Click Stream erreichen, deswegen ist hier ein Zeitfenster drauf definiert,
13:42
sodass wir den letzten Tag, die letzte Woche vielleicht behalten wollen. Trotzdem das gleiche Prinzip mit der Kommunikation, nur das Topic ist dann anders konfiguriert. Das ist so ungefähr die Topologie von Rewe Digital. Wir haben angefangen hier mit dem e-com Bereich,
14:00
schon mal jemanden beim Rewe-Lieferservice bestellt, dann wirst du wahrscheinlich hier irgendwo drin befinden. Sehr gut, dass das auf jeden Fall Snickers wären, oder? Es sind glaube ich mehrere Snickers, oder möchte jemand Brezeln? Ich verteile mal Brezeln.
14:20
Klar, alles für den Kunden. Ich habe leider nicht mitbekommen, wer die Hand gehoben hat. Ich glaube du hast das. Kein Wunder. Während der Andreas noch die Brezeln verteilt. Hier haben wir angefangen, das ist noch bei einem Hosting Provider, auch mit Microservices und einem Kafka Cluster.
14:42
Mittlerweile machen wir einen Umzug in die Google Cloud, deswegen gibt es hier so zwei schöne farbige Wolken. Es gibt den Fulfillment-Bereich, also wenn ihr durch den Shop durch seid und auf euer Essen wartet, muss das auch jemand in ein LKW packen und losfahren, das muss eine Rechnung geben und bezahlt werden. Im Fulfillment-Bereich, der hat sein eigenes Kafka Cluster,
15:00
und das hier ist so meine Spielwiese, der Big Data Bereich. Hier werden wir uns hauptsächlich mit Personalisierung beschäftigen und die Sachen, die an Daten anfallen, analysieren. Auch mit einem eigenen Kafka Cluster und die reden ganz normal mit dem Mirror Maker miteinander. Wir haben hier auch eine einfache Replikation der Daten über verschiedene Cluster mit dem Kafka Mechanismus.
15:24
So, dann kommen wir auch zu den Lessons learned. Ich hatte vorhin erwähnt, Autonomie heißt auch, dass die Entwickler oder die Teams ihre Kafka Topics selber anlegen müssen und verwalten müssen, hat das schon mal jemand gemacht? Sehr gut, war Spaß? Erstmal nicht, okay.
15:42
Wie man das so macht, man macht das nicht täglich, denn so viele Kafka Topics gibt es dann doch nicht und ein gutes Pferd springt halt nur so hoch, wie es muss. Also sucht man sich wahrscheinlich den Pfad des geringsten Widerstandes und versucht halt ein Kafka Topic so schnell anzulegen, dass man mit den Story Points noch durchkommt, mit dem Rest der Story.
16:01
Was man oft hört, ist so was wie, der Admin sagt, mein Topic wird immer größer, aber ich habe doch Compaction eingestellt. Das ist halt so eine zwiespältige Sache. Compaction heißt halt nur, alte Versionen eines Keys werden aufgeräumt und wenn die Keys immer mehr werden, wird das Topic natürlich immer größer. Ganz im Gegensatz zu Delete, da kann man halt einstellen,
16:21
wie lange oder wie alt oder wie groß Sachen werden dürfen. Das ist so der erste wichtige Konfigurationswert, den man kennen muss und das begegnet einem immer wieder, dass die verwechselt werden. Es gibt eine Cleanup Policy, Delete oder Compact, die läuft auf einem Topic und sagt, Kafka, wie soll dieses Topic sauber gehalten werden?
16:40
Bei Compact, der Andreas sagte es, die Messages werden auf die Partitionen verteilt mit einem Key, wird geguckt, welche Version des Keys die letzte ist und alle vorherigen können dann weggeschmissen werden. Bei Delete dagegen können wir sagen, das Topic darf nur xBytes oder xms groß werden.
17:01
Dann geht Kafka radikal hin und sagt, das ist älter als ein Tag, du hast gesagt, mehr als ein Tag brauchst du nicht, alles andere verschwindet. Freut den Admin, aber vielleicht nicht den, der die Sachen noch braucht. Wie sieht so eine Partition eigentlich aus? Das ist auch relativ unbekannt,
17:21
ist aber durchaus wichtig, denn da oben gibt es die Konfigurationswerte segment milliseconds und second bytes. Hier betrachten wir eine Partition von einem Topic, denn die unterteilt sich, die ist kein riesiger Binärblock oder liegt immer komplett in Memory, sondern in ein Head und den Tail, das ist der ganze Rest. Die einzelnen Elemente sind die Segmente,
17:41
die kann man konfigurieren und sind auch abhängig davon, was er einstellt und abhängig davon, was an Daten reinkommt. Da muss man sich am besten ein bisschen hinsetzen, rechnen, überlegen, wie viel kommt da so rein, wie viele Filehandles habe ich, auch ein bisschen das Monitoren und dann stellt man das dort ein. Der Head ist das aktive Segment,
18:02
das liegt immer in Memory und ist von den beiden Cleanup Policies nicht betroffen. Das heißt, wenn hier Nachrichten drin liegen, dann werden die nicht gelöscht und auch nicht kompaktiert. Ganz im Gegensatz zum Tail, denn hier passiert gleich die ganze Magie und das hier sind dann die einzelnen Segmente. Wenn wir uns das bei einer
18:21
Delete Cleanup Policy angucken, dann ist der wichtige Wert Retention Milliseconds. Ich habe schon relativ häufig gesehen, dass jemand gesagt hat, ich habe ja Compaction und meine Retention Milliseconds sind eingestellt, aber irgendwie funktioniert es nicht. Das ist der Grund, Retention Milliseconds funktionieren nur bei Cleanup Policy Delete, denn das ist die Zeit,
18:40
die ein Segment alt werden darf, bevor es gelöscht wird und zwar nicht von der ersten Nachricht in dem Segment, sondern von der letzten und Kafka geht tatsächlich an den Last Modified Timestamp und vergleicht den mit den Retentions und der aktuellen Zeit und schmeißt dann hinten weg. Das Ganze kann man auch mit Bites machen, wenn man lieber mit Festplattengröße rechnet. Man kann es auch mit Beidem machen, dann wird das gelöscht,
19:03
wo der Wert zuerst erreicht ist. Dann ist man eigentlich auch nochmal sicher. Bei Compaction funktioniert das Ganze ein bisschen anders. Wir haben hier so einen schon kompaktierten Teil, da war Kafka schon mal drüber und hat gesagt, von Entitate C, da gab es schon vier Versionen, aber ich will nur die fünfte behalten,
19:20
damit es ein bisschen aufgeräumter ist. Und Kafka muss jetzt entscheiden, wann räume ich denn eigentlich hier den Teil auf, wo schon wieder Nachrichten in den Tail gekommen sind. Da geht ein Thread drüber und da kommt natürlich die Mint Cleanable Dirty Ratio. Klingt richtig gut. Das ist tatsächlich das Verhältnis von kompletten Segmenten
19:42
in dieser Partition für dieses Topic im Verhältnis zu den bereits aufgeräumten. Die ist standardmäßig auf 50%. Also wenn ihr 100 Kies da reinschmeißt und wundert euch, dass nach 30 nicht aufgeräumt wird, dann ist das Topic halt noch nicht schmutzig genug. Die kann man auch konfigurieren. Das ist ein Wert zwischen 0 und 1, eine Prozentzahl,
20:01
und hier wäre es halt jetzt schon drüber. Hier haben wir gut die Hälfte schmutzig und Kafka räumt dann auf und im Endeffekt haben wir danach ein sehr kleines Topic. Das sind so ungefähr die wichtigsten Dinge. Es gibt wie bei Kafka, hier haben wir schon mal die Kafka Doku gelesen, kann alle Konfigurationswerte auswendig?
20:21
Ich weiß auch nicht alle, man findet immer einen, der dann doch noch so ein bisschen was ändert. Es gibt über 100, glaube ich, allein für den Broker. Irgendwie muss sich die Schulung ja auch rechtfertigen. Aber so im Prinzip sind das so die wichtigen Dinge. Retention nur bei Delete, komplex funktioniert so, alles passiert nur im Tail. Wenn ihr in Memory seid, im ersten Segment, dessen Größe ihr selber bestimmen könnt,
20:43
dann passiert nichts. Das heißt für unsere Teams, jeder muss wissen, was er tut. Und es reicht halt nicht zu sagen, hast du das schon mal gemacht, kopiere ich mir einfach, sondern lieber selber nachlesen. Hier die ganzen Begriffe, alles nicht so gut. Es gibt hier so ein kostenloses E-Book von Confluent,
21:03
die mittlerweile eine eigene Firma sind, die Kafka gebaut haben. Das kann ich eben nur empfehlen. Das findet man sofort bei Google, das ist kostenlos. Da ist alles erklärt, auch wenn das ein bisschen alt hat mit den Kafka-Versionen. Aber die Grundprinzipien stehen drin und da kann man immer nachschlagen. Ansonsten bietet sich an, startet im lokalen Kafka.
21:21
Im Docker Hub liegt, glaube ich, der von Wurstmeister. Mit dem Zookeeper dran, einfach starten, ein bisschen rumspielen. Man muss ja nicht 3 Monate Retention einstellen, man kann es ja auch mit 3 Minuten testen, aber dann wisst ihr ungefähr, was passiert. Ansonsten halt lesen, lesen, lesen. Doku bietet sich an. Beispiele, sagt der Andreas nachher noch was zu. Die Konfigurationsparameter sind gut erklärt.
21:41
Wir schauen uns auch mal an, warum dein Compaction vielleicht manchmal nicht so gut ist, wenn man die Reihenfolge nicht sicherstellen kann, weil Kafka kennt halt nur die Keys und keine Version. Genau, das sehen wir gleich. Dann haben wir das Problem, jetzt wissen wir ungefähr, wie wir konfigurieren müssen.
22:01
Dann stehe ich jetzt im Büro, hab mir alles schön durchgelesen, dann kommt der Andreas und sagt, ich brauch jetzt ein Topic. Wie lange soll es denn halten? 2 Wochen, sagt der Andreas, okay, kein Problem. Ich weiß auch ungefähr, wie groß die Segmente sein sollen. Die sollen 10 Stunden sein oder 500 Megabyte. Dann hab ich alles, was ich brauche.
22:20
Wenigstens komm ich zu dir und leg's nicht direkt selber an. Der hätte es ja auch selber probieren können, hätten wir auch zusammen machen können. Ich benutze Kafka Topics, die Konsolenkonfiguration und hab mir das schon ungefähr zusammengebaut. Ich erzeuge mir ein Topic namens Froskon. Ich sag, das soll gelöscht werden, weil Andreas gesagt hat, die Daten ist ein Clickstream, wo nicht so viel passiert.
22:42
Das heißt, ich brauch die Retention Milliseconds, ich brauch die Segment Milliseconds und die Segment Bytes, je nachdem, was größer sein soll. Dann fang ich an zu rechnen und denke, Milliseconds, super cool. Erst mal alles 1000, dann mal Minuten, dann mal Stunden, dann 24 Stunden, dann bin ich schon bei Tagen und dann bin ich noch bei 14 Tagen, dann ist Andreas glücklich.
23:01
Die Zahl, die ist so eine schöne Taschenrechner-Rauskopierzahl. Bitte was? Ich mach die DSGVO dann glücklich. Nach 2 Wochen ist alles weg. Wer hat Spaß mit der DSGVO? Erstaunlich wenige. Genau, 10 Stunden hast du gesagt, sollen die Segmenten maximal alt werden.
23:21
Also einmal der gleiche Rechenspaß, wir nehmen mal Millisekunden, Minuten und dann mal 10 Stunden. Das Ganze noch mal rechnen, Taschenrechner glüht. 500 Megabyte, hat der Andreas gesagt, aber ich mag 1024 lieber, deswegen nehm ich Migibyte. Ich glaub, so heißen sie. Nehme das Ganze mal 512 und dann hab ich den Wert.
23:40
Das ist dann mein Aufruf, um das Topic zu konfigurieren. Jetzt mach ich das natürlich nicht unbedingt immer manuell, sondern das liegt dann irgendwo in einem Konfig-File, falls der Broker mal weg ist und wir das neu aufsetzen müssen. So kommt das dann, dass nächste Woche ein anderer Kollege kommt und sagt, cool, so ein Topic brauch ich auch, aber ich brauch irgendwie nur 100 Megabyte Segmente.
24:00
Der geht dann halt hin, sucht sich das raus und sieht, oh, 500 Megabyte ungefähr. Dann teile ich das einfach durch 5. Hat er den Wert, kopiert sich das raus und irgendwann landet man bei so einem File. Und wenn dann jetzt jemand zu euch kommt und sagt, ich brauch ein Topic, das nach 7 Tagen gelöscht wird
24:21
und nur 24 Stunden Segmente hat, dann denkt ihr euch, ja, cool, da steht es ja. Dann kopiert ihr es einfach, stracke meinen Namen ein und so. Ja, das ist halt nicht so cool, weil ich hab hier ne Null vergessen und meine Daten sind irgendwie noch anderthalb Tagen weg. Blöd, ne? Sorry. Können wir ja neu konfigurieren, weiß nur der Kollege
24:41
von nächster Woche nicht mehr. Deswegen ist sowas brandgefährlich, weil diese Zahlen kann kein Mensch mehr lesen, die vielleicht, weil sie als Default-Wert drin steht und eine Woche ist. Trotzdem muss man halt sagen, es ist nicht die schönste Konfigurationsart, das in Milliseconds nur konfigurieren zu können. Auf dem Broker kann man tatsächlich auch mal Werte finden,
25:01
wo Minutes und Hours hinten dran steht. Dankenswerterweise nur für die Retention. Also Segmente kann man nicht anders konfigurieren als Milliseconds und Bytes. Einzelne Bytes, ja. Eine nette Anekdote gibts da auch. Genau, da gibt es auch ne Anekdote, ich hab mal versucht, große Segmente anzulegen, größer als 2 GB,
25:21
irgendwann kann der Int nicht mehr parsen. Ja, ist vielleicht auch nicht die beste Idee, da so ein Int-Parse an so einen Millisekundwert zu klemmen, wenn man so ein skalierbares System hat, aber gut. Tut euch einen Gefallen,
25:44
sucht euch irgendwie einen kleinen gemeinsamen Nenner für möglichst viele Topics, konfiguriert den Broker so, dass der den Standardwert hat. Es muss halt nicht immer jedes Topic super individuell konfiguriert sein, es ist kein Porsche denne konfiguriert, da reicht auch 100 MB für 5 Topics, die sonst irgendwie 75 und 125 hätten, davon stirbt erstmal auch keiner.
26:03
Topics können neu konfiguriert werden, das ist keine ganz einfache Sache, aber vor allen Dingen nicht, wenn man Repartitioning macht. Ich hab vorhin gesagt, die Retention geht auf den Last Modified Timestamp von den Segmenten, bei einer Repartition werden da auch Sachen verschoben und dann muss man ein bisschen aufpassen.
26:21
Es gibt natürlich noch ne bessere Variante, als den hier zu machen. Wir können ja einfach den Computer rechnen lassen. Wenn wir sowieso schon so autonom sind, dass wir uns die Topics anlegen lassen, dann erzeugen wir uns einfach ein paar Konstanten und legen das Topic im Code an und das ist tatsächlich auch was, was ich lesen kann und wo ich auch sehen kann, oh zwei Tage, ja das kommt hin.
26:43
Das kann man auch am besten auf der Shell machen. Jetzt haben wir hier ein Java Beispiel, auf jeden Fall diesen Zahlenboost möglichst vermeiden. Dann kommen wir zum Konsumerteil. Wir gehen jetzt ein bisschen auf die Java API ein.
27:00
Wir haben halt festgestellt, als wir vor vier Jahren mit Kafka angefangen haben, da gab es noch den Simple Consumer und die Advanced API, also zwei APIs, während die eine in Scala geschrieben ist, war und mit Java nicht so einfach zu benutzen war und die Simple API eigentlich kaputt war,
27:23
aber gut für Demos. Irgendwann haben die Entwickler eine nettere API entwickelt und die beiden bestehenden halt ersetzt haben. Keine Ahnung, ich habe jetzt
27:42
meinen Sprint gestartet. As requirement haben wir irgendwie bekommen, hey, konsumiert doch alle Änderungen im Warenkorb. Was mache ich? Ich gucke auf Stackoverflow oder JavaDoc. Wobei JavaDoc schon wesentlich besser ist,
28:01
was man auf Stackoverflow liest. Ich kopiere die auch immer nur. Das funktioniert danach manchmal. Samples sind jetzt in Kotlin, weil dann passt mehr auf die Folie. Wie funktioniert ein Consumer?
28:22
Ich sage dem einfach hier, es ist ein Bootstrap-Server. Normalerweise gibt man eine Liste von APIs an. Man sollte möglichst alle Nodes im Cluster drin haben. Der fragt den Sucheaper hier, was ist denn jetzt gerade,
28:40
wie ist das Cluster konfiguriert und würde sich die anderen APIs auch ziehen. Besser ist ein Ziel zu haben. Ich gebe dem noch eine Consumer Group. Da sind wir noch nicht darauf eingegangen. Im Endeffekt kann ich Consumer zusammenfassen, sodass ich mit mehreren Threats konsumieren kann.
29:01
Damit nicht die Nachrichten mehrfach ausgespielt werden. Es gibt dieses Konzept von Consumer Groupen. Da ist noch eine lustige Limitierung mit drin. Ich kann maximal so viele Consumer haben, wie ich Partitionen habe.
29:23
Wir haben mit drei Partitionen angefangen. Wir haben festgestellt, mit mehrer Threats können wir nicht konsumieren. Wir haben dann 30 als default eingestellt. Danach kamen Leute auf die Idee, 1000 zu nehmen.
29:42
Das hat nicht so gut geendet. Genauso 10 bis 30. Das ist ein guter Wert für die Anzahl von Partitionen. Ich habe noch eine Möglichkeit zu customisieren, wie ich Keys und Values serialisiere. Das Einfachste ist ein String Serializer. In die Serializer puste ich dann Key rein.
30:02
Das kann ein Dresden-Objekt sein. Oder einfach nur ein String. Das Gleiche in grün für den Value. Der Consumer sagt dann hier, hör mal auf das Topic. Dann geht er in einen Poll-Loop. Wir hatten am Anfang gesehen, das ist ein Poll und kein Push.
30:22
Dann habe ich das, starte das. Alles ist cool. In einer Sekunde kommt so eine Nachricht rein? Genau. Das ist der For Each. Man bekommt immer eine Batch an Nachrichten. Da gibt es diverse Konfigurations-Settings.
30:42
Im Endeffekt bekommt man, ich glaube, per Deep Vault 8000 Nachrichten. Das lässt sich konfigurieren. Da bekommt man relativ viele Nachrichten. Da muss man auf den Memory aufpassen. Aber im Endeffekt funktioniert das erst mal. Ich bekomme Nachrichten, der Happy Pass ist cool.
31:02
Ich bin glücklich und lege das zur Seite. Nach einer Woche merke ich, ich nehme an, ich habe die Produkte konsumiert. Da fehlen ein paar Produkte. Leute können Sachen nicht kaufen. Das liegt daran,
31:21
in den Standard Tutorials wird der Aspekt des Offset Committing relativ stiefmütig behandelt. Der Konsument, der Printline macht etwas Komplexeres, auf die Konsole auszugeben, in der Datenbank oder mit einem anderen Service reden
31:42
oder Business-Logik machen. Da kommt etwas an, was er nicht prozessieren kann. Irgendjemand hat keinen Jason auf die EQ geschrieben. Oder eine Nachricht, die wir nicht realisieren können. Was macht der Konsumer? Er fällt auf die Nase.
32:02
Er prozessiert die nächste Nachricht, wenn wir Error Handling eingebaut haben. Das ist cool. Das Problem ist, im Hintergrund läuft ein Auto-Commit. Der sagt, ich habe diese Batch bekommen, die commite ich ab und setze den Offset.
32:21
Aber das hast du schon eingestellt. Genau, das ist irgendwo konfiguriert. Aber das ist der Default. Das ist nicht so schlimm. Nach ein paar Stunden ausprobieren, komme ich auf die Idee, ich sollte auf jeden Fall Auto-Commit abschalten.
32:40
Und ich sollte manuell committen. Wir haben angefangen, relativ komplexen Kram zu bauen. Wir haben jede Nachricht gezählt und die in eine Liste geschrieben. Damit wir schneller committen können. Das ist nicht wert. Wir haben festgestellt,
33:01
die Implementierung ist auch kaputt. Wir haben nicht bedacht, dass ein Konsumer zwei Positionen kennt. Er kennt seine interne In-Memory-Position. Und er kennt die committete Position. Wenn ich noch mal einen Poll mache,
33:21
die Nachrichten aber nicht committet habe, bekomme ich die alten Nachrichten nicht mehr. Das ist ein bisschen blöd. Die Erwartungshaltung wäre, ich committe nicht, weil ein Fehler passiert ist. Dann gehe ich noch mal an den Poll und sage,
33:40
gib mir die Nachrichten noch mal. Dann kommen nicht die Nachrichten noch mal, sondern ich bekomme die nächste Batch. Wenn ich die weg committe, habe ich meine Nachrichten verloren. Wenn ihr einen Konsumer baut, stellt Autokommit ab.
34:01
Das ist extrem wichtig. Ihr solltet den Offset manuell setzen. Ich persönlich bin inzwischen der Meinung, dass es keine coole Idee ist, den Offset von Kafka managen zu lassen. Ihr könnt den Offset total machen. Das ist nicht eine gute Idee. Das ist ein Pro-Trip,
34:22
in eurer Postgres-Datenbank speichern. Oder in eurer Anwendungs-Datenbank. Das hat den Vorteil, ihr könnt das transaktional ablegen. Es gibt noch ein paar Besonderheiten, dass Kafka die gespeicherten Offsets
34:41
nach einem Tag wegschmeißt, wenn man die nicht warm hält. Das ändern die jetzt auf 7 Tage, aber im Moment in der aktuellen Version. In 2.0 haben die das gefixt, in 1.0 ist es noch so. 7 Tage Urlaub kann man auch schon mal machen. Am Wochenende schaltet der Sysop den Service aus,
35:00
weil er sich nicht nett verhält. Am Montag startet ihr den neu, und er fängt plötzlich an, die komplette Produktdatenbank zu konsumieren. Ihr solltet überlegen, was macht ihr mit nicht-prozessierbaren Nachrichten. Das ist immer ein großes Problem gewesen. Ich lege die beiseite, überspringe die, hier Integration Patterns sagen,
35:21
ihr baut euch eine Message-Queue. Ich lege die dahin. Was mache ich, wenn das JSON nicht passbar ist? Oder ein Property fehlt, was ich brauche? Wir haben festgestellt, dass es eine coole Idee ist, sich auf den Rücken zu legen und zu sagen,
35:41
ich kann nicht weitermachen. Ein Lämpchen rot machen in dem Service, sobald der nächste draufschaut, wird das gefixt und die Nachricht manuell nachprozessiert. Oder das Problem wirklich gefixt. Das war eine schöne Koppel.
36:08
Es gibt auch eine Möglichkeit, zurückzusegen beim Poll. Der Hinweis war, man soll nicht immer wieder einen Retry machen, dann bekommt man die Nachricht immer wieder.
36:22
Und zwar sehr schnell. Was man da machen sollte, ist eine Back-up-Strategie, wie ein Spring-Retry-Template. Und dann hingehen und sagen, hol die Nachricht erst nach 10 Sekunden wieder. Dann ein exponentielles Back-off.
36:43
Und dann im Notfall muss da jemand draufgucken. Kafka überflutet mit Nachrichten. Wenn ihr hingeht, das habe ich ja mehrfach gesehen, in eine Blocking-Queue, oder eine Worker-Queue inbauen.
37:02
Und sagt, die arbeite ich nachher ab. Ist das keine gute Idee, dann explodiert euch die JBM. Dann kriegt ihr 500 MB an Daten und packt die noch in JSON-Objekte. Dann sind die Gigabyte, den euer Microservice einen Hieb gibt, relativ schnell voll.
37:22
Das ist ja kein Problem. Das ist eine Starter-Queue. Genau. Dann starte ich den neu. Immer Bounded-Queues nehmen. Worker-Queues machen. Nur kommitten, wenn ihr die prozessiert habt. Wir haben festgestellt,
37:41
einige haben so etwas gebaut wie, ich nehme ganz schnell die Nachrichten an. Dann habe ich einen großen Worker-Pool. Das sind Altenloft-Services, die zum Prozessieren abholen. Und dann damit weiterarbeiten. Gutes Monitoring.
38:01
Wir haben mehrere Down-Times gehabt. Sorry. Ich meine damit Java-Listen-Queues. Sorry. Genau.
38:21
Das bezieht sich auf, wenn du in der JVM bist oder so, solltest du Sneakers oder... Solltest du nicht eine Blocking-Queue mit Integer, Max oder so konfigurieren. Das ist problematisch. Und einen Kill-Switch für die SysOps haben wir jetzt in relativ vielen Services.
38:44
Wir haben das Problem, wenn jemand das Orders-Topic konsumiert. Das ist riesengroß. Und damit mit Full-Speed gegen die Datenbank haut. Dann macht er unsere Produktiv-Services kaputt. Und keiner kann mehr Artikel in den Warenkorb legen. Das ist uns ein paar Mal passiert.
39:02
Auch mit Produkten. Um 10 Uhr wurden die Produkte abgeladen. Dann kam eine neue Batch von den Produkten. Alle Services haben schnell versucht, die Produkte zu konsumieren. Das ist uns relativ lange um die Ohren geflogen. Ich habe noch 10 min.
39:20
Dann bin ich gut in der Zeit. Dann kommen wir zum Producer. Ich will euch gar nicht lange mit Slides nerven. Diesmal bin ich schlauer gewesen. Ich habe die Java-Doc gelesen. Die Java-Doc sagt, hey, ein Producer. Die Java-Doc ist einigermaßen gut.
39:42
Man muss XOR sagen. Das hatten wir am Anfang gesehen. Das bedeutet alle Server. Alle sogenannten Instinct-Replikas. Die alle Nachrichten, die auf dem Server sein sollen, schon bekommen haben. Ein paar Mal die Nacht bekommen.
40:02
Das ist die offizielle Doku. Das ist auf jeden Fall safe. Die erklären, warum das nicht so safe ist. Aber sie haben keine richtigen Alternativen. Dann kommen wir zum Compaction. Wir schauen uns das in der IDE an.
40:21
Wir haben auf der rechten Seite den Producer konfiguriert. Wir haben die Default-Settings.
40:41
Dass der einen String-Sealizer für den Key und den Value nimmt. Einen Kafka nimmt, der hier lukar läuft, soll XOR. Ich habe einen Retry reinkonfiguriert. Den kann man größer setzen. Ein Config-Objekt, ein Logger,
41:02
damit man es visualisiert. Ich schlafe 200 Millisekunden. Was macht der Retry? Wenn eine Message an den Kafka nicht submitted werden kann, würde er versuchen, die nochmal zu schicken. Das führt zu Reordering.
41:22
Wenn mehrere Messages an den Kafka-Broker unterwegs sind, gibt es ein In-Flight-Request. Das würde dazu führen, wenn der eine Retry der andere nicht, dann überholen die sich gegenseitig. Das ist ein ganz nettes Problem.
41:44
Wir starten den Producer. Dann starten wir den Consumer. Ein Breakpoint wollte ich nicht machen. Der Producer fängt an und sagt, ich habe jetzt Nachrichten
42:02
auf das Topic, um in der Terminologie zu bleiben. Wer macht das mit 1000 Nachrichten? Das schläft ein bisschen. Es ist ein langsamer Producer. Was wir haben, die schnellsten produzieren 700-800 Nachrichten
42:23
pro Minute im E-Com-Bereich. Ich weiß nicht, wie das bei euch aussieht. Bei den Produzern? Ja, es gibt verschiedene. Wir nähern uns den 1000. Jetzt haben wir ein cooles Setup. Der Consumer kriegt die Nachrichten.
42:41
Der Producer bekommt die Nachrichten. Jetzt gehen wir ins Terminal und ziehen die Netzwerkkarte. Das kam überraschend. Ich gehe an den Docker-Container. Eintippen macht mehr Sinn. Ich kann mit Docker-Network
43:01
und Disconnect sagen, wir ziehen eine Netzwerkinterface. Wir haben einen Default-Container. Da gebe ich die Container-ID ein. Das ist die 41. Jetzt würde ich erwarten, der Producer produziert weiter
43:20
und merkt, der Netzwerk ist nicht da. Dann muss ich die Nachrichten zurückhalten und sie produzieren. Der Consumer hat die Connection verloren. Der letzte Rekord ist 412. Hier sagt er, Connection to Node fehlt.
43:42
412 haben wir bekommen. Der Producer sagt, ich habe Produced. Der Producer macht ein Rekord. Jetzt muss ich schnell sein. Wenn ich nicht schnell genug bin,
44:02
timet mein Consumer aus. Consumer haben eine Lifetime. Wenn die aus timen, werden die Partitionen rebalanced. Um festzustellen, der Consumer ist tot. Deswegen muss man manchmal einen Poll aufrufen.
44:22
Wenn man viel Arbeit macht, kann es sein, dass der Server denkt, ihr seid tot, die Session ist abgelaufen. Dann verteilt er die Arbeit neu. Das ist nicht so cool,
44:42
wenn man exactly once-Semantik haben möchte. Wenn man at least once haben will, ist das okay. Darauf sollte man optimieren. Wir sehen die letzten Nachrichten. Das Timing war gut. Der Producer hat den Server wiedergefunden.
45:03
Alles ist cool. Das ist bei uns relativ häufig in der Hosted-Environment ein Problem. Warum auch immer, wenn man eine Firewall beschlossen hat, flaky zu sein, dass wir den Broker zufällig nicht sehen.
45:22
Ich glaube, das wurde gerade gefixt. Was passiert? 412 haben wir aufgehört. Der Consumer hat die Verbindung verloren. Jetzt geht er weiter. Die nächste Nachricht ist 613.
45:43
Ich habe gute 200 Nachrichten verloren. Die sind wo auch immer. Die sind im Nichts gelandet. Das ist das, was ihr machen solltet,
46:04
wenn ihr einen Kafka-Producer baut. Das ist gar nicht so trivial. Die Nachrichten lagen nicht auf dem Topic? Nein, die lagen nicht auf dem Topic. Der Consumer wollte an der Position weitermachen, weil ich keinen Offset-Committed habe.
46:22
Er hat die letzte Nachricht bekommen. Er hat die Verbindung wieder aufgebaut. Ich war an dieser Position. Bitte gib mir die nachfolgenden Nachrichten. Was bedeutet das für mich als Entwickler? Wichtig ist Ex-All.
46:40
Das reicht noch nicht. Wenn ihr einen coolen, schnellen Cluster haben wollt, stellt mal Antinida-Lection auf True. Das bedeutet, auch wenn der Replika nicht aktuell ist,
47:04
darf ein Replika als Master selektiert werden. Das hat den Hintergrund, Sie möchten halt, oder der Reaktor, der Punkt wird vom Cap-Theorien auf die Verfügbarkeit gesetzt. Wenn die verfügbar sein wollen,
47:22
können sie nicht warten darauf, dass der Leader wieder aktiv wird oder genug Server den aktuellen Stand haben. Deswegen ist unser Tipp, dass die Instinct-Replika mindestens auf zwei, dass zwei Server eure Nachricht gesehen haben und die Replikation mindestens auf drei.
47:41
So dass drei Server theoretisch diese Nachricht bekommen haben, ihr könnt die Replikation höher setzen, erhöht die Wahrscheinlichkeit, dass zwei den aktuellen Stand haben. Wenn ihr Retries aktiviert, führt das immer zu Reordering. In Edge-Cases, wenn mehrere Nachrichten in-flight sind,
48:04
also dieses Max-In-Flight-Request-Per-Connection, dann würden sich Nachrichten oder Badges überholen können. Das wäre blöd. Vor allen Dingen, wenn wir zurückgehen zu Holgers kompaktischen Informationen,
48:23
Kafka weiß nichts von Versionen. Kafka erkennt nur Keys und Values. In die Values kann er nicht reingucken. Also kompaktet er auf die Keys. Wenn ihr die Reihenfolge jetzt ändert, und z.B. das Produkt Delete zufällig mit der vor dem Produkt Create ankommt,
48:43
weil in-flight-rego-ordert worden ist, hättet ihr das Produkt plötzlich wieder im Shop und könntet es kaufen. Die Kunden wundern sich, warum der Warenkorb immer sagt, das Produkt gibt es nicht mehr, du kannst es nicht kaufen.
49:00
Vielleicht kommt meine Milch auch an die Alte Adresse. Genau. Wenn ihr glücklich seid, Version 1.0 von Kafka benutzt, gibt es einen Flag, um Ideenpotenz anzuschalten. Das haben die eingeführt mit exactly-once-Semantik. Das bedeutet, die Fragen beim Server ab,
49:23
gib mir bitte 5 IDs, mit denen ich den Nachrichten schicken kann beim Broker. Der Broker verwendet die 5 IDs, um Nachrichten zu schicken. Dann sagt der Broker, cool, danke. Hier sind die nächsten 5 IDs, aber du hast mir keine Nachrichten geschickt
49:41
oder schickst mir die gleichen. Das ist die Empfehlung von den Kafka-Leuten. Wenn so was passiert, dann ist der Producer kaputt. Dann müsst ihr per Consumer fragen, was sind die letzten Nachrichten, die du bekommen hast? Dann den Producer nochmal neu an den Nachrichten produzieren.
50:04
Ich habe ein Ende gesehen. Du hast ein Ende gesehen? Dann noch kurz das Fazit. Wir produzieren halt oder legen die Nachrichten in unserer Persistenz
50:22
in dem Microservice ab. Jetzt bin ich irritiert mit dem Ende. Wir gehen hin und speichern die, bevor wir die transmitten. Wir haben einen Worker, der das Transmit übernimmt. Dann sagt er, du bist verschickt.
50:42
So kriegen wir die Order hin. Es kommt ganz krass darauf an, was ihr macht. Egal, was ihr macht. Das sind Clickstreams. Wenn da Nachrichten verloren gehen, dann kriegen wir nicht mit, dass er einmal Add to Cart gedruckt hat. Wenn ihr etwas sagt wie Customer Create,
51:01
dann wäre es total fatal, wenn das nicht ankommt. Schaltet die Retrace ab, macht die Retrace selber. XOIL anschalten. Enable-Ideen-Potenz finde ich schwierig. Die Consumer sollten mit mehrfachen Nachrichten umkommen können. Mit den Problemen mit Compaction.
51:22
Damit bin ich durch. Hört man mich noch? Habt ihr noch Fragen? Wir haben noch ein bisschen Essen da.
51:48
Genau. Die Frage ist, ob Kafka Connect unser Problem lösen könnte. Kafka Connect ist ein Produkt von Confluent, das eine ETL-API bereitstellt.
52:05
Wir haben das in der Produktion im Einsatz. Kafka Connect passt bei manchen Services. Wir sind autonom in Teams überlassen, was sie einsetzen.
52:20
Viele schreiben lieber, weil es einfach wirkt, ein kleines Stekot für einen Producer. Um danach die Probleme zu haben. Ich glaube, Kafka Connect ist nicht für jeden Use-Case geeignet. Das haben wir uns angeguckt.
52:43
Teilweise im Einsatz. Teilweise stark custom-ized.
53:06
Wir verwenden auch Spring Kafka. Ich habe nur die direkten APIs gezeigt. Spring Kafka hat ganz viel Magic, wie Retro Templates, schon eingebaut. Das abstrahiert das ein bisschen.
53:21
Aber die Wahrheit liegt trotzdem drunter. Sie benutzen die Kafka-API. Da muss man dann schon reingehen. Ich glaube, wir stoppen. Wir können noch. Letzte Frage.
53:44
Wir haben auf einem Topic LZH aktiv. Oder LZ4? Ich glaube, LZ4. Wir und ihr habt auch Kompomierungen an. Ich kann vom Betrieb her keine Aussagen treffen.
54:02
Ich benutze das für meinen Topic. Das Basket-Topic. Das ist komprimiert. Wenn ich das nicht komprimiere, wird das relativ heftig. Wir können erst mal nicht die Storage-Zusagen,
54:20
die wir bekommen haben, einhalten. Deswegen haben wir es komprimiert. Ich sehe da relativ wenig Probleme oder Nachteile. Im Vergleich zum nicht komprimierten Topic ist mir noch nichts aufgefallen.
54:42
Ich schicke 700 Nachrichten die Minute ab. Das ist halt... 1,5 Millionen am Tag. Das ist halt machbar. Da langweilt sich die CPU. Das ist keine Limitierung gewesen. Danke fürs Zuhören.