Wie wir bei Sportmaster ein Caching-System ausgewählt haben. Teil 1

Hallo! Mein Name ist Alexey Pyankov, ich bin Entwickler bei der Firma Sportmaster. Darin post Ich erzählte, wie die Arbeit an der Sportmaster-Website im Jahr 2012 begann, welche Initiativen wir „durchsetzen“ konnten und umgekehrt, welchen Rake wir einsammelten.

Heute möchte ich Gedanken zu einem anderen Thema teilen – der Auswahl eines Caching-Systems für das Java-Backend im Site-Administrationsbereich. Diese Handlung hat für mich eine besondere Bedeutung – obwohl sich die Geschichte nur über zwei Monate erstreckte, haben wir in diesen 2 Tagen 60 bis 12 Stunden und ohne einen einzigen freien Tag gearbeitet. Ich hätte nie gedacht oder mir vorgestellt, dass es möglich ist, so hart zu arbeiten.

Deshalb habe ich den Text in 2 Teile aufgeteilt, um ihn nicht vollständig zu laden. Im Gegenteil, der erste Teil wird sehr einfach sein – Vorbereitung, Einführung, einige Überlegungen darüber, was Caching ist. Wenn Sie bereits ein erfahrener Entwickler sind oder mit Caches gearbeitet haben, wird es aus technischer Sicht in diesem Artikel höchstwahrscheinlich nichts Neues geben. Aber für einen Junior kann eine so kleine Rezension ihm sagen, in welche Richtung er schauen muss, wenn er sich an einem solchen Scheideweg befindet.

Als die neue Version der Sportmaster-Website in Produktion ging, wurden die Daten auf eine, gelinde gesagt, nicht sehr bequeme Weise empfangen. Grundlage waren Tabellen, die für die vorherige Version der Site (Bitrix) vorbereitet wurden, die in ETL gezogen, in eine neue Form gebracht und mit diversen Kleinigkeiten aus einem Dutzend weiterer Systeme angereichert werden mussten. Damit ein neues Bild oder eine neue Produktbeschreibung auf der Seite erschien, musste man bis zum nächsten Tag warten – Updates nur nachts, einmal am Tag.

Zunächst gab es in den ersten Wochen nach Produktionsstart so viele Sorgen, dass solche Unannehmlichkeiten für Content-Manager eine Kleinigkeit waren. Doch sobald sich alles beruhigt hatte, ging die Entwicklung des Projekts weiter – einige Monate später, Anfang 2015, begannen wir, das Admin-Panel aktiv weiterzuentwickeln. In den Jahren 2015 und 2016 läuft alles gut, wir veröffentlichen regelmäßig, das Admin-Panel deckt immer mehr Bereiche der Datenaufbereitung ab und wir bereiten uns darauf vor, dass unserem Team bald die wichtigste und komplexeste Sache anvertraut wird – das Produkt Schaltung (vollständige Aufbereitung und Pflege der Daten zu allen Produkten). Doch im Sommer 2017, kurz vor dem Start des Commodity-Kreislaufs, wird sich das Projekt in einer sehr schwierigen Situation befinden – gerade wegen Problemen beim Caching. Über diese Episode möchte ich im zweiten Teil dieser zweiteiligen Publikation sprechen.

Aber in diesem Beitrag werde ich aus der Ferne beginnen und einige Gedanken vorstellen – Ideen zum Caching, die ein guter Schritt zum Durchblättern vor einem großen Projekt wären.

Wenn eine Caching-Aufgabe auftritt

Die Caching-Aufgabe wird nicht einfach angezeigt. Wir sind Entwickler, schreiben ein Softwareprodukt und möchten, dass es gefragt ist. Wenn das Produkt gefragt und erfolgreich ist, werden Nutzer kommen. Und es kommen immer mehr. Und dann gibt es viele Benutzer und dann wird das Produkt stark ausgelastet.

In den ersten Phasen denken wir nicht an Optimierung und Codeleistung. Das Wichtigste ist die Funktionalität, die schnelle Einführung eines Piloten und das Testen von Hypothesen. Und wenn die Belastung steigt, pumpen wir das Eisen auf. Wir erhöhen es zwei- oder dreimal, fünfmal, vielleicht zehnmal. Irgendwo hier – die Finanzen lassen es nicht mehr zu. Wie oft wird sich die Anzahl der Benutzer erhöhen? Es wird nicht wie 10-2-5 sein, aber bei Erfolg wird es 10-100 bis 1000 Mal sein. Das heißt, früher oder später müssen Sie eine Optimierung durchführen.

Nehmen wir an, dass ein Teil des Codes (nennen wir diesen Teil eine Funktion) unangemessen lange dauert und wir die Ausführungszeit verkürzen möchten. Eine Funktion kann der Zugriff auf eine Datenbank oder die Ausführung einer komplexen Logik sein – Hauptsache, die Ausführung dauert lange. Wie stark können Sie die Ausführungszeit verkürzen? Im Grenzfall können Sie es auf Null reduzieren, nicht weiter. Wie können Sie die Ausführungszeit auf Null reduzieren? Antwort: Eliminieren Sie die Ausführung vollständig. Geben Sie stattdessen das Ergebnis sofort zurück. Wie erfahren Sie das Ergebnis? Antwort: entweder berechnen oder irgendwo suchen. Die Berechnung dauert lange. Und Spionieren bedeutet zum Beispiel, sich an das Ergebnis zu erinnern, das die Funktion beim letzten Aufruf mit denselben Parametern erzeugt hat.

Das heißt, die Implementierung der Funktion ist für uns nicht wichtig. Es genügt zu wissen, von welchen Parametern das Ergebnis abhängt. Wenn dann die Parameterwerte in Form eines Objekts dargestellt werden, das als Schlüssel in einem Speicher verwendet werden kann, kann das Ergebnis der Berechnung gespeichert und beim nächsten Zugriff ausgelesen werden. Wenn dieses Schreiben und Lesen des Ergebnisses schneller ist als das Ausführen der Funktion, haben wir einen Geschwindigkeitsgewinn. Die Höhe des Gewinns kann das 100-, 1000- und 100-fache erreichen (10^5 ist eher eine Ausnahme, aber bei einer relativ nacheilenden Basis ist dies durchaus möglich).

Grundvoraussetzungen für ein Caching-System

Die erste Voraussetzung für ein Caching-System ist eine schnelle Lesegeschwindigkeit und, in etwas geringerem Maße, eine Schreibgeschwindigkeit. Das stimmt, aber nur so lange, bis wir das System in die Produktion bringen.

Spielen wir diesen Fall.

Nehmen wir an, wir haben die aktuelle Auslastung mit Hardware bereitgestellt und führen nun schrittweise Caching ein. Die Anzahl der Benutzer wächst ein wenig, die Last wächst – wir fügen ein paar Caches hinzu, schrauben es hier und da ein. Das geht noch einige Zeit so weiter, mittlerweile werden schwere Funktionen praktisch nicht mehr aufgerufen – die gesamte Hauptlast fällt auf den Cache. Die Anzahl der Benutzer hat sich in dieser Zeit um das N-fache erhöht.

Und wenn die anfängliche Hardwareversorgung das 2- bis 5-fache betragen könnte, dann könnten wir mit Hilfe des Caches die Leistung um den Faktor 10 oder im guten Fall um den Faktor 100 verbessern, an manchen Stellen vielleicht sogar um den Faktor von 1000. Das heißt, auf derselben Hardware verarbeiten wir 100-mal mehr Anfragen. Großartig, du hast den Lebkuchen verdient!

Doch nun stürzte in einem schönen Moment zufällig das System ab und der Cache brach zusammen. Nichts Besonderes – schließlich wurde der Cache nach dem Anspruch „Hohe Lese- und Schreibgeschwindigkeit, der Rest ist egal“ ausgewählt.

Bezogen auf die Ausgangslast betrug unsere Eisenreserve das 2- bis 5-fache und die Belastung stieg in dieser Zeit um das 10- bis 100-fache. Mithilfe des Caches haben wir Aufrufe für schwere Funktionen eliminiert und daher hat alles funktioniert. Und wie oft wird unser System jetzt ohne Cache langsamer? Was wird mit uns passieren? Das System wird fallen.

Auch wenn unser Cache nicht abgestürzt ist, sondern nur für eine Weile geleert wurde, muss er aufgewärmt werden, was einige Zeit in Anspruch nehmen wird. Und in dieser Zeit liegt die Hauptlast auf der Funktionalität.

Fazit: Hochbelastete Produktionsprojekte erfordern von einem Caching-System nicht nur hohe Lese- und Schreibgeschwindigkeiten, sondern auch die Gewährleistung von Datensicherheit und Ausfallsicherheit.

Mehlauswahl

In einem Projekt mit einem Admin-Panel fiel die Wahl so aus: Zuerst haben wir Hazelcast installiert, weil Wir kannten dieses Produkt bereits aus Erfahrung auf der Hauptseite. Doch hier erwies sich diese Wahl als erfolglos – unter unserem Lastprofil ist Hazelcast nicht nur langsam, sondern furchtbar langsam. Und zu diesem Zeitpunkt hatten wir uns bereits für den Veröffentlichungstermin angemeldet.

Spoiler: Wie genau sich die Umstände entwickelt haben, dass wir eine so große Sache verpasst haben und in eine akute und angespannte Situation geraten sind – das erzähle ich euch im zweiten Teil – und wie es dazu kam und wie wir wieder rausgekommen sind. Aber jetzt sage ich einfach, dass es eine Menge Stress war, und „zum Nachdenken – irgendwie kann ich nicht denken, wir schütteln die Flasche.“ Auch „Shaking the Bottle“ ist ein Spoiler, dazu später mehr.

Was wir gemacht haben:

1. Wir erstellen eine Liste aller Systeme, die Google und StackOverflow vorschlagen. Etwas über 30
2. Wir schreiben Tests mit einer produktionstypischen Belastung. Dazu haben wir Daten aufgezeichnet, die das System in einer Produktionsumgebung durchlaufen – eine Art Sniffer für Daten nicht im Netzwerk, sondern innerhalb des Systems. Genau diese Daten wurden in den Tests verwendet.
3. Gemeinsam mit dem gesamten Team wählt jeder das nächste System aus der Liste aus, konfiguriert es und führt Tests durch. Es besteht den Test nicht, es trägt die Last nicht – wir werfen es weg und gehen zum nächsten in der Reihe über.
4. Am 17. System wurde klar, dass alles hoffnungslos war. Hören Sie auf, die Flasche zu schütteln, es ist Zeit, ernsthaft nachzudenken.

Dies ist jedoch eine Option, wenn Sie ein System auswählen müssen, das in vorbereiteten Tests „durch die Geschwindigkeit kommt“. Was ist, wenn es solche Tests noch nicht gibt und Sie schnell entscheiden möchten?

Lassen Sie uns diese Option modellieren (es ist schwer vorstellbar, dass ein Entwickler der Mittelstufe+ in einem Vakuum lebt und zum Zeitpunkt der Auswahl seine Präferenz, welches Produkt er zuerst ausprobieren möchte, noch nicht formalisiert hat – daher ist die weitere Argumentation eher eine Theoretiker/Philosophie/ über einen Junior).

Nachdem wir uns über die Anforderungen entschieden haben, beginnen wir mit der Auswahl einer sofort einsatzbereiten Lösung. Warum das Rad neu erfinden: Wir nehmen ein fertiges Caching-System.

Wenn Sie gerade erst anfangen und googeln, geben Sie die Bestellung auf oder nehmen Sie sie entgegen. Im Allgemeinen gelten jedoch folgende Richtlinien. Zunächst einmal werden Sie auf Redis stoßen, es ist überall zu hören. Dann werden Sie feststellen, dass EhCache das älteste und bewährteste System ist. Als nächstes werden wir über Tarantool schreiben, eine inländische Entwicklung, die einen einzigartigen Aspekt der Lösung aufweist. Und auch Ignite, denn es erfreut sich mittlerweile wachsender Beliebtheit und genießt die Unterstützung von SberTech. Am Ende steht noch Hazelcast, da es in der Unternehmenswelt häufig bei großen Unternehmen vorkommt.

Die Liste ist nicht vollständig; es gibt Dutzende von Systemen. Und wir werden nur eines vermasseln. Nehmen wir die ausgewählten 5 Systeme für den „Schönheitswettbewerb“ und treffen wir eine Auswahl. Wer wird der Gewinner sein?

Redis

Wir lesen, was sie auf der offiziellen Website schreiben.
Redis - OpenSource-Projekt. Bietet In-Memory-Datenspeicherung, die Möglichkeit, auf der Festplatte zu speichern, automatische Partitionierung, hohe Verfügbarkeit und Wiederherstellung nach Netzwerkausfällen.

Es scheint, dass alles in Ordnung ist, man kann es nehmen und anschrauben - alles, was man braucht, tut es. Aber schauen wir uns mal zum Spaß mal die anderen Kandidaten an.

ÄhCache

ÄhCache - „der am weitesten verbreitete Cache für Java“ (Übersetzung des Slogans von der offiziellen Website). Auch OpenSource. Und dann verstehen wir, dass Redis nicht für Java, sondern allgemein gedacht ist und dass für die Interaktion damit ein Wrapper erforderlich ist. Und EhCache wird bequemer sein. Was verspricht das System sonst noch? Zuverlässigkeit, bewährt, volle Funktionalität. Nun, es ist auch das häufigste. Und speichert Terabytes an Daten zwischen.

Redis ist vergessen, ich bin bereit, EhCache zu wählen.

Aber ein Gefühl des Patriotismus treibt mich dazu, herauszufinden, was an Tarantool gut ist.

Tarantool

Tarantool - erfüllt die Bezeichnung „Echtzeit-Datenintegrationsplattform“. Es klingt sehr kompliziert, also lesen wir die Seite im Detail und finden eine laute Aussage: „Cachet 100 % der Daten im RAM.“ Das dürfte Fragen aufwerfen – schließlich kann es viel mehr Daten als Speicher geben. Die Erklärung ist, dass Tarantool keine Serialisierung ausführt, um Daten aus dem Speicher auf die Festplatte zu schreiben. Stattdessen nutzt es Low-Level-Funktionen des Systems, bei denen der Speicher einfach einem Dateisystem mit sehr guter I/O-Leistung zugeordnet wird. Im Allgemeinen haben sie etwas Wunderbares und Cooles gemacht.

Schauen wir uns die Implementierungen an: Mail.ru Corporate Highway, Avito, Beeline, Megafon, Alfa-Bank, Gazprom ...

Wenn es noch Zweifel an Tarantool gab, dann macht mir der Umsetzungsfall bei Mastercard den Garaus. Ich nehme Tarantool.

Aber wie auch immer…

Ignite

… gibt es noch mehr Ignite, wird als „In-Memory-Computing-Plattform … In-Memory-Geschwindigkeit bei Petabytes an Daten“ angepriesen. Auch hier gibt es viele Vorteile: verteilter In-Memory-Cache, schnellster Schlüsselwertspeicher und Cache, horizontale Skalierung, hohe Verfügbarkeit, strikte Integrität. Im Allgemeinen stellt sich heraus, dass Ignite am schnellsten ist.

Implementierungen: Sberbank, American Airlines, Yahoo! Japan. Und dann erfahre ich, dass Ignite nicht nur in der Sberbank implementiert ist, sondern das SberTech-Team seine Leute zum Ignite-Team selbst schickt, um das Produkt zu verfeinern. Das ist absolut fesselnd und ich bin bereit, Ignite zu nehmen.

Es ist völlig unklar warum, ich schaue auf den fünften Punkt.

Hazelcast

Ich gehe auf die Seite Hazelcast, Lektüre. Und es stellt sich heraus, dass Hazelcast die schnellste Lösung für verteiltes Caching ist. Es ist um Größenordnungen schneller als alle anderen Lösungen und im Allgemeinen führend auf dem Gebiet des In-Memory-Datengrids. Vor diesem Hintergrund bedeutet es nicht, sich selbst zu respektieren, wenn man etwas anderes nimmt. Darüber hinaus wird ein redundanter Datenspeicher für den kontinuierlichen Betrieb des Clusters ohne Datenverlust verwendet.

Das war's, ich bin bereit, Hazelcast einzunehmen.

Vergleich

Aber wenn man genau hinschaut, werden alle fünf Kandidaten so beschrieben, dass jeder von ihnen der Beste ist. Wie man wählt? Wir können sehen, welches am beliebtesten ist, suchen nach Vergleichen und die Kopfschmerzen werden verschwinden.

So einen finden wir Bewertung, wählen Sie unsere 5 Systeme.

Hier sind sie sortiert: Redis steht an der Spitze, Hazelcast an zweiter Stelle, Tarantool und Ignite werden immer beliebter, EhCache war und bleibt derselbe.

Aber schauen wir mal Rechenmethode: Links zu Websites, allgemeines Interesse am System, Stellenangebote - großartig! Das heißt, wenn mein System ausfällt, sage ich: „Nein, es ist zuverlässig!“ Es gibt viele Stellenangebote..." Ein so einfacher Vergleich reicht nicht aus.

Bei all diesen Systemen handelt es sich nicht nur um Caching-Systeme. Sie verfügen auch über viele Funktionen, auch wenn Daten nicht zur Verarbeitung an den Client gepumpt werden, sondern umgekehrt: Der Code, der auf den Daten ausgeführt werden muss, wandert auf den Server, wird dort ausgeführt und das Ergebnis zurückgegeben. Und sie werden nicht so oft als separates Caching-System betrachtet.

Okay, geben wir nicht auf, suchen wir einen direkten Vergleich der Systeme. Nehmen wir die beiden besten Optionen – Redis und Hazelcast. Uns interessiert die Geschwindigkeit und wir werden sie anhand dieses Parameters vergleichen.

Hz vs. Redis

Das finden wir Vergleich:


Blau ist Redis, Rot ist Hazelcast. Hazelcast gewinnt überall, und dafür gibt es einen Grund: Es ist multithreaded, hochoptimiert, jeder Thread arbeitet mit seiner eigenen Partition, sodass es keine Blockierungen gibt. Und Redis ist Single-Threaded; es profitiert nicht von modernen Multi-Core-CPUs. Hazelcast verfügt über asynchrone E/A, Redis-Jedis über blockierende Sockets. Schließlich verwendet Hazelcast ein Binärprotokoll und Redis ist textzentriert, was bedeutet, dass es ineffizient ist.

Wenden wir uns für alle Fälle einer anderen Vergleichsquelle zu. Was wird er uns zeigen?

Redis vs. Hz

Andere Vergleich:


Hier hingegen ist Rot Redis. Das heißt, Redis übertrifft Hazelcast in Bezug auf die Leistung. Hazelcast gewann den ersten Vergleich, Redis gewann den zweiten. Hier erklärte sehr genau, warum Hazelcast den vorherigen Vergleich gewonnen hat.

Es stellte sich heraus, dass das Ergebnis des ersten Tests tatsächlich manipuliert war: Redis wurde in der Basisbox aufgenommen und Hazelcast wurde für einen Testfall maßgeschneidert. Dann stellt sich heraus: Erstens können wir niemandem vertrauen und zweitens müssen wir, wenn wir uns schließlich für ein System entscheiden, es noch richtig konfigurieren. Diese Einstellungen umfassen Dutzende, fast Hunderte von Parametern.

Schütteln der Flasche

Und den ganzen Prozess, den wir jetzt gemacht haben, kann ich mit folgender Metapher erklären: „Die Flasche schütteln.“ Das heißt, jetzt müssen Sie nicht mehr programmieren, jetzt geht es vor allem darum, den Stackoverflow lesen zu können. Und ich habe in meinem Team eine Person, einen Profi, der in kritischen Momenten genau so arbeitet.

Was macht er? Er sieht ein kaputtes Ding, sieht einen Stack-Trace, übernimmt einige Wörter daraus (welche sind sein Fachwissen im Programm), sucht bei Google und findet Stackoverflow unter den Antworten. Ohne zu lesen, ohne nachzudenken, wählt er unter den Antworten auf die Frage etwas aus, das dem Satz „Mach dies und das“ am ähnlichsten ist (eine solche Antwort zu wählen ist sein Talent, denn es ist nicht immer die Antwort, die die meisten Likes erhält). Sie sieht aus: Wenn sich etwas geändert hat, dann großartig. Wenn es sich nicht geändert hat, setzen Sie es zurück. Und wiederholen Sie die Start-Check-Suche. Und auf diese intuitive Art sorgt er dafür, dass der Code nach einiger Zeit funktioniert. Er weiß nicht warum, er weiß nicht, was er getan hat, er kann es nicht erklären. Aber! Diese Infektion funktioniert. Und „das Feuer ist gelöscht.“ Lassen Sie uns nun herausfinden, was wir getan haben. Wenn das Programm funktioniert, ist es um eine Größenordnung einfacher. Und es spart viel Zeit.

Diese Methode wird anhand dieses Beispiels sehr gut erklärt.

Früher war es sehr beliebt, ein Segelboot in einer Flasche zu sammeln. Gleichzeitig ist das Segelboot groß und zerbrechlich und der Flaschenhals ist sehr schmal, es ist unmöglich, es hineinzuschieben. Wie wird es zusammengebaut?

Es gibt eine solche Methode, sehr schnell und sehr effektiv.

Das Schiff besteht aus vielen Kleinigkeiten: Stöcke, Seile, Segel, Kleber. Wir haben das alles in eine Flasche gepackt.
Wir nehmen die Flasche mit beiden Händen und beginnen zu schütteln. Wir schütteln und schütteln sie. Und meistens stellt sich heraus, dass es sich natürlich um kompletten Müll handelt. Aber manchmal. Manchmal entpuppt es sich als Schiff! Genauer gesagt, etwas Ähnliches wie ein Schiff.

Wir zeigen jemandem etwas: „Seryoga, siehst du!?“ Und tatsächlich sieht es von weitem wie ein Schiff aus. Aber das darf nicht so weitergehen.

Es geht auch anders. Sie werden von fortgeschritteneren Leuten wie Hackern verwendet.

Ich habe diesem Kerl eine Aufgabe gegeben, er hat alles getan und ist gegangen. Und Sie sehen – es sieht aus, als wäre es geschafft. Und nach einer Weile, wenn der Code finalisiert werden muss, beginnt das wegen ihm ... Es ist gut, dass er es bereits geschafft hat, weit wegzulaufen. Das sind die Leute, die am Beispiel einer Flasche das machen werden: Sehen Sie, wo der Boden ist, biegt sich das Glas. Und es ist nicht ganz klar, ob es transparent ist oder nicht. Dann schneiden die „Hacker“ diesen Boden ab, setzen dort ein Schiff ein, kleben den Boden wieder auf und es ist, als ob es so sein soll.

Von der Problemstellung her scheint alles in Ordnung zu sein. Aber am Beispiel von Schiffen: Warum überhaupt dieses Schiff bauen, wer braucht es schon? Es bietet keine Funktionalität. Normalerweise sind solche Schiffe Geschenke an sehr hochrangige Personen, die sie als eine Art Symbol, als Zeichen auf ein Regal über sich stellen. Und wenn eine solche Person der Chef eines großen Unternehmens oder ein hochrangiger Beamter ist, wie wird die Flagge dann für einen solchen Hacker stehen, dem der Hals abgetrennt wurde? Es wäre besser, wenn er nie davon erfahren würde. Wie kommt es also dazu, dass diese Schiffe hergestellt werden, die einer wichtigen Person geschenkt werden können?

Der einzige Schlüsselort, an dem man wirklich nichts ändern kann, ist der Körper. Und der Schiffsrumpf passt genau in den Hals. Während das Schiff außerhalb der Flasche montiert wird. Aber es geht nicht nur um den Zusammenbau eines Schiffes, es ist ein echtes Schmuckhandwerk. An den Bauteilen werden spezielle Hebel angebracht, die dann ein Anheben ermöglichen. Zum Beispiel werden die Segel gefaltet, vorsichtig hineingebracht und dann mit Hilfe einer Pinzette sehr präzise und präzise gezogen und angehoben. Das Ergebnis ist ein Kunstwerk, das man mit gutem Gewissen und Stolz verschenken kann.

Und wenn das Projekt erfolgreich sein soll, muss mindestens ein Juwelier im Team sein. Jemand, dem die Qualität des Produkts am Herzen liegt und der alle Aspekte berücksichtigt, ohne auf etwas zu verzichten, selbst in stressigen Momenten, wenn die Umstände es erfordern, das Dringende auf Kosten des Wichtigen zu tun. Alle erfolgreichen Projekte, die nachhaltig sind und sich bewährt haben, basieren auf diesem Prinzip. Sie haben etwas sehr Präzises und Einzigartiges, etwas, das alle verfügbaren Möglichkeiten ausnutzt. Im Beispiel mit dem Schiff in der Flasche wird die Tatsache durchgespielt, dass der Schiffsrumpf durch den Hals geht.

Zurück zur Aufgabe der Auswahl unseres Caching-Servers: Wie könnte diese Methode angewendet werden? Ich biete diese Möglichkeit der Auswahl aus allen existierenden Systemen an – schütteln Sie nicht die Flasche, wählen Sie nicht, sondern schauen Sie sich an, was sie grundsätzlich haben, worauf Sie bei der Auswahl eines Systems achten sollten.

Wo nach Engpässen suchen?

Versuchen wir nicht, die Flasche zu schütteln, nicht alles, was da ist, einzeln durchzugehen, sondern sehen wir, welche Probleme entstehen, wenn wir für unsere Aufgabe plötzlich selbst ein solches System entwerfen. Selbstverständlich bauen wir das Fahrrad nicht zusammen, aber anhand dieses Diagramms können wir herausfinden, auf welche Punkte bei Produktbeschreibungen geachtet werden muss. Lassen Sie uns ein solches Diagramm skizzieren.

Wenn das System verteilt ist, verfügen wir über mehrere Server (6). Nehmen wir an, es sind vier (es ist praktisch, sie auf dem Bild zu platzieren, aber es können natürlich so viele sein, wie Sie möchten). Wenn sich die Server auf unterschiedlichen Knoten befinden, bedeutet das, dass sie alle einen Code ausführen, der dafür verantwortlich ist, dass diese Knoten einen Cluster bilden und im Falle einer Unterbrechung eine Verbindung herstellen und sich gegenseitig erkennen.

Wir benötigen auch Codelogik (2), bei der es eigentlich um Caching geht. Clients interagieren über eine API mit diesem Code. Clientcode (1) kann sich entweder innerhalb derselben JVM befinden oder über das Netzwerk darauf zugreifen. Die darin implementierte Logik ist die Entscheidung, welche Objekte im Cache belassen und welche gelöscht werden sollen. Wir verwenden Speicher (3), um den Cache zu speichern, aber bei Bedarf können wir einen Teil der Daten auf der Festplatte (4) speichern.

Mal sehen, in welchen Teilen die Belastung auftritt. Tatsächlich wird jeder Pfeil und jeder Knoten geladen. Erstens kann die Absenkung zwischen dem Client-Code und der API, wenn es sich um eine Netzwerkkommunikation handelt, deutlich spürbar sein. Zweitens kann es im Rahmen der API selbst zu Problemen mit der CPU kommen, wenn wir es mit komplexer Logik übertreiben. Und es wäre schön, wenn die Logik keine Zeit mit dem Gedächtnis verschwenden würde. Und es bleibt die Interaktion mit dem Dateisystem – in der üblichen Version ist dies Serialisieren/Wiederherstellen und Schreiben/Lesen.

Als nächstes folgt die Interaktion mit dem Cluster. Höchstwahrscheinlich wird es im selben System sein, es könnte aber auch separat sein. Hier müssen Sie auch die Datenübertragung dorthin, die Geschwindigkeit der Datenserialisierung und die Interaktionen zwischen dem Cluster berücksichtigen.

Nun können wir uns einerseits vorstellen, „welche Gänge sich im Cache-System drehen werden“, wenn Anfragen aus unserem Code verarbeitet werden, und andererseits können wir abschätzen, welche und wie viele Anfragen unser Code für dieses System generieren wird. Dies reicht aus, um eine mehr oder weniger nüchterne Entscheidung zu treffen – ein System für unseren Anwendungsfall auszuwählen.

Hazelcast

Sehen wir uns an, wie wir diese Zerlegung auf unsere Liste anwenden können. Zum Beispiel Hazelcast.

Um Daten von Hazelcast bereitzustellen/zu übernehmen, greift der Clientcode auf (1) die API zu. Mit Hz können Sie den Server eingebettet ausführen. In diesem Fall ist der Zugriff auf die API ein Methodenaufruf innerhalb der JVM, der als kostenlos betrachtet werden kann.

Damit die Logik in (2) funktioniert, verlässt sich Hz auf den Hash des Byte-Arrays des serialisierten Schlüssels – das heißt, der Schlüssel wird in jedem Fall serialisiert. Dies ist für Hz ein unvermeidlicher Mehraufwand.
Räumungsstrategien werden gut umgesetzt, aber für besondere Fälle können Sie Ihre eigenen hinzufügen. Sie müssen sich um diesen Teil keine Sorgen machen.

Speicher (4) anschließbar. Großartig. Die Interaktion (5) für eingebettete Elemente kann als sofort betrachtet werden. Datenaustausch zwischen Knoten im Cluster (6) – ja, den gibt es. Dies ist eine Investition in Fehlertoleranz auf Kosten der Geschwindigkeit. Mit der Near-Cache-Funktion von Hz können Sie den Preis senken – von anderen Knoten im Cluster empfangene Daten werden zwischengespeichert.

Was kann man unter solchen Bedingungen tun, um die Geschwindigkeit zu erhöhen?

Um beispielsweise eine Serialisierung des Schlüssels in (2) zu vermeiden, fügen Sie einen weiteren Cache über Hazelcast hinzu, um die heißesten Daten zu erhalten. Zu diesem Zweck hat sich Sportmaster für Caffeine entschieden.

Für das Twisten auf Level (6) bietet Hz zwei Speicherarten an: IMap und ReplicatedMap.


Es ist erwähnenswert, wie Hazelcast in den Technologie-Stack von Sportmaster gelangt ist.

Als wir 2012 am allerersten Pilotprojekt der zukünftigen Website arbeiteten, stellte sich heraus, dass Hazelcast der erste Link war, den die Suchmaschine zurückgab. Die Bekanntschaft startete „beim ersten Mal“ – wir waren fasziniert davon, dass es bereits zwei Stunden später, als wir Hz ins System schraubten, funktionierte. Und es hat gut funktioniert. Am Ende des Tages hatten wir einige Tests abgeschlossen und waren zufrieden. Und diese Kraftreserve reichte aus, um die Überraschungen zu überwinden, die Hz im Laufe der Zeit mit sich brachte. Jetzt hat das Sportmaster-Team keinen Grund, Hazelcast aufzugeben.

Aber Argumente wie „der erste Link in der Suchmaschine“ und „HelloWorld war schnell zusammengestellt“ sind natürlich eine Ausnahme und ein Merkmal des Moments, in dem die Wahl erfolgte. Die eigentlichen Tests für das ausgewählte System beginnen mit der Freigabe in die Produktion, und genau auf diese Phase sollten Sie bei der Auswahl eines Systems, einschließlich Cache, achten. Eigentlich können wir in unserem Fall sagen, dass wir uns zufällig für Hazelcast entschieden haben, aber dann stellte sich heraus, dass wir die richtige Wahl getroffen hatten.

Für die Produktion viel wichtiger: Überwachung, Umgang mit Fehlern auf einzelnen Knoten, Datenreplikation, Kosten der Skalierung. Das heißt, es lohnt sich, auf die Aufgaben zu achten, die bei der Wartung des Systems anfallen – wenn die Auslastung um das Zehnfache höher ist als geplant, wenn wir versehentlich etwas an der falschen Stelle hochladen, wenn wir eine neue Version einführen müssen des Codes, ersetzen Sie Daten und tun Sie dies unbemerkt für Kunden.

Für all diese Anforderungen ist Hazelcast genau das Richtige.

Fortsetzung folgt

Aber Hazelcast ist kein Allheilmittel. Im Jahr 2017 haben wir uns für Hazelcast für den Admin-Cache entschieden, einfach aufgrund der guten Eindrücke aus der Vergangenheit. Dies spielte eine Schlüsselrolle in einem sehr grausamen Witz, aufgrund dessen wir uns in einer schwierigen Situation befanden und 60 Tage lang „heldenhaft“ daraus herauskamen. Aber mehr dazu im nächsten Teil.

In der Zwischenzeit... Frohes Neues Code!

Source: habr.com