🏂🏿 🔫 👩🏾‍🚀 Wie wir bei Sportmaster ein Caching-System gewählt haben. Teil 1 🧖🏻 👨‍💻 📥

Hallo! Mein Name ist Alexey Pyankov, ich bin Entwickler bei Sportmaster. In diesem Beitrag habe ich darüber gesprochen, wie die Arbeit an der Sportmaster-Website im Jahr 2012 begann, welche Initiativen wir durchsetzen konnten und umgekehrt, welchen Rechen wir gesammelt haben.

Heute möchte ich die Gedanken teilen, die einer anderen Geschichte folgen - die Auswahl eines Caching-Systems für das Java-Backend im Admin-Bereich der Site. Diese Handlung ist für mich von besonderer Bedeutung - obwohl die Geschichte nur 2 Monate dauerte, arbeiteten wir diese 60 Tage 12-16 Stunden und ohne freien Tag. Ich hätte nie gedacht und mir vorgestellt, dass man so viel arbeiten kann.

Daher teile ich den Text in 2 Teile, um ihn nicht vollständig herunterzuladen. Im Gegenteil, der erste Teil wird sehr einfach sein - Vorbereitung, Einführung, einige Überlegungen, was Caching ist. Wenn Sie bereits ein erfahrener Entwickler sind oder mit Caches gearbeitet haben - technisch gesehen - enthält dieser Artikel höchstwahrscheinlich nichts Neues. Aber für einen Junior kann eine kleine solche Bewertung sagen, wie er aussehen soll, wenn er sich an einem solchen Scheideweg befindet.

Als die neue Version der Sportmaster-Website in Produktion ging, kamen die Daten, gelinde gesagt, nicht sehr praktisch. Grundlage waren die Tabellen, die für die vorherige Version der Site (Bitrix) erstellt wurden, die in ETL verschärft, neu gestaltet und mit verschiedenen Kleinigkeiten aus einem Dutzend weiterer Systeme angereichert werden musste. Damit ein neues Bild oder eine neue Produktbeschreibung auf der Website angezeigt wird, mussten Sie bis zum nächsten Tag warten - Aktualisierung nur nachts, 1 Mal pro Tag.

Anfangs gab es in den ersten Wochen nach Produktionsbeginn so viele Sorgen, dass solche Unannehmlichkeiten für Content Manager eine Kleinigkeit waren. Sobald sich alles beruhigt hatte, wurde die Entwicklung des Projekts fortgesetzt - einige Monate später, Anfang 2015, begannen wir, das Admin-Panel aktiv weiterzuentwickeln. In den Jahren 2015 und 2016 läuft alles gut, wir werden es regelmäßig veröffentlichen, der Administrationsbereich deckt den größten Teil der Datenaufbereitung ab und wir bereiten uns darauf vor, dass bald das Wichtigste und Schwierigste unserem Team anvertraut wird - die Produktlinie (vollständige Aufbereitung und Pflege der Daten für alle Produkte). Im Sommer 2017, kurz vor dem Start der Produktlinie, wird sich das Projekt jedoch in einer sehr schwierigen Situation befinden - gerade wegen Caching-Problemen. Ich möchte über diese Episode im zweiten Teil dieser zweiteiligen Veröffentlichung sprechen.

Aber in diesem Beitrag beginne ich wie einige Gedanken von weitem - Ideen zum Zwischenspeichern, die vor einem großen Projekt im Voraus gescrollt werden sollten, wäre ein guter Schritt.

Wenn eine Cache-Aufgabe auftritt

Die Caching-Aufgabe wird nicht nur angezeigt. Wir sind Entwickler, wir schreiben ein Softwareprodukt und wir möchten, dass es gefragt ist. Wenn das Produkt gefragt und erfolgreich ist, kommen Benutzer. Und mehr kommen und mehr. Und so gibt es viele Benutzer und dann wird das Produkt hoch geladen.

In den ersten Phasen denken wir nicht an Optimierung und Codeleistung. Die Hauptsache ist die Funktionalität, die schnelle Einführung des Piloten und das Testen von Hypothesen. Und wenn die Last wächst, pumpen wir Eisen. Wir erhöhen es um den Faktor zwei, drei, fünf, lassen es zehnmal sein. Irgendwo hier - die Finanzen werden es nicht mehr zulassen. Und wie oft wird die Anzahl der Benutzer steigen? Es wird nicht nur 2-5-10 sein, sondern wenn es erfolgreich ist, wird es von 100-1000 und bis zu 100.000 Mal sein. Das heißt, früher oder später, muss aber die Optimierung durchführen.

Nehmen wir an, ein Teil des Codes (nennen wir diesen Teil eine Funktion) funktioniert lange Zeit unanständig, und wir möchten die Ausführungszeit reduzieren. Funktion - es kann der Zugriff auf die Datenbank sein, es kann die Ausführung einer komplexen Logik sein - die Hauptsache ist, dass es lange dauert. Wie viel können Sie die Vorlaufzeit reduzieren? Im Limit - kann nicht weiter auf Null reduziert werden. Und wie können Sie die Laufzeit auf Null reduzieren? Antwort: Ausschluss generell ausschließen. Geben Sie stattdessen sofort das Ergebnis zurück. Und woher kennst du das Ergebnis? Antwort: entweder berechnen oder irgendwo suchen. Berechnen ist eine lange Zeit. Und gucken heißt zum Beispiel, sich an das Ergebnis zu erinnern, das die Funktion beim letzten Aufruf mit denselben Parametern zuletzt erzeugt hat.

Das heißt, die Implementierung der Funktion spielt für uns keine Rolle. Es reicht zu wissen, von welchen Parametern das Ergebnis abhängt. Wenn die Parameterwerte dann in Form eines Objekts dargestellt werden, das in einem Speicher als Schlüssel verwendet werden kann, können wir das Ergebnis der Berechnung speichern und beim nächsten Mal lesen. Wenn diese Schreib- / Leseergebnisse schneller sind als die Ausführung der Funktion, erzielen wir einen Geschwindigkeitsgewinn. Der Gewinnwert kann das 100-, 1000- und 100.000-fache erreichen (10 ^ 5 ist eher eine Ausnahme, aber bei einer anständigen Verzögerungsbasis ist dies durchaus möglich).

Wichtige Caching-Anforderungen

Das erste, was für ein Caching-System erforderlich werden kann, ist eine schnelle Lesegeschwindigkeit und in etwas geringerem Maße eine Schreibgeschwindigkeit. Dies ist so, aber nur bis wir das System in der Produktion einführen.

Lassen Sie uns einen solchen Fall spielen.

Angenommen, wir haben die aktuelle Ladung mit Eisen versorgt und führen nun schrittweise das Caching ein. Die Benutzer wachsen ein bisschen, die Last wächst - wir fügen ein wenig Caches hinzu, wir befestigen sie hier und da. Dies ist schon seit einiger Zeit so, und jetzt werden die schweren Funktionen praktisch nicht mehr aufgerufen - die Hauptlast liegt beim Cache. Die Anzahl der Benutzer in dieser Zeit ist N-mal gestiegen.

Und wenn die anfängliche Eisenversorgung 2-5-mal sein könnte, könnten wir mit Hilfe des Caches die Produktivität alle 10 oder in einem guten Fall 100-mal an einigen Stellen, möglicherweise 1000, erhöhen. Das heißt, wir verarbeiten auf demselben Eisen 100 mal mehr Anfragen. Großartig, verdiene einen Lebkuchen!

Aber jetzt stürzte das System versehentlich ab und der Cache stürzte ab. Nichts Besonderes - schließlich wurde der Cache bei Bedarf ausgewählt "Hochgeschwindigkeitslesen und -schreiben, der Rest spielt keine Rolle."

In Bezug auf die Startlast betrug die Eisenreserve das 2-5-fache, und die Last stieg während dieser Zeit um das 10-100-fache. Mit Hilfe des Caches haben wir Anrufe für schwere Funktionen eliminiert und daher flog alles. Und jetzt, ohne Cache - wie oft hängt unser System ab? Was wird mit uns passieren? Das System wird fallen.

Selbst wenn unser Cache nicht abgestürzt ist, sondern nur für eine Weile gelöscht wurde, muss er aufgewärmt werden, und dies wird einige Zeit dauern. Und zu diesem Zeitpunkt wird die Hauptlast auf die Funktion fallen.

Fazit: Hochlastprojekte im Produkt erfordern vom Caching-System nicht nur eine hohe Lese- und Schreibgeschwindigkeit, sondern auch Datensicherheit und Fehlerresistenz.

Mehl der Wahl

Im Projekt mit dem Admin-Panel ging die Wahl so: Zuerst haben sie Hazelcast gesetzt, weil waren bereits mit diesem Produkt aus der Erfahrung der Hauptseite vertraut. Aber hier war diese Wahl erfolglos - für unser Lastprofil arbeitet Hazelcast nicht nur langsam, sondern auch furchtbar langsam. Und zu diesem Zeitpunkt haben wir uns bereits für die Rücknahmebedingungen für das Produkt angemeldet.

Spoiler: Wie genau sind die Umstände entstanden, dass wir einen solchen Plop verpasst haben und eine akute und angespannte Situation hatten - ich werde im zweiten Teil erzählen - sowohl wie wir uns herausstellten als auch wie wir herauskamen. Aber jetzt - ich sage nur, dass es viel Stress war und "denke - irgendwie denke ich nicht, schüttle die Flasche." "Shaking the Bottle" ist auch ein Spoiler, etwas weiter.

Was haben wir getan:

Wir erstellen eine Liste aller Systeme, die von Google und StackOverflow aufgefordert werden. Etwas mehr als 30
, . , - — , .
, , , . , – , .
17- , . « », .

Dies ist jedoch eine Option, wenn Sie ein System auswählen müssen, das in vorbereiteten Tests "schnell kriecht". Und wenn es noch keine solchen Tests gibt und Sie schneller wählen möchten?

Wir werden eine solche Option simulieren (es ist schwer vorstellbar, dass der mittlere Entwickler in einem Vakuum lebt, und zum Zeitpunkt der Auswahl hatte er noch nicht entschieden, welches Produkt er zuerst ausprobieren sollte - daher ist eine weitere Diskussion eher ein Theoretiker / eine Philosophie / über einen Junior).

Nachdem wir die Anforderungen festgelegt haben, werden wir beginnen, eine Lösung aus der Box auszuwählen. Warum das Rad neu erfinden: Wir werden ein fertiges Caching-System nehmen.

Wenn Sie gerade erst anfangen und googeln, dann plus oder minus der Bestellung, aber im Allgemeinen werden die Richtlinien so sein. Zunächst einmal stolpern Sie über Redis, es ist überall zu hören. Dann werden Sie feststellen, dass es EhCache als ältestes und bewährtes System gibt. Dann wird über Tarantool geschrieben - eine häusliche Entwicklung, bei der es einen einzigartigen Aspekt der Lösung gibt. Und auch Ignite, denn es erfreut sich immer größerer Beliebtheit und wird von SberTech unterstützt. Am Ende gibt es Hazelcast, weil es in der Unternehmenswelt oft inmitten großer Unternehmen blinkt.

Diese Liste endet nicht dort, es gibt Dutzende von Systemen. Und wir schrauben nur einen. Nehmen Sie die ausgewählten 5 Systeme für den "Schönheitswettbewerb" und führen Sie eine Auswahl durch. Wer wird der Gewinner sein?

Redis

Wir lesen, was sie auf der offiziellen Website schreiben.
Redis ist ein Open Source Projekt. Es bietet speicherinternen Datenspeicher, die Möglichkeit, auf der Festplatte zu speichern, automatisch in Partitionen zu partitionieren, hohe Verfügbarkeit und Wiederherstellung nach Netzwerkunterbrechungen.

Es scheint, dass alles in Ordnung ist, man kann es nehmen und anschrauben - alles was er braucht ist was er tut. Aber schauen wir uns nur das Interesse an den anderen Kandidaten an.

Ehcache

EhCache - „der am häufigsten verwendete Cache für Java“ (Übersetzung des Slogans von der offiziellen Website). Auch OpenSource. Und hier verstehen wir, dass Redis nicht unter Java steht, sondern allgemein, und um damit zu interagieren, benötigen Sie einen Wrapper. Und EhCache wird bequemer sein. Was verspricht das System noch? Zuverlässigkeit, Offenheit, volle Funktionalität. Nun, und sie ist die häufigste. Und speichert Terabytes an Daten zwischen.

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

Aber ein Gefühl des Patriotismus drängt mich zu sehen, was Tarantool gut macht.

Tarantool

Tarantool - Erfüllt die Bezeichnung "Echtzeit-Datenintegrationsplattform". Es klingt sehr schwierig, deshalb lesen wir die Seite im Detail und finden eine laute Aussage: "Zwischenspeichert 100% der Daten im RAM." Dies sollte Fragen aufwerfen - schließlich kann es viel mehr Daten als Speicher geben. Die Entschlüsselung besteht darin, dass hier impliziert wird, dass Tarantool keine Serialisierung ausführt, um Daten aus dem Speicher auf eine Festplatte zu schreiben. Stattdessen werden die Low-Level-Funktionen des Systems verwendet, wenn der Speicher einfach einem Dateisystem mit sehr guter E / A-Leistung zugeordnet wird. Im Allgemeinen haben sie es irgendwie wunderbar und cool gemacht.

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

Wenn es noch Zweifel an Tarantool gäbe, würde mich die Einführung der Mastercard-Implementierung umbringen. Ich nehme Tarantool.

Aber wie auch immer…

Entzünden

... gibt es Ignite , das als "In-Memory-Computing-Plattform ... In-Memory-Geschwindigkeiten für Petabyte Daten" deklariert ist. Es gibt auch viele Vorteile: verteilter In-Memory-Cache, schnellster Schlüsselwertspeicher und -cache, horizontale Skalierung, hohe Verfügbarkeit, strenge Integrität. Im Allgemeinen stellt sich heraus, dass Ignite am schnellsten ist.

Implementierungen: Sberbank, American Airlines, Yahoo! Japan Und dann finde ich immer noch heraus, dass Ignite nicht nur in Sberbank implementiert ist, sondern das SberTech-Team seine Mitarbeiter an das Ignite-Team sendet, um das Produkt fertigzustellen. Das ist absolut fesselnd und ich bin bereit, Ignite zu nehmen.

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

Hazelcast

Ich gehe zur Hazelcast- Website und lese sie. Und es stellt sich heraus, dass Hazelcast die schnellste Lösung für verteiltes Caching ist. Er ist um Größenordnungen schneller als alle anderen Lösungen und im Allgemeinen führend auf dem Gebiet des In-Memory-Datengitters. Nehmen Sie vor diesem Hintergrund etwas anderes - respektieren Sie sich nicht. Es verwendet auch redundanten Datenspeicher für den kontinuierlichen Betrieb des Clusters ohne Datenverlust.

Alles, ich bin bereit, Hazelcast zu nehmen.

Vergleich

Aber wenn Sie schauen, dann sind alle fünf Kandidaten so gemalt, dass jeder von ihnen der beste ist. Wie man wählt? Wir können sehen, welches am beliebtesten ist, nach Vergleichen suchen und die Kopfschmerzen werden vergehen.

Wir finden eine solche Bewertung , wählen Sie unsere 5 Systeme.

Hier sind sie sortiert: An der Spitze von Redis, an zweiter Stelle stehen Hazelcast, Tarantool und Ignite werden immer beliebter, EhCache war und ist.

Aber schauen wir uns die Berechnungsmethode an : Links zu Websites, allgemeines Interesse am System, Stellenangebote - großartig! Das heißt, wenn mein System ausfällt, werde ich sagen: „Nein, es ist zuverlässig! Hier gibt es viele Stellenangebote ... ". Ein so einfacher Vergleich wird nicht funktionieren.

Alle diese Systeme sind nicht nur Caching-Systeme. Sie haben immer noch viele Funktionen, auch wenn die Daten nicht zur Verarbeitung an den Client übertragen werden, sondern: Der Code, der auf den Daten ausgeführt werden muss, wird auf den Server verschoben, dort ausgeführt und das Ergebnis zurückgegeben. Und als separates System für das Caching werden sie nicht so oft in Betracht gezogen.

Nun, nicht aufgeben, wir finden einen direkten Vergleich der Systeme. Nehmen Sie die beiden besten Optionen - Redis und Hazelcast. Wir sind an Geschwindigkeit interessiert, wir können sie anhand dieses Parameters vergleichen.

Hz gegen Redis

Wir finden einen solchen Vergleich :

Blau ist Redis, Rot ist Hazelcast. Hazelcast gewinnt überall und die Begründung lautet: Es ist Multithread-fähig, hochoptimiert, jeder Thread arbeitet mit einer eigenen Partition, sodass es keine Sperren gibt. Und Redis ist Single-Threaded, es profitiert nicht von modernen Multi-Core-CPUs. Hazelcast hat asynchrone E / A, Redis-Jedis hat Sockets blockiert. Am Ende verwendet Hazelcast ein Binärprotokoll, während Redis textorientiert ist, was bedeutet, dass es ineffizient ist.

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

Redis vs Hz

Ein weiterer Vergleich :

Hier ist Rot im Gegenteil Redis. Das heißt, Redis übertrifft Hazelcast in der Leistung. Im ersten Vergleich gewann Hazelcast, im zweiten Redis. Hier erklärten sie sehr genau, warum Hazelcast im vorherigen Vergleich gewonnen hat.

Es stellt sich heraus, dass das Ergebnis des ersten tatsächlich manipuliert wurde: Redis wurde in die Basisbox genommen und Hazelcast wurde für einen Testfall eingesperrt. Dann stellt sich heraus: Erstens kann niemandem vertraut werden, und zweitens müssen wir es immer noch richtig konfigurieren, wenn wir uns dennoch für ein System entscheiden. Diese Einstellungen umfassen Dutzende, fast Hunderte von Parametern.

Eine Flasche schütteln

Und den ganzen Prozess, den wir gerade gemacht haben, kann ich mit einer solchen Metapher erklären: "Schüttle die Flasche." Das heißt, jetzt können Sie nicht programmieren, jetzt ist die Hauptsache, Stackoverflow lesen zu können. Und in meinem Team gibt es eine Person, einen Fachmann, der in kritischen Momenten einfach so arbeitet.

Was macht er? Er sieht eine kaputte Sache, sieht eine Stapelspur, nimmt einige seiner Wörter (welche sind seine Fachkenntnisse im Programm), sucht in Google und findet einen Stapelüberlauf unter den Antworten. Ohne zu lesen, ohne nachzudenken, wählt er unter den Antworten auf die Frage etwas, das dem Satz "dies und das tun" am ähnlichsten ist (die Wahl einer solchen Antwort ist sein Talent, da es nicht immer die Antwort ist, die mehr Likes gesammelt hat), die er verwendet sieht aus: wenn sich etwas geändert hat, dann gut. Wenn es sich nicht geändert hat, rollen wir zurück. Und wir wiederholen die Start-Check-Suche. Und auf solch intuitive Weise erreicht er, 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 gelöscht". Jetzt verstehen wir, was wir getan haben. Wenn das Programm funktioniert, ist es viel einfacher.Und spart erheblich Zeit.

Diese Methode wird durch ein solches Beispiel sehr gut erklärt.

Es war einmal sehr beliebt, ein Segelboot in einer Flasche zu sammeln. Gleichzeitig ist das Segelboot groß und zerbrechlich, und der Flaschenhals ist sehr schmal, man kann ihn nicht hineinschieben. Wie montiere ich es?

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

Das Schiff besteht aus ein paar kleinen Dingen: Stöcken, Seilen, Segeln, Kleber. Wir packen das alles in eine Flasche.
Wir nehmen die Flasche mit beiden Händen und fangen an zu zittern. Wir zittern, zittern. Und normalerweise bekommt man natürlich kompletten Müll. Aber manchmal. Manchmal bekommt man ein Schiff! Genauer gesagt, etwas ähnlich wie ein Schiff.

Wir zeigen dies jemandem: "Serge, sehen Sie !?". Und zwar aus der Ferne - als wäre es ein Schiff. Aber dann kannst du das nicht loslassen.

Es geht auch anders. Die Jungs benutzen fortgeschrittenere, solche Hacker.

Hat so einem Kerl eine Aufgabe gegeben, er hat alles getan und ist gegangen. Und du siehst aus - es scheint getan zu sein. Und nach einer Weile, wenn es notwendig ist, den Code zu verfeinern - dort beginnt es deswegen ... Es ist gut, dass er es bereits geschafft hat, weit wegzulaufen. Das sind die Leute, die am Beispiel einer Flasche Folgendes tun: Sie sehen, wo der Boden ist - das Glas biegt sich. Und es ist nicht ganz klar, ob es transparent ist oder nicht. Dann schneiden die „Hacker“ diesen Boden ab, setzen das Schiff dort ein, fügen den Boden erneut ein und als ob es notwendig wäre.

Unter dem Gesichtspunkt der Problemstellung scheint alles korrekt zu sein. Aber hier ist ein Beispiel für Schiffe: Warum macht dieses Schiff im Allgemeinen, wer braucht es überhaupt? Es hat keine Funktionalität. Normalerweise sind solche Schiffe Geschenke an sehr hochrangige Leute, die sie als Symbol als Zeichen auf ein Regal über sich stellen. Und jetzt, wenn eine solche Person, der Leiter eines großen Unternehmens oder ein hochrangiger Beamter, wie steht die Flagge für solchen Müll, in den der Hals geschnitten ist? Es wäre besser, wenn er nie davon wüsste. Wie werden diese Schiffe letztendlich hergestellt, die einer wichtigen Person präsentiert werden können?

Der einzige Ort, Schlüssel, mit dem wirklich nichts zu tun ist, ist das Gebäude. Und der Rumpf des Schiffes geht gerade durch den Hals. Während das Schiff außerhalb der Flasche fährt. Aber es geht nicht nur darum, ein Schiff zusammenzubauen, es ist ein echtes Schmuckhandwerk. Den Bauteilen werden spezielle Hebel hinzugefügt, mit denen sie später angehoben werden können. Zum Beispiel werden die Segel gefaltet, sanft hineingetrieben und dann mit Hilfe einer Pinzette ist es sehr Schmuck, sicher, sie werden gezogen und angehoben. Das Ergebnis ist ein Kunstwerk, das mit gutem Gewissen und Stolz präsentiert werden kann.

Und wenn das Projekt erfolgreich sein soll, muss mindestens ein Juwelier im Team sein. Jeder, der sich um die Qualität des Produkts kümmert und alle Aspekte berücksichtigt, ohne auch in stressigen Zeiten einen einzigen zu opfern, wenn die Umstände dies zum Nachteil der Wichtigen dringend erfordern. Alle erfolgreichen Projekte, die nachhaltig sind, die sich bewährt haben, bauen auf diesem Prinzip auf. Sie haben etwas sehr Präzises und Einzigartiges, das alle verfügbaren Funktionen nutzt. Am Beispiel eines Schiffs in einer Flasche wird ausgespielt, dass der Schiffsrumpf durch den Hals verläuft.

Wie könnte diese Methode angewendet werden, um zur Auswahl unseres Caching-Servers zurückzukehren? Ich schlage eine solche Option aus allen Systemen vor, die es gibt - schütteln Sie nicht die Flasche, wählen Sie nicht, sondern sehen Sie, worauf sie bei der Auswahl eines Systems im Prinzip achten müssen.

Wo man nach Flaschenhals sucht

Lassen Sie uns versuchen, die Flasche nicht zu schütteln, nicht alles zu sortieren, was wiederum ist, sondern zu sehen, welche Aufgaben, wenn auch plötzlich, für Ihre Aufgabe entstehen - ein solches System selbst zu entwerfen. Natürlich werden wir das Fahrrad nicht zusammenbauen, aber wir werden dieses Schema verwenden, um uns an den Punkten zu orientieren, auf die in den Produktbeschreibungen zu achten ist. Wir skizzieren ein solches Schema.

Wenn das System verteilt ist, haben wir mehrere Server (6). Sagen wir vier (es ist praktisch, sie auf dem Bild zu platzieren, aber es kann natürlich eine beliebige Anzahl davon geben). Wenn sich die Server auf verschiedenen Knoten befinden, bedeutet dies, dass sich auf allen ein Teil des Codes dreht. Dies ist dafür verantwortlich, dass diese Knoten einen Cluster bilden und sich im Falle einer Unterbrechung gegenseitig verbinden und erkennen.

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

Mal sehen, in welchen Teilen die Last auftreten wird. Tatsächlich werden jeder Pfeil und jeder Knoten geladen. Erstens kann zwischen Client-Code und API, wenn es sich um eine Netzwerkinteraktion handelt, ein Absinken durchaus spürbar sein. Zweitens können wir im Rahmen der API selbst - nachdem wir sie mit komplexer Logik überschrieben haben - auf die CPU stoßen. Und es wäre gut, wenn die Logik den Speicher nicht noch einmal ansteuern würde. Und es bleibt die Interaktion mit dem Dateisystem - in der üblichen Version wird es serialisiert / wiederhergestellt und geschrieben / gelesen.

Weitere Interaktion mit dem Cluster. Höchstwahrscheinlich befindet es sich im selben System, kann jedoch separat ausgeführt werden. Hier müssen Sie auch die Datenübertragung berücksichtigen, die Geschwindigkeit der Datenserialisierung und die Interaktion zwischen dem Cluster.

Einerseits können wir uns vorstellen, welche Zahnräder sich im Cache-System drehen, wenn Anforderungen aus unserem Code verarbeitet werden, und andererseits können wir abschätzen, welche und wie viele Anforderungen unser Code an dieses System generiert. Dies reicht aus, um eine mehr oder weniger nüchterne Wahl zu treffen - um ein System für unseren Anwendungsfall zu wählen.

Hazelcast Mal

sehen, wie diese Zerlegung auf unsere Liste zutrifft. Zum Beispiel Hazelcast.

Um Daten von Hazelcast abzulegen / abzurufen, greift der Client-Code auf (1) die API zu. Mit Hz können Sie den Server als eingebettet starten. In diesem Fall ist der Zugriff auf die API ein Methodenaufruf innerhalb der JVM. Sie können ihn kostenlos lesen.

Um die Logik in (2) zu erarbeiten, stützt sich Hz auf einen Hash aus dem Byte-Array des serialisierten Schlüssels - das heißt, die Schlüssel-Serialisierung erfolgt in jedem Fall. Dies ist ein unvermeidlicher Overhead für Hz.
Räumungsstrategien sind gut implementiert, aber für spezielle Fälle können Sie Ihre eigenen verbinden. Sie müssen sich um diesen Teil keine Sorgen machen.

Speicher (4) kann angeschlossen werden. Fein. Die Interaktion (5) für Embedded kann als sofort betrachtet werden. Der Datenaustausch zwischen Knoten im Cluster (6) - ja, das ist es. Dies trägt zur Ausfallsicherheit auf Kosten der Geschwindigkeit bei. Die Hz-Funktion von Near-Cache ermöglicht das Verringern des Preises - Daten, die von anderen Knoten des Clusters empfangen werden, werden zwischengespeichert.

Was kann unter solchen Bedingungen getan werden, um die Geschwindigkeit zu erhöhen?

Um beispielsweise zu vermeiden, dass der Schlüssel in (2) über Hazelcast serialisiert wird, schrauben Sie einen weiteren Cache für die heißesten Daten. Bei Sportmaster wurde zu diesem Zweck Koffein ausgewählt.

Für das Verdrehen auf Stufe (6) bietet Hz zwei Arten von Speicher: IMap und ReplicatedMap.

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

Als wir 2012 an dem allerersten Pilotprojekt der zukünftigen Site arbeiteten, stellte sich heraus, dass Hazelcast der erste Link war, den die Suchmaschine herausgab. Die Bekanntschaft begann „das erste Mal“ - wir waren beeindruckt von der Tatsache, dass es nur zwei Stunden später funktionierte, als wir die Hz in das System einschraubten. Und es hat gut funktioniert. Bis zum Ende des Tages haben wir einige Tests hinzugefügt, wir waren froh. Und diese Kraft reichte aus, um die Überraschungen zu überwinden, die Hz im Laufe der Zeit mit sich brachte. Jetzt hat das Sportmaster-Team keinen Grund, Hazelcast abzulehnen.

Aber Argumente wie "der erste Link in einer Suchmaschine" und "schnell zusammengestellte HelloWorld" sind natürlich eine Ausnahme und ein Merkmal des Augenblicks, in dem die Wahl getroffen wurde. Diese Tests für das ausgewählte System beginnen mit der Freigabe im Produkt. In diesem Stadium sollten Sie bei der Auswahl eines Systems, einschließlich des Caches, aufpassen. In unserem Fall können wir tatsächlich sagen, dass wir uns zufällig für Hazelcast entschieden haben, aber dann stellte sich heraus, dass wir uns für den richtigen entschieden haben.

Für die Produktion ist es viel wichtiger: Überwachung, Verarbeitungsfehler auf einzelnen Knoten, Datenreplikation, Skalierungskosten. Das heißt, es lohnt sich, auf die Aufgaben zu achten, die sich gerade dann ergeben, wenn das System unterstützt wird - wenn die Last zehnmal höher ist als geplant, wenn wir versehentlich etwas in die falsche Richtung füllen, wenn Sie eine neue Version des Codes einführen, die Daten ersetzen und unbemerkt tun müssen für Kunden.

Für all diese Anforderungen ist Hazelcast definitiv geeignet.

Fortsetzung folgt

Aber Hazelcast ist kein Allheilmittel. 2017 haben wir Hazelcast für den Cache im Admin-Bereich ausgewählt, wobei wir uns einfach auf den guten Eindruck vergangener Erfahrungen verlassen haben. Dies spielte eine Schlüsselrolle in einem sehr bösen Witz, weshalb wir uns in einer schwierigen Situation befanden und 60 Tage lang „heldenhaft“ herauskamen. Aber mehr dazu im nächsten Teil.

In der Zwischenzeit ... Happy New Code!

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