{"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 im Sportmaster das Caching-System ausgew\u00e4hlt haben. Teil 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hallo! Mein Name ist Alexey Pjankov, ich bin Entwickler bei Sportmaster. In diesem Beitrag<\/a><\/noindex> Artikel erz\u00e4hle ich, wie die Arbeit an der Sportmaster-Website im Jahr 2012 begann, welche Initiativen wir \"durchsetzen\" konnten und welche Herausforderungen wir dagegen \u00fcberwunden haben.<\/p>\n

Heute m\u00f6chte ich Gedanken teilen, die sich um ein anderes Thema drehen \u2013 die Auswahl eines Cache-Systems f\u00fcr das Java-Backend im Admin-Bereich der Website. Dieses Thema ist f\u00fcr mich von besonderer Bedeutung \u2013 obwohl die Geschichte nur zwei Monate dauerte, arbeiteten wir an diesen 60 Tagen 12-16 Stunden ohne einen einzigen freien Tag. Ich h\u00e4tte nie gedacht oder mir vorstellen k\u00f6nnen, dass man so viel arbeiten kann.<\/p>\n

Deshalb teile ich den Text in 2 Teile, um nicht zu \u00fcberlasten. Im Gegenteil, der erste Teil wird sehr leicht sein \u2013 eine Vorbereitung, eine Einf\u00fchrung und einige \u00dcberlegungen, was Cache bedeutet. Wenn Sie bereits ein erfahrener Entwickler sind oder mit Caches gearbeitet haben, wird dieser Artikel in technischer Hinsicht wahrscheinlich nichts Neues bieten. F\u00fcr einen Junior-Entwickler kann dieser kleine \u00dcberblick jedoch eine hilfreiche Richtung anzeigen, in die er schauen sollte, falls er vor einer solchen Entscheidung steht.<\/p>\n

\"Wie<\/a><\/noindex>
\n<\/a><\/noindex>
\nAls die neue Version der Sportmaster-Website in die Produktion ging, wurden die Daten auf eine, gelinde gesagt, nicht sehr bequeme Weise bereitgestellt. Die Grundlage bildeten Tabellen, die f\u00fcr die alte Version der Website (Bitrix) vorbereitet waren, die in ETL gebracht, in ein neues Format \u00fcberf\u00fchrt und mit verschiedenen kleinen Anpassungen aus einem Dutzend anderer Systeme angereichert werden mussten. Damit ein neues Bild oder eine Produktbeschreibung auf der Website erscheint, musste man bis zum n\u00e4chsten Tag warten \u2013 das Update fand nur nachts einmal t\u00e4glich statt.<\/p>\n

In den ersten Wochen nach dem Produktionsstart hatten wir so viele Anliegen, dass solche Unannehmlichkeiten f\u00fcr die Content-Manager kaum bedeutend waren. Aber sobald sich alles beruhigte, ging die Entwicklung des Projekts weiter \u2013 nach einigen Monaten, Anfang 2015, begannen wir aktiv, den Admin-Bereich zu entwickeln. 2015 und 2016 lief alles gut, wir ver\u00f6ffentlichten regelm\u00e4\u00dfig Updates, der Admin-Bereich deckte immer gr\u00f6\u00dfere Teile der Datenvorbereitung ab, und wir bereiteten uns darauf vor, dass unser Team bald mit dem Wichtigsten und Schwierigsten betraut wird \u2013 dem Produktbereich (vollst\u00e4ndige Vorbereitung und Verwaltung der Daten zu allen Produkten). Aber im Sommer 2017, kurz vor dem Launch des Produktbereichs, befand sich das Projekt in einer sehr schwierigen Situation \u2013 gerade wegen der Probleme mit dem Caching. \u00dcber diesen Zwischenfall m\u00f6chte ich in der zweiten Teil dieser zweiteiligen Ver\u00f6ffentlichung berichten.<\/p>\n

In diesem Beitrag m\u00f6chte ich von weitem anfangen und einige Gedanken \u2013 Vorstellungen zum Thema Caching zusammenfassen, die es wert w\u00e4ren, vor einem gro\u00dfen Projekt im Voraus durchdacht zu werden.<\/p>\n

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

\nDie Aufgabe des Cachings taucht nicht einfach so auf. Wir Entwickler entwickeln ein Softwareprodukt und wollen, dass es gefragt ist. Wenn das Produkt gefragt und erfolgreich ist \u2013 kommen die Nutzer. Und noch mehr Nutzer kommen dazu. Und dann sind es sehr viele Nutzer und das Produkt wird hochgradig belastet.<\/p>\n

In den ersten Phasen denken wir nicht \u00fcber die Optimierung und die Leistungsf\u00e4higkeit des Codes nach. Das Wichtigste ist die Funktionalit\u00e4t, schnell ein Pilotprojekt herauszubringen und Hypothesen zu \u00fcberpr\u00fcfen. Und wenn die Last steigt \u2013 verbessern wir die Hardware. Wir verdoppeln, verdreifachen, verf\u00fcnffachen, vielleicht auch verzehnfachen. Irgendwo hier \u2013 die Finanzen lassen das nicht mehr zu. Und um wie viel wird die Anzahl der Nutzer wachsen? Es wird nicht nur 2-5-10 sein, sondern im Erfolgsfall \u2013 es werden von 100-1000 bis zu 100.000 mehr sein. Das hei\u00dft, fr\u00fcher oder sp\u00e4ter m\u00fcssen wir uns mit der Optimierung befassen.<\/p>\n

Nehmen wir an, ein bestimmter Teil des Codes (nennen wir diesen Teil eine Funktion) ben\u00f6tigt unverh\u00e4ltnism\u00e4\u00dfig lange, und wir wollen die Ausf\u00fchrungszeit verk\u00fcrzen. Eine Funktion kann der Zugriff auf die Datenbank sein, es kann die Ausf\u00fchrung einer komplexen Logik sein \u2013 das Wichtigste ist, dass sie lange dauert. Wie viel kann die Ausf\u00fchrungszeit verk\u00fcrzt werden? Im besten Fall kann sie auf null gesenkt werden, nicht weiter. Und wie kann die Ausf\u00fchrungszeit auf null verk\u00fcrzt werden? Antwort: indem man die Ausf\u00fchrung einfach ausschlie\u00dft. Stattdessen \u2013 sofort das Ergebnis zur\u00fcckgeben. Und wie erf\u00e4hrt man das Ergebnis? Antwort: entweder berechnen oder irgendwo nachsehen. Berechnen \u2013 das ist zeitaufwendig. Und nachsehen \u2013 das bedeutet beispielsweise, sich das Ergebnis zu merken, das die Funktion beim letzten Aufruf mit den gleichen Parametern gegeben hat.<\/p>\n

Das hei\u00dft, die Implementierung der Funktion ist f\u00fcr uns unwichtig. Es reicht aus zu wissen, von welchen Parametern das Ergebnis abh\u00e4ngt. Wenn die Werte der Parameter als Objekt dargestellt werden, das als Schl\u00fcssel in einem bestimmten Speicher verwendet werden kann, k\u00f6nnen wir das Ergebnis der Berechnung speichern und beim n\u00e4chsten Aufruf abrufen. Wenn das Speichern und Abrufen des Ergebnisses schneller ist als die Ausf\u00fchrung der Funktion, haben wir einen Geschwindigkeitsvorteil. Der Umfang des Vorteils kann 100, 1000 oder sogar 100.000-fach (10^5 \u2013 das ist eher die Ausnahme, aber bei einer stark verz\u00f6gerten Datenbank durchaus m\u00f6glich) erreichen.<\/p>\n

Hauptanforderungen an das Cachesystem<\/h2>\n

\nDie erste Anforderung an ein Cachesystem k\u00f6nnte eine schnelle Lesegeschwindigkeit und in etwas geringerem Ma\u00dfe \u2013 die Schreibgeschwindigkeit sein. Das ist auch so, aber nur bis zu dem Punkt, an dem wir das System in die Produktion bringen.<\/p>\n

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

Angenommen, wir haben die aktuelle Last mit Hardware gedeckt und fangen nun allm\u00e4hlich an, das Caching einzuf\u00fchren. Die Anzahl der Nutzer steigt langsam an, die Last w\u00e4chst \u2013 wir f\u00fcgen ein wenig Caches hinzu und integrieren sie hier und da. Das geht eine Weile so weiter, und die rechenintensiven Funktionen werden praktisch nicht mehr aufgerufen \u2013 die gesamte Hauptlast liegt auf dem Cache. In dieser Zeit ist die Nutzerzahl um N-fach gestiegen.<\/p>\n

Und wenn der anf\u00e4ngliche Hardwarevorrat 2-5-fach gewesen sein k\u00f6nnte, so konnten wir mit Hilfe von Caching die Leistung um das 10-fache oder im besten Fall um das 100-fache steigern, an manchen Stellen vielleicht sogar um das 1000-fache. Das hei\u00dft, auf derselben Hardware bearbeiten wir 100-mal mehr Anfragen. Gro\u00dfartig, das haben wir uns verdient!<\/p>\n

Aber jetzt, eines sch\u00f6nen Tages, hat die Systemzuf\u00e4lligkeit versagt und der Cache ist zusammengebrochen. Nichts Besonderes \u2013 schlie\u00dflich haben wir den Cache nach den Anforderungen \u201ehohe Lese- und Schreibgeschwindigkeit, der Rest ist unwichtig\u201c ausgew\u00e4hlt.<\/p>\n

Relativ zur anf\u00e4nglichen Last hatten wir einen Hardwarevorrat von 2-5-fach, w\u00e4hrend die Last in dieser Zeit auf 10-100-fach gewachsen ist. Mit Hilfe des Caches haben wir Aufrufe f\u00fcr rechenintensive Funktionen ausgeschlossen und daher lief alles reibungslos. Und jetzt, ohne Cache \u2013 wie stark wird unser System zur\u00fcckgehen? Was wird mit uns passieren? Das System wird zusammenbrechen.<\/p>\n

Selbst wenn unser Cache nicht zusammengebrochen ist, sondern nur f\u00fcr eine gewisse Zeit geleert wurde, muss er wieder aufgew\u00e4rmt werden, und das wird einige Zeit in Anspruch nehmen. Und w\u00e4hrend dieser Zeit wird die Hauptlast auf die Funktionalit\u00e4t fallen.<\/p>\n

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

Das Dilemma der Auswahl<\/h2>\n

\nIn einem Projekt mit Admin-Bereich verlief die Auswahl so: Zun\u00e4chst haben wir Hazelcast gew\u00e4hlt, da wir bereits Erfahrungen mit diesem Produkt von der Hauptseite hatten. Allerdings stellte sich diese Wahl als ungl\u00fccklich heraus \u2013 unter unserem Lastprofil arbeitet Hazelcast nicht nur langsam, sondern extrem langsam. Und zu dem Zeitpunkt hatten wir uns bereits auf die Fristen f\u00fcr den Produktionsstart festgelegt.<\/p>\n

Spoiler: Wie genau die Umst\u00e4nde entstanden sind, dass wir eine solche Gelegenheit verpasst haben und in eine angespannte Situation geraten sind \u2013 dar\u00fcber werde ich im zweiten Teil berichten \u2014 wie wir dahin kamen und wie wir wieder herauskamen. Aber jetzt \u2014 ich sage nur, dass es ein gro\u00dfer Stress war, und \u201edenken geht nicht, wir sch\u00fctteln die Flasche\u201c. \u201eWir sch\u00fctteln die Flasche\u201c \u2014 das ist auch ein Spoiler, dar\u00fcber 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 einer Last, die f\u00fcr die Produktion typisch ist. Dazu haben wir Daten aufgezeichnet, die in einem Produktionsumfeld durch das System flie\u00dfen \u2013 eine Art Sniffer f\u00fcr Daten nicht im Netzwerk, sondern innerhalb des Systems. In die Tests haben wir genau diese Daten eingesetzt.<\/li>\n
  3. Das gesamte Team w\u00e4hlt gemeinsam das n\u00e4chste System aus der Liste aus, konfiguriert es und f\u00fchrt die Tests durch. Besteht der Test nicht, h\u00e4lt die Last nicht stand \u2013 wird das System verworfen, und wir wechseln zum n\u00e4chsten in der Reihe.<\/li>\n
  4. Bei System 17 wurde klar, dass alles aussichtslos ist. Genug \u201edie Flasche sch\u00fctteln\u201c, es ist Zeit, ernsthaft nachzudenken.<\/li>\n<\/ol>\n

    \nDies ist aber die Variante, wenn man ein System ausw\u00e4hlen muss, das in den vorab vorbereiteten Tests \u201eschnell genug\u201c ist. Aber was, wenn es noch keine solchen Tests gibt und man schneller ausw\u00e4hlen m\u00f6chte?<\/p>\n

    Wir simulieren ein solches Szenario (schwer vorstellbar, dass ein Mittel- oder Senior-Entwickler in einem Vakuum lebt und zum Zeitpunkt der Auswahl noch nicht entschieden hat, welches Produkt er zuerst ausprobieren m\u00f6chte \u2014 daher sind die weiteren \u00dcberlegungen eher theoretischer Natur \/ Philosophie \/ \u00fcber Junior-Entwickler).<\/p>\n

    Nachdem wir die Anforderungen festgelegt haben, beginnen wir mit der Auswahl einer Standardl\u00f6sung. Warum das Rad neu erfinden: Wir gehen und nehmen ein fertiges Caching-System.<\/p>\n

    Wenn Sie gerade erst anfangen und googeln, wird die Reihenfolge mehr oder weniger die gleiche sein, aber die Orientierungspunkte werden so sein. Zuerst werden Sie auf Redis sto\u00dfen, das \u00fcberall bekannt ist. Dann erfahren Sie, dass es EhCache gibt, das als das \u00e4lteste und bew\u00e4hrte System gilt. Danach wird \u00fcber Tarantool geschrieben \u2013 ein inl\u00e4ndisches Produkt, das einen einzigartigen Aspekt der L\u00f6sung bietet. Und auch Ignite, weil es derzeit an Popularit\u00e4t gewinnt und von SberTech unterst\u00fctzt wird. Zum Schluss noch Hazelcast, da es in der Unternehmenswelt oft bei gro\u00dfen Firmen erw\u00e4hnt wird.<\/p>\n

    Damit ist die Liste noch lange nicht ersch\u00f6pft; es gibt Dutzende von Systemen. Aber wir werden nur eines betrachten. Wir nehmen f\u00fcnf ausgew\u00e4hlte Systeme f\u00fcr einen \"Sch\u00f6nheitswettbewerb\" und f\u00fchren eine Auswahl durch. Wer wird der Sieger sein?<\/p>\n

    Redis<\/h3>\n

    \nLesen wir, was auf der offiziellen Website steht.
    \n    Redis<\/a><\/noindex> \u2013 Open-Source-Projekt. Es bietet einen In-Memory-Datenspeicher, die M\u00f6glichkeit zur Speicherung auf der Festplatte, automatische Partitionierung, hohe Verf\u00fcgbarkeit und Wiederherstellung nach Netzwerkunterbrechungen.<\/p>\n

    Eigentlich sieht alles gut aus, man kann es nehmen und integrieren \u2013 alles, was man braucht, macht es. Aber schauen wir nur aus Interesse auf die anderen Kandidaten.<\/p>\n

    EhCache<\/h3>\n

    \nEhCache<\/a><\/noindex> \u2013 \"der am weitesten verbreitete Cache f\u00fcr Java\" (\u00dcbersetzung des Slogans von der offiziellen Website). Auch Open-Source. Hier verstehen wir, dass Redis nicht f\u00fcr Java, sondern allgemein ist, und eine Wrapper f\u00fcr die Interaktion ben\u00f6tigt wird. EhCache wird bequemer sein. Was verspricht das System noch? Zuverl\u00e4ssigkeit, Bew\u00e4hrtheit, Vollst\u00e4ndigkeit. Au\u00dferdem ist es das am weitesten verbreitete. Und es cached Terabytes an Daten.<\/p>\n

    Redis ger\u00e4t in Vergessenheit, ich bin bereit, EhCache auszuw\u00e4hlen.<\/p>\n

    Aber das Gef\u00fchl des Patriotismus dr\u00e4ngt mich, zu schauen, was Tarantool gut macht.<\/p>\n

    Tarantool<\/h3>\n

    \nTarantool<\/a><\/noindex> \u2013 wird als \"Plattform f\u00fcr die Integration von Daten in Echtzeit\" bezeichnet. Es klingt sehr kompliziert, also lesen wir die Seite im Detail und finden eine gewagte Aussage: \"Cached 100 % der Daten im Arbeitsspeicher.\" Das sollte Fragen aufwerfen \u2013 denn es kann deutlich mehr Daten als Speicher geben. Die Erkl\u00e4rung ist, dass damit gemeint ist, dass Tarantool beim Schreiben von Daten auf die Festplatte die Serialisierung im Arbeitsspeicher \u00fcberspringt. Stattdessen nutzt es die Low-Level-Eigenschaften des Systems, bei denen der Speicher einfach auf das Dateisystem abgebildet wird, mit sehr guten I\/O-Werten. Insgesamt haben sie es erstaunlich und gro\u00dfartig gemacht.<\/p>\n

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

    Wenn es noch irgendwelche Zweifel an Tarantool gab, dann rei\u00dft mich der Implementierungsfall bei Mastercard endg\u00fcltig um. Ich w\u00e4hle Tarantool.<\/p>\n

    Aber trotzdem\u2026<\/p>\n

    Ignite<\/h3>\n

    \n\u2026 gibt es noch Ignite<\/a><\/noindex>, angek\u00fcndigt als \u201ein-memory Rechenplattform\u2026 in-memory Geschwindigkeiten auf Petabytes von Daten\u201c. Auch hier gibt es viele Vorteile: verteiltes in-memory Caching, der schnellste Key-Value Speicher und Cache, horizontale Skalierung, hohe Verf\u00fcgbarkeit, strikte Integrit\u00e4t. Insgesamt stellt sich heraus, dass Ignite das schnellste ist.<\/p>\n

    Implementierungen: Sberbank, American Airlines, Yahoo! Japan. Und dann erfahre ich auch noch, dass Ignite nicht nur in der Sberbank implementiert ist, sondern dass das SberTech-Team seine Leute ins Team von Ignite sendet, um das Produkt weiterzuentwickeln. Das \u00fcberzeugt mich vollst\u00e4ndig und ich bin bereit, Ignite zu w\u00e4hlen.<\/p>\n

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

    Hazelcast<\/h3>\n

    \nIch gehe auf die Website Hazelcast<\/a><\/noindex>, lese. Und es stellt sich heraus, dass die schnellste L\u00f6sung f\u00fcr verteiltes Caching Hazelcast ist. Es ist um ein Vielfaches schneller als alle anderen L\u00f6sungen und generell ist es der Marktf\u00fchrer im Bereich in-memory Daten-Grid. Vor diesem Hintergrund etwas anderes zu w\u00e4hlen \u2014 das w\u00e4re Selbstmissachtung. Au\u00dferdem nutzt es redundante Datenspeicherung f\u00fcr einen kontinuierlichen Betrieb des Clusters ohne Datenverluste.<\/p>\n

    Ich bin bereit, Hazelcast zu w\u00e4hlen.<\/p>\n

    Vergleich<\/h2>\n

    \nAber wenn man sich das anschaut, sind alle f\u00fcnf Kandidaten so beschrieben, dass jeder von ihnen der beste ist. Wie w\u00e4hlt man aus? Wir k\u00f6nnen sehen, welcher von ihnen am beliebtesten ist, nach Vergleichen suchen, und das Kopfzerbrechen wird verschwinden.<\/p>\n

    Wir finden so etwas \u00dcberblick<\/a><\/noindex>, w\u00e4hlen unsere 5 Systeme aus.<\/p>\n

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

    Aber schauen wir uns die Berechnungsmethode<\/a><\/noindex>: Links zu Websites, allgemeines Interesse am System, Jobangebote \u2014 gro\u00dfartig! Das hei\u00dft, wenn mein System ausf\u00e4llt, sage ich: \u201eNein, es ist zuverl\u00e4ssig! Hier gibt es viele Stellenangebote\u2026\u201c. So ein einfacher Vergleich passt nicht.<\/p>\n

    All diese Systeme sind nicht nur Systeme zum Cachen. Sie haben auch sehr viele Funktionen, einschlie\u00dflich \u2013 wenn nicht die Daten zum Verarbeiten an den Kunden \u00fcbertragen werden, sondern umgekehrt: der Code, der \u00fcber 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 so oft betrachtet.<\/p>\n

    Gut, wir geben nicht auf, wir finden einen direkten Vergleich der Systeme. Nehmen wir die beiden obersten Optionen \u2014 Redis und Hazelcast. Wir interessieren uns f\u00fcr Geschwindigkeiten, und nach diesem Parameter vergleichen wir sie.<\/p>\n

    Hz vs Redis<\/h3>\n

    \nWir finden so etwas der Vergleich<\/a><\/noindex>:
    \n\"Wie
    \n
    \nBlau ist Redis, rot ist Hazelcast. Hazelcast gewinnt \u00fcberall, und das ist begr\u00fcndet: Es ist mehrthreadig, hochoptimiert, jeder Thread arbeitet mit seiner eigenen Partition, daher gibt es keine Sperren. Redis hingegen ist ein einthreadiges System; es profitiert nicht von modernen Mehrkern-CPUs. Hazelcast verwendet asynchrones I\/O, w\u00e4hrend Redis-Jedis blockierende Sockets nutzt. Schlie\u00dflich verwendet Hazelcast ein Bin\u00e4rprotokoll, w\u00e4hrend Redis textorientiert ist, was ineffizient ist.<\/p>\n

    Der Vollst\u00e4ndigkeit halber schauen wir uns eine weitere Vergleichsquelle an. Was wird sie uns zeigen?<\/p>\n

    Redis vs Hz<\/h3>\n

    \nNoch ein weiteres der Vergleich<\/a><\/noindex>:
    \n\"Wie
    \n
    \nHier ist es umgekehrt, rot ist Redis. Das bedeutet, Redis \u00fcbertrifft Hazelcast in Bezug auf die Leistung. Im ersten Vergleich gewann Hazelcast, im zweiten jedoch Redis.     Hier<\/a><\/noindex> wurde sehr pr\u00e4zise erkl\u00e4rt, warum Hazelcast im vorherigen Vergleich gewonnen hat.<\/p>\n

    Es stellte sich heraus, dass das Ergebnis des ersten Vergleichs tats\u00e4chlich manipuliert war: Redis wurde in der Standardkonfiguration verwendet, w\u00e4hrend Hazelcast auf den Testfall optimiert war. Das f\u00fchrt dazu, dass: Erstens, man niemandem trauen kann, und zweitens, wenn wir unser System schlie\u00dflich w\u00e4hlen, m\u00fcssen wir es richtig konfigurieren. Diese Konfiguration umfasst Dutzende, fast Hunderte von Parametern.<\/p>\n

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

    \nUnd den gesamten Prozess, den wir gerade durchlaufen haben, kann ich mit der Metapher \"Wir sch\u00fctteln die Flasche\" erkl\u00e4ren. Das hei\u00dft, jetzt kann man nicht programmieren, jetzt ist es wichtig, Stack Overflow lesen zu k\u00f6nnen. Und in meinem Team gibt es eine Person, einen Experten, der genau so in kritischen Momenten arbeitet.<\/p>\n

    Was macht er? Er sieht ein nicht funktionierendes Teil, erkennt den Stack Trace, nimmt einige W\u00f6rter daraus (welche genau das sind, ist seine Expertise in der Software), sucht bei Google und findet darunter Stack Overflow. Ohne zu lesen oder nachzudenken w\u00e4hlt er aus den Antworten auf die Frage etwas aus, das am ehesten wie der Vorschlag \"das und das zu tun\" klingt (diese Auswahl ist sein Talent, denn es ist nicht immer die Antwort, die die meisten Likes bekommt), implementiert es, schaut: Wenn sich etwas ge\u00e4ndert hat, gro\u00dfartig. Wenn nichts passiert ist, rollen wir zur\u00fcck. Und wir wiederholen den Start-Test-Suchprozess. Auf diese intuitive Weise bringt er es zustande, dass der Code nach einer Weile funktioniert. Er wei\u00df nicht warum, er wei\u00df nicht, was er getan hat, und kann es nicht erkl\u00e4ren. Aber! Das Ding funktioniert. Und \"das Feuer ist gel\u00f6scht\". Jetzt schauen wir uns an, was wir getan haben. Wenn die Software funktioniert, ist es um vieles leichter. Und es spart erheblich Zeit.<\/p>\n

    Dieser Ansatz wird sehr gut durch folgendes Beispiel erkl\u00e4rt.<\/p>\n

    Es war einst sehr beliebt, ein Segelschiff in einer Flasche zu bauen. Dabei ist das Segelschiff gro\u00df und zerbrechlich, w\u00e4hrend der Flaschenhals sehr schmal ist, sodass es nicht hineinpasst. Wie kann man es zusammenbauen?<\/p>\n

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

    Das Schiff besteht aus vielen kleinen Dingen: St\u00e4bchen, Schn\u00fcre, Segel, Kleber. All das legen wir in die Flasche.
    \nWir nehmen die Flasche mit beiden H\u00e4nden und beginnen zu sch\u00fctteln. Wir sch\u00fctteln und sch\u00fctteln. Und normalerweise \u2014 dabei kommt nat\u00fcrlich nichts Gutes heraus. Aber manchmal, manchmal entsteht ein Schiff! Genauer gesagt, etwas \u00e4hnliches wie ein Schiff.<\/p>\n

    Wir zeigen dieses Etwas jemandem: \u201eSiehst du, Serjoga!?\u201c. Und tats\u00e4chlich, aus der Ferne sieht es aus wie ein Schiff. Aber weitergeben kann man es nicht.<\/p>\n

    Es gibt noch einen anderen Weg. Fortgeschrittene Typen verwenden ihn, solche Hacker.<\/p>\n

    Ich gab einem solchen Typen eine Aufgabe, er erledigte alles und ging. Und wenn man schaut \u2013 sieht es aus, als w\u00e4re es gemacht. Aber nach einer Weile, wenn man den Code nachbessern muss \u2014 f\u00e4ngt das an, wegen ihm\u2026 Gut, dass er schon weit weggelaufen ist. Das sind solche Typen, die aus dem Beispiel der Flasche das machen: Siehst du, wo der Boden ist \u2013 das Glas biegt sich. Und es ist nicht ganz klar, ob es durchsichtig ist oder nicht. Dann s\u00e4gen die \u201eHacker\u201c diesen Boden ab, setzen das Schiff hinein, kleben den Boden dann wieder fest, und es sieht so aus, als w\u00e4re es genau so n\u00f6tig.<\/p>\n

    Aus der Sicht der Aufgabenstellung scheint alles korrekt zu sein. Aber aus Sicht der Schiffe: Warum \u00fcberhaupt dieses Schiff machen, wem n\u00fctzt es \u00fcberhaupt? Funktionalit\u00e4t hat es keine. Solche Schiffe sind meistens Geschenke f\u00fcr sehr hochrangige Personen, die es auf das Regal \u00fcber sich stellen, als ein gewisses Symbol, als Zeichen. Und wenn bei so einer Person, einem Leiter eines gro\u00dfen Unternehmens oder eines hochrangigen Beamten, ein solches St\u00fcck Arbeit, dessen Flaschenhals abges\u00e4gt ist, als Flagge aufgestellt wird? Es w\u00e4re besser, wenn er niemals davon erf\u00e4hrt. Wie werden also diese Schiffe hergestellt, die man wichtigen Personen schenken kann?<\/p>\n

    Der einzige Ort, an dem man wirklich nichts machen kann, ist der Rumpf. Und der Rumpf des Schiffs passt genau durch den Flaschenhals. W\u00e4hrend das Schiff au\u00dferhalb der Flasche zusammengesetzt wird. Aber es geht nicht nur darum, das Schiff zusammenzubauen, es ist ein echtes Juwelierhandwerk. In die Einzelteile werden spezielle Hebel eingef\u00fcgt, die es sp\u00e4ter erm\u00f6glichen, sie anzuheben. Zum Beispiel werden die Segel gefaltet, sorgf\u00e4ltig nach innen gebracht, und dann werden sie mit einer Pinzette sehr kunstvoll, genau, angehoben und angezogen. Das Ergebnis ist ein Kunstwerk, das man mit reinem Gewissen und Stolz verschenken kann.<\/p>\n

    Und wenn wir wollen, dass das Projekt erfolgreich ist, muss mindestens eine Person im Team ein Juwelier sein. Jemand, der sich um die Qualit\u00e4t des Produkts k\u00fcmmert und alle Aspekte ber\u00fccksichtigt, ohne einen einzigen auch in stressigen Momenten zu opfern, wenn die Umst\u00e4nde verlangen, etwas Dringendes auf Kosten des Wichtigen zu tun. Alle erfolgreichen Projekte, die nachhaltig sind und die Zeit \u00fcberstanden haben, basieren auf diesem Prinzip. Sie haben etwas sehr Pr\u00e4zises und Einzigartiges, etwas, das alle verf\u00fcgbaren M\u00f6glichkeiten nutzt. Im Beispiel mit dem Schiff in der Flasche wird gespielt mit der Tatsache, dass der Rumpf des Schiffs durch den Flaschenhals geht.<\/p>\n

    Um auf die Aufgabe der Auswahl unseres Cache-Servers zur\u00fcckzukommen, wie k\u00f6nnte dieser Ansatz angewendet werden? Ich schlage einen Auswahlansatz aus all den verf\u00fcgbaren Systemen vor: nicht die Flasche sch\u00fctteln, nicht ausw\u00e4hlen, sondern zu schauen, was grunds\u00e4tzlich darin vorhanden ist, auf das man bei der Auswahl des Systems achten sollte.<\/p>\n

    Wo den Flaschenhals suchen.<\/h2>\n

    \nLassen Sie uns versuchen, die Flasche nicht zu sch\u00fctteln, nicht alles nacheinander zu durchgehen, sondern zu sehen, welche Aufgaben auftreten, wenn wir pl\u00f6tzlich f\u00fcr unsere Aufgabe - ein solches System selbst zu entwerfen. Wir werden nat\u00fcrlich kein Fahrrad neu erfinden, sondern dieses Schema nutzen, um uns zu orientieren, auf welche Punkte wir in den Produktbeschreibungen achten sollten. Lassen Sie uns ein solches Schema skizzieren.<\/p>\n

    \"Wie
    \n
    \nWenn das System verteilt ist, haben wir mehrere Server (6). Nehmen wir an, vier (bequem, um sie im Bild darzustellen, aber nat\u00fcrlich kann es beliebig viele geben). Wenn die Server auf verschiedenen Knoten sind, l\u00e4uft auf ihnen allen ein gewisser Code, der daf\u00fcr verantwortlich ist, dass diese Knoten ein Cluster bilden und sich im Falle einer Unterbrechung wieder verbinden und erkennen.<\/p>\n

    Es wird noch eine Code-Logik (2) ben\u00f6tigt, die sich mit dem Caching befasst. Mit diesem Code interagieren die Clients \u00fcber eine bestimmte API. Der Client-Code (1) kann sowohl innerhalb derselben JVM laufen als auch \u00fcber das Netzwerk darauf zugreifen. Die implementierte Logik besteht darin, welche Objekte im Cache behalten und welche verworfen werden. F\u00fcr die Speicherung des Caches verwenden wir den Speicher (3), aber wenn n\u00f6tig, k\u00f6nnen wir auch einen Teil der Daten auf der Festplatte speichern (4).<\/p>\n

    Lassen Sie uns betrachten, in welchen Bereichen die Last entstehen wird. Im Grunde genommen werden jede Pfeilspitze und jeder Knoten belastet. Erstens kann es zwischen dem Client-Code und der API, wenn es sich um eine Netzwerkinteraktion handelt, zu sp\u00fcrbaren Verz\u00f6gerungen kommen. Zweitens, innerhalb der API selbst \u2013 wenn wir zu viel komplexer Logik einsetzen, k\u00f6nnten wir auf die CPU sto\u00dfen. Es w\u00e4re gut, wenn die Logik den Speicher nicht unn\u00f6tig beansprucht. Und es bleibt die Interaktion mit dem Dateisystem \u2013 im Normalfall bedeutet das Serialisieren\/Wiederherstellen und Schreiben\/Lesen.<\/p>\n

    Dann gibt es die Interaktion mit dem Cluster. H\u00f6chstwahrscheinlich wird es sich im selben System befinden, kann aber auch separat sein. Auch hier muss die Daten\u00fcbertragung zu ihm, die Geschwindigkeit der Datenserialisierung und die Interaktion zwischen den Clustern ber\u00fccksichtigt werden.<\/p>\n

    Jetzt k\u00f6nnen wir einerseits \u00fcberlegen, \u201ewelche Zahnr\u00e4der sich\u201c im Caching-System bei der Verarbeitung von Anfragen von unserem Code drehen werden, und andererseits k\u00f6nnen wir einsch\u00e4tzen, welche und wie viele Anfragen unser Code an dieses System generieren wird. Das reicht aus, um eine mehr oder weniger kluge Entscheidung zu treffen \u2013 ein System f\u00fcr unsere Nutzung auszuw\u00e4hlen.<\/p>\n

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

    Lassen Sie uns anschauen, wie wir eine solche Aufteilung auf unsere Liste anwenden k\u00f6nnen. Zum Beispiel, Hazelcast.<\/p>\n

    Um Daten in Hazelcast zu speichern\/abzurufen, spricht der Client-Code (1) die API an. Hz erm\u00f6glicht es, den Server als Embedded zu starten, und in diesem Fall ist der API-Aufruf ein Methodenaufruf 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 besondere F\u00e4lle k\u00f6nnen eigene hinzugef\u00fcgt werden. Um diesen Teil muss man sich keine Sorgen machen.<\/p>\n

    Das Speicher (4) kann angeschlossen werden. Ausgezeichnet. Die Interaktion (5) f\u00fcr Embedded kann als sofort betrachtet werden. Der Datenaustausch zwischen den Knoten im Cluster (6) \u2013 ja, das gibt es. Dies ist ein Beitrag zur Fehlertoleranz auf Kosten der Geschwindigkeit. Die N\u00e4he von Hz-Funktion Near-cache senkt die Kosten \u2013 Daten, die von anderen Knoten des Clusters erhalten wurden, werden zwischengespeichert.<\/p>\n

    Was kann unter diesen Bedingungen zur Geschwindigkeitssteigerung unternommen werden?<\/p>\n

    Um beispielsweise die Serialisierung des Schl\u00fcssels in (2) zu vermeiden \u2013 einen weiteren Cache \u00fcber Hazelcast zu legen, f\u00fcr die am h\u00e4ufigsten genutzten Daten. Bei Sportmaster haben wir daf\u00fcr Caffeine ausgew\u00e4hlt.<\/p>\n

    F\u00fcr Anpassungen auf Ebene (6) werden in Hz zwei Speichertypen angeboten: IMap und ReplicatedMap.
    \n\"Wie
    \n
    \nEs sei gesagt, wie Hazelcast in den Technologiestack von Sportmaster gelangte.<\/p>\n

    Im Jahr 2012, als wir an dem allerersten Pilotprojekt der zuk\u00fcnftigen Website arbeiteten, war es genau Hazelcast, der der erste Link war, den die Suchmaschine zur\u00fcckgab. Die Bekanntschaft entstand \"auf den ersten Blick\" \u2013 wir waren begeistert, dass er nur zwei Stunden sp\u00e4ter, nachdem wir Hz in das System integriert hatten \u2013 funktionierte. Und zwar gut. Bis zum Ende des Tages haben wir eine Anzahl von Tests geschrieben und uns gefreut. Und diese Energie reichte aus, um die \u00dcberraschungen zu \u00fcberwinden, die Hz im Laufe der Zeit bot. Jetzt hat das Team von Sportmaster keinen Grund, Hazelcast abzulehnen.<\/p>\n

    Aber solche Argumente wie \"der erste Link in der Suchmaschine\" und \"schnell ein HelloWorld zusammengestellt\" \u2013 das sind nat\u00fcrlich Ausnahmen und Besonderheiten des Moments, in dem die Auswahl getroffen wurde. Die wirklichen Pr\u00fcfungen f\u00fcr das gew\u00e4hlte System beginnen mit dem Wechsel in die Produktion, und genau auf diesen Schritt sollte man bei der Auswahl eines jeden Systems, einschlie\u00dflich Caching, achten. Man kann sagen, dass wir Hazelcast zuf\u00e4llig gew\u00e4hlt haben, aber sp\u00e4ter stellte sich heraus, dass die Wahl richtig war.<\/p>\n

    F\u00fcr die Produktion sind viel wichtiger: Monitoring, Fehlerbehandlung auf einzelnen Knoten, Datenreplikation, Kosten f\u00fcr das Scaling. Das hei\u00dft, man sollte auf die Aufgaben achten, die beim Betrieb des Systems auftreten \u2013 wenn die Last um das Zehnfache die geplante \u00fcbersteigt, wenn wir versehentlich etwas Falsches und auf den falschen Ort hochladen, wenn eine neue Version des Codes ausgerollt und Daten ersetzt werden m\u00fcssen und dies unbemerkt f\u00fcr die Kunden geschieht.<\/p>\n

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

    Fortsetzung folgt<\/h2>\n

    \nAber Hazelcast ist kein Allheilmittel. 2017 w\u00e4hlten wir Hazelcast als Cache f\u00fcr das Admin-Panel, einfach basierend auf den positiven Eindr\u00fccken aus der Vergangenheit. Dies spielte eine Schl\u00fcsselrolle in einem sehr b\u00f6sen Witz, wodurch wir uns in einer schwierigen Situation wiederfanden und uns \"heldenhaft\" 60 Tage daraus herausk\u00e4mpfen mussten. Aber davon in dem n\u00e4chsten Teil.<\/p>\n

    Und bis dahin... 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 gew\u00e4hlt haben. Teil 1 | ProHoster","description":"Hallo! Ich hei\u00dfe Alexey Pjankov, ich bin Entwickler bei Sportmaster.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}