{"id":73949,"date":"2020-03-13T02:42:07","date_gmt":"2020-03-12T23:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1"},"modified":"2020-03-13T02:42:07","modified_gmt":"2020-03-12T23:42:07","slug":"kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","title":{"rendered":"Wie wir bei Sportmaster das Caching-System ausgew\u00e4hlt haben. Teil 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo! Ich bin Alexey Pjankov, ein Entwickler bei Sportmaster. In diesem haben wir erl\u00e4utert, wie wir standardisierte Kundenvirtualmaschinen vorbereiten, und am Beispiel unseres neuen Tarifs Ultralight f\u00fcr 120 Rubel gezeigt, wie wir ein standardm\u00e4\u00dfiges Abbild von Windows Server 2019 Core erstellt haben.<\/a><\/noindex> Bericht habe ich erz\u00e4hlt, wie die Arbeit an der Sportmaster-Website im Jahr 2012 begann, welche Initiativen wir erfolgreich durchsetzen konnten und welche Herausforderungen wir bew\u00e4ltigt haben.<\/p>\n

Heute m\u00f6chte ich meine Gedanken zu einem anderen Thema teilen \u2013 der Auswahl eines Caching-Systems f\u00fcr das Java-Backend im Admin-Bereich der Website. Dieses Thema liegt mir besonders am Herzen \u2013 obwohl die Geschichte nur 2 Monate dauerte, haben wir in diesen 60 Tagen 12-16 Stunden am Tag ohne einen einzigen freien Tag gearbeitet. Ich h\u00e4tte nie gedacht, dass man so viel arbeiten kann.<\/p>\n

Deshalb teile ich den Text in 2 Teile auf, um es nicht zu \u00fcberladen. Im Gegenteil, der erste Teil wird sehr leicht sein \u2013 eine Vorbereitung, eine Einf\u00fchrung und einige \u00dcberlegungen zum Thema Caching. Wenn Sie bereits ein erfahrener Entwickler sind oder mit Caches gearbeitet haben, wird es in diesem Artikel aus technischer Sicht wahrscheinlich nichts Neues geben. F\u00fcr einen Junior k\u00f6nnte jedoch eine kleine \u00dcbersicht hilfreich sein, in welche Richtung man schauen sollte, falls man an einem solchen Scheideweg steht.<\/p>\n

\"Wie<\/a><\/noindex>
\n<\/a><\/noindex>
\nAls die neue Version der Sportmaster-Website in die Produktion ging, war der Datenfluss, um es vorsichtig auszudr\u00fccken, alles andere als ideal. Die Grundlage bildeten Tabellen, die f\u00fcr die vorherige Website-Version (Bitrix) erstellt wurden. Diese mussten in das ETL-System integriert, an das neue Format angepasst und mit verschiedenen zus\u00e4tzlichen Informationen aus einer Handvoll anderer Systeme angereichert werden. Um sicherzustellen, dass ein neues Bild oder eine Produktbeschreibung auf der Website erscheint, musste man bis zum n\u00e4chsten Tag warten \u2014 die Aktualisierungen fanden nur nachts einmal t\u00e4glich statt.<\/p>\n

Anfangs gab es in den ersten Wochen nach dem Produktionsstart so viele Herausforderungen, dass die Unannehmlichkeiten der Content-Manager eher nebens\u00e4chlich waren. Doch sobald sich alles stabilisierte, entwickelte sich das Projekt weiter \u2013 Anfang 2015 begannen wir aktiv an der Administrationsoberfl\u00e4che zu arbeiten. In den Jahren 2015 und 2016 lief alles gut, wir ver\u00f6ffentlichten regelm\u00e4\u00dfig Updates, die Admin-Oberfl\u00e4che umfasste zunehmend mehr Bereiche der Datenaufbereitung, und wir bereiteten uns darauf vor, bald das Wichtigste und Schwierigste zu \u00fcbernehmen \u2013 die Produktlinie (komplette Vorbereitung und Verwaltung der Daten f\u00fcr alle Produkte). Doch im Sommer 2017, kurz vor dem Start der Produktlinie, befand sich das Projekt in einer sehr schwierigen Lage \u2013 gerade wegen Problemen mit dem Caching. \u00dcber diesen Vorfall m\u00f6chte ich im zweiten Teil dieser zweiteiligen Ver\u00f6ffentlichung berichten.<\/p>\n

In diesem Beitrag m\u00f6chte ich jedoch von ganz hinten anfangen und einige Gedanken zur Vorstellung vom Caching zusammenfassen, die vor einem gro\u00dfen Projekt im Voraus hilfreich gewesen w\u00e4ren.<\/p>\n

Wenn die Aufgabe des Cachings entsteht<\/h2>\n

\nCaching-Probleme tauchen nicht einfach so auf. Wir sind Entwickler, die Softwareprodukte erstellen, und wir m\u00f6chten, dass diese gefragt sind. Wenn das Produkt gefragt und erfolgreich ist, kommen die Nutzer. Immer mehr Nutzer. Und wenn die Nutzerzahl stark ansteigt, wird das Produkt hochbelastet.<\/p>\n

In den fr\u00fchen Phasen denken wir nicht \u00fcber Code-Optimierung und Leistung nach. Das Wichtigste ist die Funktionalit\u00e4t, das schnelle Bereitstellen eines Prototyps und die \u00dcberpr\u00fcfung von Hypothesen. Wenn die Last steigt, verbessern wir die Hardware. Wir verdoppeln, verdreifachen, verzehnfachen die Ressourcen. Irgendwo hier wird das Budget nicht mehr mitspielen. Und um wie viel wird die Anzahl der Nutzer steigen? Es wird nicht nur 2-5-10 sein, sondern im Erfolgsfall von 100 bis 1000 und bis zu 100.000. Das hei\u00dft, irgendwann wird es unumg\u00e4nglich sein, sich intensiv mit der Optimierung zu befassen.<\/p>\n

Nehmen wir an, ein bestimmter Teil des Codes (wir nennen ihn Funktion) ben\u00f6tigt unverh\u00e4ltnism\u00e4\u00dfig lange, und wir m\u00f6chten die Ausf\u00fchrungszeit verk\u00fcrzen. Eine Funktion kann der Datenbankzugriff sein oder die Ausf\u00fchrung komplexer Logik \u2013 entscheidend ist, dass die Ausf\u00fchrung lange dauert. Wie viel kann die Ausf\u00fchrungszeit verk\u00fcrzt werden? Im besten Fall \u2013 sie kann bis auf null reduziert werden, nicht weiter. Und wie kann man die Ausf\u00fchrungszeit auf null reduzieren? Antwort: Indem man die Ausf\u00fchrung vollst\u00e4ndig ausschlie\u00dft. Stattdessen \u2013 geben Sie sofort das Ergebnis zur\u00fcck. Aber wie bekommt man das Ergebnis? Antwort: Entweder berechnen oder irgendwo nachsehen. Berechnen ist zeitaufw\u00e4ndig. Nachsehen hingegen bedeutet zum Beispiel, das Ergebnis zu speichern, das die Funktion beim letzten Aufruf mit denselben Parametern geliefert hat.<\/p>\n

Das bedeutet, dass die Implementierung der Funktion f\u00fcr uns nicht entscheidend ist. Es reicht aus, die Parameter zu kennen, von denen das Ergebnis abh\u00e4ngt. Wenn wir dann die Werte der Parameter in einem Objekt darstellen, das als Schl\u00fcssel in einem Speicher verwendet werden kann, k\u00f6nnen wir das Berechnungsergebnis speichern und bei der n\u00e4chsten Abfrage abrufen. Wenn diese Speicherung und Abfrage schneller erfolgt als die Ausf\u00fchrung der Funktion, erzielen wir einen Geschwindigkeitsvorteil. Der Vorteil kann bis zu 100, 1000 oder sogar 100.000-fach (10^5 \u2013 dies ist eher die Ausnahme, aber im Fall einer stark verz\u00f6gerten Datenbank durchaus m\u00f6glich) betragen.<\/p>\n

Die grundlegenden Anforderungen an ein Caching-System<\/h2>\n

\nDie erste Anforderung an ein Caching-System ist die schnelle Lesegeschwindigkeit, und in etwas geringerem Ma\u00dfe die Schreibgeschwindigkeit. Das ist so, aber nur bis wir das System in die Produktion bringen.<\/p>\n

Lassen Sie uns einen solchen Fall durchspielen.<\/p>\n

Angenommen, wir haben die aktuelle Belastung mit entsprechender Hardware gedeckt und f\u00fchren nun schrittweise Caching ein. Die Nutzerzahl steigt allm\u00e4hlich, die Last w\u00e4chst \u2013 wir f\u00fcgen einige Caches hinzu und integrieren sie hier und da. So verl\u00e4uft es eine Zeit lang, und schon werden die ressourcenintensiven Funktionen kaum noch aufgerufen \u2013 die gesamte Hauptlast liegt auf dem Cache. In dieser Zeit ist die Nutzeranzahl um das N-Fache gestiegen.<\/p>\n

Und wenn das anf\u00e4ngliche Hardware-Setup vielleicht das 2- bis 5-Fache ausmachen konnte, so konnten wir mit Hilfe des Caching die Leistung um das 10-Fache steigern oder im besten Fall sogar um das 100-Fache, in einigen F\u00e4llen m\u00f6glicherweise sogar um das 1000-Fache. Das hei\u00dft, mit derselben Hardware verarbeiten wir 100-mal mehr Anfragen. Gro\u00dfartig, das haben wir verdient!<\/p>\n

Doch nun, eines sch\u00f6nen Tages, gab das System zuf\u00e4llig den Geist auf und der Cache fiel aus. Nichts Au\u00dfergew\u00f6hnliches \u2013 schlie\u00dflich hatten wir den Cache mit dem Kriterium \u201ehohe Lese- und Schreibgeschwindigkeit, alles andere ist unwichtig\u201c ausgew\u00e4hlt.<\/p>\n

Im Hinblick auf die anf\u00e4ngliche Last verf\u00fcgten wir \u00fcber eine Hardwarereserve von 2-5 Mal, w\u00e4hrend die Last in der Zwischenzeit auf das 10- bis 100-Fache gestiegen ist. Mithilfe des Caches konnten wir die Aufrufe f\u00fcr rechenintensive Funktionen vermeiden, sodass alles reibungslos lief. Aber jetzt, ohne Cache \u2013 um wie viel wird unser System einbrechen? Was wird mit uns geschehen? Das System wird ausfallen.<\/p>\n

Selbst wenn unser Cache nicht abgest\u00fcrzt ist, sondern nur vor\u00fcbergehend geleert wurde, muss er wieder aufgeheizt werden, und das wird einige Zeit in Anspruch nehmen. W\u00e4hrend dieser Zeit wird die Hauptlast auf die Funktionalit\u00e4t fallen.<\/p>\n

Fazit: Hochbelastete Projekte in der Produktion erfordern von einem Systemspeicher nicht nur hohe Lese- und Schreibgeschwindigkeiten, sondern auch Datensicherung und Ausfallsicherheit.<\/p>\n

Die Qual der Wahl<\/h2>\n

\nIm Projekt mit dem Admin-Bereich stellte sich die Auswahl so dar: Zuerst setzten wir Hazelcast ein, da wir bereits durch die Erfahrungen mit der Hauptseite mit diesem Produkt vertraut waren. Doch diese Wahl stellte sich als nicht g\u00fcnstig heraus \u2013 unter unserem Lastprofil arbeitet Hazelcast nicht nur langsam, sondern schrecklich langsam. Zu diesem Zeitpunkt hatten wir bereits einen Termin f\u00fcr den Produktionsstart festgelegt.<\/p>\n

Spoiler: Ich werde im zweiten Teil erz\u00e4hlen, wie es zu den Umst\u00e4nden kam, dass wir so eine Pleite erlebt haben und uns in eine schwierige und angespannte Situation gebracht haben \u2013 und wie wir da herausgekommen sind. Aber jetzt kann ich nur sagen, dass es ein gro\u00dfer Stress war, und \u201adenken \u2013 geht irgendwie nicht, wir sch\u00fctteln die Flasche\u2018. \u201aWir sch\u00fctteln die Flasche\u2018 ist auch ein Spoiler, dazu sp\u00e4ter mehr.<\/p>\n

Was wir gemacht haben:<\/p>\n

    \n
  1. Wir erstellen eine Liste aller Systeme, die Google und StackOverflow vorschlagen. Etwas mehr als 30.<\/li>\n
  2. Wir schreiben Tests mit der f\u00fcr die Produktion typischen Last. Daf\u00fcr haben wir Daten erfasst, die im Produktionsumfeld durch das System laufen \u2013 eine Art Sniffer f\u00fcr Daten, die nicht im Netzwerk, sondern innerhalb des Systems sind. In die Tests haben wir genau diese Daten eingesetzt.<\/li>\n
  3. Das gesamte Team w\u00e4hlt nacheinander das n\u00e4chste System aus der Liste aus, konfiguriert es und f\u00fchrt die Tests durch. Wenn der Test nicht besteht und die Last nicht tr\u00e4gt \u2013 werfen wir es weg und gehen zum n\u00e4chsten in der Reihe.<\/li>\n
  4. Beim 17. System wurde klar, dass alles hoffnungslos war. Genug mit dem \u201aFlasche sch\u00fctteln\u2018, es ist Zeit, ernsthaft nachzudenken.<\/li>\n<\/ol>\n

    \nAber das ist eine Option, wenn man ein System ausw\u00e4hlen muss, das in bereits durchgef\u00fchrten Tests hinsichtlich Geschwindigkeit \"besteht\". Und wenn es noch keine solchen Tests gibt und man m\u00f6chte etwas Schnelleres w\u00e4hlen?<\/p>\n

    Lass uns dieses Szenario durchspielen (es ist schwer vorstellbar, dass ein mittelm\u00e4\u00dfiger Entwickler in einem Vakuum lebt und zu dem Zeitpunkt der Auswahl noch keine Pr\u00e4ferenz ge\u00e4u\u00dfert hat, welches Produkt er als erstes ausprobieren m\u00f6chte \u2013 daher handelt es sich bei den weiteren \u00dcberlegungen eher um theoretische \u00dcberlegungen\/philosophische Betrachtungen \u00fcber Junioren).<\/p>\n

    Sobald wir uns \u00fcber die Anforderungen einig sind, beginnen wir mit der Auswahl einer fertigen L\u00f6sung. Warum das Rad neu erfinden: wir greifen auf ein bestehendes Caching-System zur\u00fcck.<\/p>\n

    Wenn Sie gerade erst anfangen und googeln, wird es mehr oder weniger in dieser Reihenfolge sein, aber insgesamt werden die Anhaltspunkte wie folgt aussehen. Zun\u00e4chst werden Sie auf Redis sto\u00dfen, das ist in aller Munde. Dann erfahren Sie, dass es EhCache gibt, das als eines der \u00e4ltesten und bew\u00e4hrtesten Systeme gilt. Danach wird \u00fcber Tarantool geschrieben \u2013 eine heimische Entwicklung, die einen einzigartigen Aspekt der L\u00f6sung bietet. Und auch Ignite, da es derzeit an Popularit\u00e4t gewinnt und von SberTech unterst\u00fctzt wird. Am Ende kommt noch Hazelcast, da es in der Enterprise-Welt h\u00e4ufig in gro\u00dfen Unternehmen auftaucht.<\/p>\n

    Diese Liste ist nicht abschlie\u00dfend; es gibt Dutzende von Systemen. Wir betrachten lediglich eines davon. Nehmen wir die f\u00fcnf ausgew\u00e4hlten Systeme zum \u201eSch\u00f6nheitswettbewerb\u201c und f\u00fchren eine Auswahl durch. Wer wird der Gewinner sein?<\/p>\n

    Redis<\/h3>\n

    \nLassen Sie uns lesen, was auf der offiziellen Website steht.
    \n    Redis<\/a><\/noindex> \u2014 ein Open-Source-Projekt. Es bietet ein In-Memory-Datenbankspeicher, die M\u00f6glichkeit zum Speichern auf Festplatte, automatische Partitionierung, hohe Verf\u00fcgbarkeit und Wiederherstellung nach Netzwerkunterbrechungen.<\/p>\n

    Scheint alles gro\u00dfartig zu sein, man k\u00f6nnte es einfach verwenden \u2013 es erf\u00fcllt alle Anforderungen. Aber lassen Sie uns der Vollst\u00e4ndigkeit halber auch die anderen Kandidaten betrachten.<\/p>\n

    EhCache<\/h3>\n

    \nEhCache<\/a><\/noindex> \u2014 \"der am h\u00e4ufigsten verwendete Cache f\u00fcr Java\" (\u00dcbersetzung des Slogans von der offiziellen Website). Auch Open-Source. Hier erkennen wir, dass Redis nicht f\u00fcr Java gedacht ist, sondern allgemein, und zur Interaktion ein Wrapper erforderlich ist. EhCache ist dabei handlicher. Was verspricht dieses System noch? Zuverl\u00e4ssigkeit, Erprobtheit, volle Funktionalit\u00e4t. Und es ist das am weitesten verbreitete System. Es cached Terabytes an Daten.<\/p>\n

    Redis ist vergessen, ich bin bereit, EhCache zu w\u00e4hlen.<\/p>\n

    Aber mein Patriotismus dr\u00e4ngt mich, zu schauen, was Tarantool zu bieten hat.<\/p>\n

    Tarantool<\/h3>\n

    \nTarantool<\/a><\/noindex> \u2014 wird mit dem Begriff \u201eEchtzeit-Datenintegrationsplattform\u201c bezeichnet. Klingt komplex, also lesen wir die Seite gr\u00fcndlich und sto\u00dfen auf die k\u00fchne Behauptung: \u201eCaching von 100 % der Daten im Arbeitsspeicher\u201c. Das sollte Fragen aufwerfen \u2014 denn es k\u00f6nnte deutlich mehr Daten geben als Speicher. Die Interpretation hier ist, dass Tarantool beim Schreiben von Daten auf die Festplatte aus dem Speicher keine Serialisierung durchf\u00fchrt. Stattdessen nutzt es die niedrigstufigen Eigenschaften des Systems, bei denen der Speicher einfach auf das Dateisystem abgebildet wird, was hervorragende I\/O-Leistungen bietet. Insgesamt haben sie das bemerkenswert und gro\u00dfartig gemacht.<\/p>\n

    Schauen wir uns die Implementierungen an: Mail.ru Unternehmensnetzwerk, Avito, Beeline, Megafon, Alfa-Bank, Gazprom\u2026<\/p>\n

    Wenn ich noch irgendwelche Zweifel an Tarantool hatte, zerstreitet der Implementierungsfall bei Mastercard meine letzten Bedenken. Ich w\u00e4hle Tarantool.<\/p>\n

    Aber letztendlich\u2026<\/p>\n

    Ignite<\/h3>\n

    \n\u2026 gibt es noch weitere Ignite<\/a><\/noindex>, angegeben als \u201ein-memory Rechenplattform\u2026 in-memory Geschwindigkeiten bei Petabytes von Daten\u201c. Hier gibt es viele Vorteile: verteilte in-memory Caches, das schnellste Key-Value-Speichersystem und Cache, horizontale Skalierung, hohe Verf\u00fcgbarkeit, strenge Konsistenz. Insgesamt ist Ignite also das schnellste.<\/p>\n

    Implementierungen: Sberbank, American Airlines, Yahoo! Japan. Und dann erfahre ich, dass Ignite nicht nur bei Sberbank implementiert ist, sondern dass das SberTech-Team eigene Leute in das Ignite-Team entsendet, um das Produkt weiterzuentwickeln. Das \u00fcberzeugt mich vollkommen und ich bin bereit, Ignite zu w\u00e4hlen.<\/p>\n

    Ganz unklar, warum, schaue ich mir den f\u00fcnften Punkt an.<\/p>\n

    Hazelcast<\/h3>\n

    \nIch besuche die Website Hazelcast<\/a><\/noindex>, lese. Und es stellt sich heraus, dass die schnellste L\u00f6sung f\u00fcr verteiltes Caching \u2013 das ist Hazelcast. Es ist um ein Vielfaches schneller als alle anderen L\u00f6sungen und generell ist es der Marktf\u00fchrer im Bereich in-memory Data Grid. Vor diesem Hintergrund etwas anderes zu w\u00e4hlen \u2013 w\u00e4re sich nicht wertzusch\u00e4tzen. Au\u00dferdem nutzt es redundante Datenspeicherung, um den Cluster kontinuierlich ohne Datenverluste zu betreiben.<\/p>\n

    Das war's, ich bin bereit, Hazelcast zu w\u00e4hlen.<\/p>\n

    Der Vergleich<\/h2>\n

    \nDoch wenn man genau hinsieht, dann sind alle f\u00fcnf Kandidaten so dargestellt, dass jeder von ihnen der Beste ist. Wie w\u00e4hlt man aus? Wir k\u00f6nnen schauen, welcher am beliebtesten ist, Vergleiche suchen, und der Kopfweh wird verschwinden.<\/p>\n

    Wir finden einen solchen Testbericht<\/a><\/noindex>, w\u00e4hlen unsere 5 Systeme aus.<\/p>\n

    \"Wie
    \n
    \nHier sind sie sortiert: an erster Stelle Redis, an zweiter Stelle \u2014 Hazelcast, w\u00e4hrend Tarantool und Ignite an Popularit\u00e4t gewinnen, bleibt EhCache wie es war. <\/p>\n

    Aber schauen wir uns die Berechnungsmethode<\/a><\/noindex>: Links zu Websites, allgemeines Interesse an dem System, Stellenangebote \u2014 gro\u00dfartig! Das hei\u00dft, wenn mein System ausf\u00e4llt, sage ich: \u201eNein, es ist doch zuverl\u00e4ssig! Da gibt es viele Stellenangebote...\u201c. Ein so einfacher Vergleich eignet sich nicht.<\/p>\n

    All diese Systeme sind nicht nur Caching-Systeme. Sie haben auch viel mehr Funktionalit\u00e4t, einschlie\u00dflich der Tatsache, dass nicht die Daten an den Kunden zur Verarbeitung \u00fcbertragen werden, sondern umgekehrt: der Code, der auf den Daten ausgef\u00fchrt werden muss, wird auf den Server \u00fcbertragen, dort ausgef\u00fchrt und das Ergebnis zur\u00fcckgegeben. Und als separates Caching-System werden sie nicht allzu oft betrachtet.<\/p>\n

    Gut, wir geben nicht auf und suchen nach einem direkten Vergleich der Systeme. Wir nehmen die zwei besten Optionen \u2014 Redis und Hazelcast. Uns interessiert die Geschwindigkeit, nach diesem Kriterium vergleichen wir sie.<\/p>\n

    Hz vs Redis<\/h3>\n

    \nWir finden das Folgende heraus. Vergleich<\/a><\/noindex>:
    \n\"Wie
    \n
    \nBlau steht f\u00fcr Redis, Rot f\u00fcr Hazelcast. Hazelcast hat in allen Aspekten die Nase vorn und hier gibt es einen guten Grund: Es ist Multithreading-f\u00e4hig und hochoptimiert, wobei jeder Thread mit seiner eigenen Partition arbeitet, was zu keiner Blockierung f\u00fchrt. Redis hingegen ist ein Single-Thread-System und kann von modernen Mehrkern-CPUs nicht profitieren. Hazelcast nutzt asynchrones I\/O, w\u00e4hrend Redis-Jedis blockierende Sockets verwendet. Au\u00dferdem verwendet Hazelcast ein bin\u00e4res Protokoll, w\u00e4hrend Redis textbasiert ist, was es ineffizient macht.<\/p>\n

    Zur Sicherheit schauen wir uns eine weitere Vergleichsquelle an. Was wird uns das zeigen?<\/p>\n

    Redis vs Hz<\/h3>\n

    \nNoch ein weiterer Vergleich. Vergleich<\/a><\/noindex>:
    \n\"Wie
    \n
    \nHier ist es umgekehrt, Rot steht f\u00fcr Redis. Das bedeutet, dass Redis in Bezug auf die Leistung Hazelcast \u00fcbertrifft. Im ersten Vergleich war Hazelcast \u00fcberlegen, im zweiten hingegen Redis.     Hier wird klar erkl\u00e4rt, warum Hazelcast im vorherigen Vergleich gewonnen hat.<\/a><\/noindex> Es stellt sich heraus, dass das Ergebnis des ersten Vergleichs praktisch manipuliert wurde: Redis wurde in der Basisversion getestet, w\u00e4hrend Hazelcast auf den Testfall optimiert wurde. Das f\u00fchrt uns zu der Erkenntnis: Erstens, niemandem kann man trauen, und zweitens, wenn wir uns schlie\u00dflich f\u00fcr ein System entscheiden, m\u00fcssen wir es richtig konfigurieren. Diese Einstellungen bestehen aus Dutzenden, fast Hunderten von Parametern.<\/p>\n

    Sch\u00fctteln wir die Flasche.<\/p>\n

    Wir sch\u00fctteln die Flasche<\/h2>\n

    \nUnd den gesamten Prozess, den wir gerade durchlaufen haben, kann ich mit der Metapher \"Die Flasche sch\u00fctteln\" erkl\u00e4ren. Das bedeutet, dass man jetzt nicht unbedingt programmieren muss; das Wichtigste ist, Stack Overflow lesen zu k\u00f6nnen. In meinem Team gibt es einen Profi, der genau so in kritischen Momenten arbeitet.<\/p>\n

    Was macht er? Er sieht ein defektes Ger\u00e4t, erkennt den Stacktrace, nimmt einige W\u00f6rter daraus (welche genau \u2013 das ist seine Expertise in der Software), sucht bei Google und findet unter den Antworten Stack Overflow. Ohne zu lesen oder dar\u00fcber nachzudenken, w\u00e4hlt er etwas, das dem Satz \u201eDas und das tun\u201c am \u00e4hnlichsten ist (diese Auswahl ist sein Talent, denn es ist nicht immer die Antwort mit den meisten Likes), wendet es an und sieht: Wenn sich etwas ge\u00e4ndert hat, ist das gro\u00dfartig. Wenn sich nichts ge\u00e4ndert hat \u2013 zur\u00fccksetzen. Und wir wiederholen Start-Test-Suche. Auf diese intuitive Weise schafft er es, dass der Code nach einer Weile funktioniert. Er wei\u00df nicht warum, er wei\u00df nicht, was er gemacht hat, kann es nicht erkl\u00e4ren. Aber! Das Ding funktioniert. Und \u201edas Feuer ist gel\u00f6scht\u201c. Jetzt kl\u00e4ren wir, was wir gemacht haben. Wenn das Programm l\u00e4uft, ist es um ein Vielfaches einfacher. Und es spart erheblich Zeit.<\/p>\n

    Diese Methode l\u00e4sst sich sehr gut durch folgendes Beispiel erkl\u00e4ren.<\/p>\n

    Es war einmal sehr popul\u00e4r, ein Segelschiff in einer Flasche zu bauen. Dabei ist das Segelschiff gro\u00df und zerbrechlich, w\u00e4hrend der Flaschenhals sehr schmal ist, man kann es nicht einfach reinstecken. Wie baut man es also zusammen?<\/p>\n

    \"Wie
    \n
    \nEs gibt eine Methode, die sehr schnell und \u00e4u\u00dferst effektiv ist.<\/p>\n

    Ein Schiff besteht aus vielen kleinen Teilen: Sticks, Schn\u00fcren, Segeln und Kleber. All dies legen wir in eine Flasche.
    \nWir nehmen die Flasche mit beiden H\u00e4nden und beginnen zu sch\u00fctteln. Wir sch\u00fctteln sie und sch\u00fctteln sie. Und normalerweise \u2013 es wird nat\u00fcrlich nichts Gescheites dabei herauskommen. Aber manchmal. Manchmal wird es ein Schiff! Genauer gesagt, etwas, das wie ein Schiff aussieht.<\/p>\n

    Wir zeigen dieses Etwas jemandem: \u201eSiehst du, Serjoga!?\u201c. Und wirklich, aus der Ferne sieht es fast wie ein Schiff aus. Aber weiter darf man es nicht lassen.<\/p>\n

    Es gibt auch eine andere M\u00f6glichkeit. Es verwenden Leute, die fortgeschrittener sind, so genannte Hacker.<\/p>\n

    Habe einem Typen eine Aufgabe gegeben, er hat alles erledigt und ist gegangen. Und man sieht \u2013 es scheint erledigt zu sein. Aber nach einer Weile, wenn man den Code nachbessern muss \u2013 da f\u00e4ngt das Durcheinander wegen ihm an... Gut, dass er sich schon weit genug entfernt hat. Das sind solche Typen, die an einem Beispiel mit der Flasche Folgendes machen: Seht ihr, wo der Boden ist \u2013 das Glas biegt sich. Und es ist nicht ganz klar, ob es durchsichtig ist oder nicht. Dann schneiden die \u201eHacker\u201c diesen Boden ab, stecken das Schiff hinein, kleben den Boden wieder fest, und es sieht so aus, als w\u00e4re es so gedacht.<\/p>\n

    Aus der Sicht der Aufgabenstellung scheint alles korrekt zu sein. Doch nehmen wir als Beispiel Schiffe: Warum sollte man \u00fcberhaupt dieses Schiff bauen, wer braucht es wirklich? Es hat keine Funktionalit\u00e4t. Solche Schiffe sind normalerweise Geschenke an hochrangige Pers\u00f6nlichkeiten, die es als ein Symbol, eine Art Zeichen, auf einem Regal ausstellen. Und wenn ein solcher Mensch, der Chef eines gro\u00dfen Unternehmens oder ein hochrangiger Beamter, ein solches Werk als Flaggschiff hat, bei dem der Hals abgeschnitten ist? Es w\u00e4re besser, wenn er niemals davon erf\u00e4hrt. Aber wie werden schlie\u00dflich diese Schiffe hergestellt, die man einer wichtigen Person schenken kann?<\/p>\n

    Der einzige Punkt, mit dem man wirklich nichts anfangen kann, ist der Rumpf. Und der Rumpf des Schiffes passt genau durch den Flaschenhals. W\u00e4hrend das Schiff au\u00dferhalb der Flasche zusammengebaut wird. Aber es ist nicht nur eine Frage des Zusammenbaus; es ist ein echtes Kunsthandwerk. In die einzelnen Teile werden spezielle Hebel integriert, die es erm\u00f6glichen, sie sp\u00e4ter anzuheben. Zum Beispiel werden die Segel zusammengelegt, sorgf\u00e4ltig hineingeschoben, und dann werden sie mit einer Pinzette \u00e4u\u00dferst pr\u00e4zise angehoben und positioniert. Am Ende entsteht ein Kunstwerk, das man mit reinem Gewissen und Stolz verschenken kann.<\/p>\n

    Und wenn wir wollen, dass das Projekt erfolgreich ist, sollte im Team mindestens eine Person wie ein Juwelier sein. Jemand, der sich um die Qualit\u00e4t des Produkts k\u00fcmmert und alle Aspekte ber\u00fccksichtigt, ohne in stressigen Momenten, in denen die Umst\u00e4nde dringendes Handeln erfordern, auf wichtige Dinge zu verzichten. Alle erfolgreichen Projekte, die Bestand haben und die Zeit \u00fcberstehen, basieren auf diesem Prinzip. In ihnen gibt es etwas sehr Pr\u00e4zises und Einzigartiges, etwas, das alle verf\u00fcgbaren M\u00f6glichkeiten nutzt. Im Beispiel des Schiffs in der Flasche wird illustriert, wie der Rumpf des Schiffs durch den Hals passt.<\/p>\n

    Zur\u00fcck zu der Aufgabe, unseren Caching-Server auszuw\u00e4hlen: Wie k\u00f6nnte man diese Methode anwenden? Ich schlage vor, die Systeme, die es gibt, so auszuw\u00e4hlen, dass wir die Flasche nicht sch\u00fctteln, sondern darauf achten, was prinzipiell darin vorhanden ist, worauf wir bei der Auswahl des Systems achten sollten.<\/p>\n

    Wo nach Engp\u00e4ssen suchen?<\/h2>\n

    \nWir versuchen, die Flasche nicht zu sch\u00fctteln und alles der Reihe nach zu durchzugehen. Stattdessen schauen wir, welche Aufgaben sich ergeben, wenn wir eigenst\u00e4ndig solch ein System entwerfen. Wir werden nat\u00fcrlich kein Fahrrad neu erfinden, sondern nutzen dieses Schema, um uns zu orientieren, auf welche Aspekte wir in den Produktbeschreibungen achten sollten. Lassen Sie uns so ein Schema entwerfen.<\/p>\n

    \"Wie
    \n
    \nWenn das System verteilt ist, bedeutet das, dass wir mehrere Server haben werden (6). Angenommen, wir haben vier (das l\u00e4sst sich bequem auf dem Bild darstellen, aber es k\u00f6nnen nat\u00fcrlich beliebig viele sein). Wenn die Server auf verschiedenen Knoten sind, l\u00e4uft auf ihnen allen ein gewisser Code, der sicherstellt, dass diese Knoten ein Cluster bilden und sich im Falle einer Unterbrechung wieder verbinden und einander erkennen.<\/p>\n

    Zus\u00e4tzlich ben\u00f6tigen wir die Logik (2), die sich mit dem Caching befasst. Dieser Code interagiert \u00fcber eine bestimmte API mit den Clients. Der Client-Code (1) kann sowohl innerhalb derselben JVM als auch \u00fcber das Netzwerk darauf zugreifen. Die interne Logik besteht darin, zu entscheiden, welche Objekte im Cache bleiben und welche entfernt werden. Wir verwenden den Speicher (3) zur Speicherung des Caches, aber je nach Bedarf k\u00f6nnen wir auch einen Teil der Daten auf der Festplatte speichern (4).<\/p>\n

    Lassen Sie uns untersuchen, in welchen Bereichen die Last entstehen wird. Im Grunde genommen werden jede Verbindung und jeder Knoten belastet. Erstens kann es, wenn die Kommunikation zwischen dem Client-Code und der API erfolgt und wenn diese Netzwerkinteraktionen beinhaltet, zu merklichen Verz\u00f6gerungen kommen. Zweitens, innerhalb der API selbst \u2013 wenn wir zu komplexe Logik implementieren, k\u00f6nnten wir an die CPU-Grenzen sto\u00dfen. Es w\u00e4re gut, wenn die Logik nicht unn\u00f6tig auf den Arbeitsspeicher zugreift. Und schlie\u00dflich bleibt die Interaktion mit dem Dateisystem \u2013 normalerweise bedeutet dies, dass wir Daten serialisieren\/wiederherstellen und schreiben\/lesen m\u00fcssen.<\/p>\n

    Als N\u00e4chstes betrachten wir die Interaktion mit dem Cluster. H\u00f6chstwahrscheinlich wird er im selben System sein, es k\u00f6nnte aber auch separat sein. Auch hier muss die Daten\u00fcbertragung zu ihm, die Geschwindigkeit der Datenserialisierung und die Interaktion zwischen dem Cluster ber\u00fccksichtigt werden.<\/p>\n

    Jetzt k\u00f6nnen wir einerseits visualisieren, \u201ewelche Zahnr\u00e4der sich im Cache-System drehen\u201c w\u00e4hrend die Anfragen von unserem Code verarbeitet werden, und andererseits k\u00f6nnen wir absch\u00e4tzen, welche und wie viele Anfragen unser Code an dieses System generieren wird. Das ist ausreichend, um eine mehr oder weniger fundierte Entscheidung zu treffen \u2013 um ein System entsprechend unserem Anwendungsfall auszuw\u00e4hlen.<\/p>\n

    Hazelcast<\/b><\/p>\n

    Schauen wir uns an, wie diese Struktur auf unsere Liste angewendet werden kann. Zum Beispiel Hazelcast.<\/p>\n

    Um Daten in Hazelcast zu speichern oder abzurufen, greift der Client-Code (1) auf die API zu. Hz erm\u00f6glicht es, den Server als Embedded zu starten, und in diesem Fall ist der Zugriff auf die API ein Methodenausruf innerhalb der JVM, was als kostenlos betrachtet werden kann.<\/p>\n

    Damit die Logik in (2) funktioniert, st\u00fctzt sich Hz auf den Hash des byte-Arrays des serialisierten Schl\u00fcssels \u2013 das hei\u00dft, die Serialisierung des Schl\u00fcssels findet in jedem Fall statt. Dies ist ein unvermeidlicher Overhead f\u00fcr Hz.
    \nDie Eviction-Strategien sind gut implementiert, aber f\u00fcr spezielle F\u00e4lle k\u00f6nnen eigene Strategien hinzugef\u00fcgt werden. Um diesen Teil muss man sich keine Sorgen machen.<\/p>\n

    Der Speicher (4) kann angeschlossen werden. Hervorragend. Die Interaktion (5) f\u00fcr Embedded kann als sofort betrachtet werden. Der Datenaustausch zwischen den Knoten im Cluster (6) \u2013 ja, der findet statt. Dies tr\u00e4gt zur Redundanz bei, jedoch auf Kosten der Geschwindigkeit. Die Hz-Funktion Near-cache erm\u00f6glicht es, dass Daten, die von anderen Knoten im Cluster erhalten werden, zwischengespeichert werden.<\/p>\n

    Was kann in solchen Situationen zur Geschwindigkeitssteigerung getan werden?<\/p>\n

    Um die Serialisierung des Schl\u00fcssels in (2) zu vermeiden, k\u00f6nnte man \u00fcber Hazelcast einen weiteren Cache f\u00fcr die hei\u00dfesten Daten anbringen. Bei Sportmaster haben wir daf\u00fcr Caffeine ausgew\u00e4hlt.<\/p>\n

    F\u00fcr die Anpassung auf Ebene (6) werden in Hz zwei Speichertypen angeboten: IMap und ReplicatedMap.
    \n\"Wie
    \n
    \nEs ist erw\u00e4hnenswert, wie Hazelcast in den Technologie-Stack von Sportmaster integriert wurde.<\/p>\n

    Im Jahr 2012, als wir an dem ersten Prototyp der zuk\u00fcnftigen Website arbeiteten, war Hazelcast der erste Link, den die Suchmaschine anzeigte. Der Kontakt entstand 'auf Anhieb' \u2013 wir waren begeistert, dass es nur zwei Stunden dauerte, bis wir Hz ins System integriert hatten \u2013 es funktionierte. Und es funktionierte gut. Bis zum Ende des Tages schrieben wir einige Tests und waren zufrieden. Und dieser Schwung reichte aus, um die Herausforderungen zu meistern, die Hz im Laufe der Zeit brachte. Jetzt gibt es f\u00fcr das Sportmaster-Team keinen Grund, auf Hazelcast zu verzichten.<\/p>\n

    Aber Argumente wie 'der erste Link in der Suchmaschine' und 'schnell HelloWorld erstellt' sind nat\u00fcrlich Ausnahmen und besondere Umst\u00e4nde, die die Auswahl beeinflussten. Die wirklichen Pr\u00fcfungen f\u00fcr das gew\u00e4hlte System beginnen mit der Markteinf\u00fchrung, und genau auf diese Phase sollte man achten, wenn man ein System, einschlie\u00dflich Caches, w\u00e4hlt. In unserem Fall kann man sagen, dass wir Hazelcast zuf\u00e4llig ausgew\u00e4hlt haben, sich aber sp\u00e4ter herausstellte, dass die Wahl die richtige war.<\/p>\n

    F\u00fcr Produktionsumgebungen sind folgende Punkte viel wichtiger: Monitoring, Fehlerbehandlung an einzelnen Knoten, Datenreplikation und Skalierungskosten. Es gilt, auf die Herausforderungen zu achten, die speziell bei der Systemwartung auftreten \u2013 wenn die Last um ein Vielfaches die geplante Belastung \u00fcbersteigt, wenn versehentlich falsche Daten hochgeladen werden und wenn es notwendig ist, eine neue Version des Codes auszurollen, Daten zu ersetzen und dies unbemerkt f\u00fcr die Kunden zu erledigen.<\/p>\n

    F\u00fcr all diese Anforderungen ist Hazelcast zweifellos geeignet.<\/p>\n

    Fortsetzung folgt<\/h2>\n

    \nAber Hazelcast ist keine Universall\u00f6sung. Im Jahr 2017 w\u00e4hlten wir Hazelcast f\u00fcr den Cache im Admin-Bereich, einfach basierend auf unseren positiven Erfahrungen aus der Vergangenheit. Dies war entscheidend f\u00fcr einen sehr b\u00f6sartigen Scherz, der uns in eine schwierige Lage brachte, aus der wir uns \u201eheldenhaft\u201c in 60 Tagen herausarbeiteten. Doch mehr dazu im n\u00e4chsten Teil.<\/p>\n

    Und bis dahin\u2026 Happy New Code!
    \n
    Quelle:     habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440. \u0412 \u044d\u0442\u043e\u043c \u043f\u043e\u0441\u0442\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0430\u0441\u044c \u0440\u0430\u0431\u043e\u0442\u0430 \u043d\u0430\u0434 \u0441\u0430\u0439\u0442\u043e\u043c \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440 \u0432 2012 \u0433\u043e\u0434\u0443, \u043a\u0430\u043a\u0438\u0435 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u0438\u0432\u044b \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u00ab\u043f\u0440\u043e\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u00bb \u0438 \u043d\u0430\u043e\u0431\u043e\u0440\u043e\u0442, \u043a\u0430\u043a\u0438\u0435 \u0433\u0440\u0430\u0431\u043b\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0445\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u043c\u044b\u0441\u043b\u044f\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043b\u0435\u0434\u0443\u044e\u0442 \u0437\u0430 \u0434\u0440\u0443\u0433\u0438\u043c \u0441\u044e\u0436\u0435\u0442\u043e\u043c \u2013 \u0432\u044b\u0431\u043e\u0440 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0434\u043b\u044f java-\u0431\u044d\u043a\u0435\u043d\u0434\u0430 \u0432 \u0430\u0434\u043c\u0438\u043d\u043a\u0435 \u0441\u0430\u0439\u0442\u0430. \u042d\u0442\u043e\u0442 \u0441\u044e\u0436\u0435\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":73950,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-73949","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Wie wir bei Sportmaster das Caching-System ausw\u00e4hlten. Teil 1 | ProHoster","description":"Hallo! Ich bin Alexey Pyankov, ein Entwickler bei Sportmaster. In diesem Beitrag erfahre ich, wie die Arbeit an der Website Sportmaster im Jahr 2012 begann, welche Initiativen wir erfolgreich \"vorangetrieben\" haben und welche Stolpersteine uns begegnet sind. Heute m\u00f6chte ich Gedanken teilen, die sich auf ein anderes Thema beziehen \u2013 die Auswahl eines Caching-Systems f\u00fcr das Java-Backend im Admin-Bereich der Website. Dieses Thema","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u0432 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440\u0435 \u0432\u044b\u0431\u0438\u0440\u0430\u043b\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440. \u0412 \u044d\u0442\u043e\u043c \u043f\u043e\u0441\u0442\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0430\u0441\u044c \u0440\u0430\u0431\u043e\u0442\u0430 \u043d\u0430\u0434 \u0441\u0430\u0439\u0442\u043e\u043c \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440 \u0432 2012 \u0433\u043e\u0434\u0443, \u043a\u0430\u043a\u0438\u0435 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u0438\u0432\u044b \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u00ab\u043f\u0440\u043e\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u00bb \u0438 \u043d\u0430\u043e\u0431\u043e\u0440\u043e\u0442, \u043a\u0430\u043a\u0438\u0435 \u0433\u0440\u0430\u0431\u043b\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0445\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u043c\u044b\u0441\u043b\u044f\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043b\u0435\u0434\u0443\u044e\u0442 \u0437\u0430 \u0434\u0440\u0443\u0433\u0438\u043c \u0441\u044e\u0436\u0435\u0442\u043e\u043c \u2013 \u0432\u044b\u0431\u043e\u0440 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0434\u043b\u044f java-\u0431\u044d\u043a\u0435\u043d\u0434\u0430 \u0432 \u0430\u0434\u043c\u0438\u043d\u043a\u0435 \u0441\u0430\u0439\u0442\u0430. \u042d\u0442\u043e\u0442 \u0441\u044e\u0436\u0435\u0442","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-12T23:42:07+00:00","article:modified_time":"2020-03-12T23:42:07+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"73949","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:23:51","updated":"2022-09-28 05:05:57"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/73949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=73949"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/73949\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/73950"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=73949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=73949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=73949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}