Skalieren Sie bis zu 100 Millionen Benutzer. Zwischenspeichern oder nicht zwischenspeichern?

    Dies ist der zweite Teil der Serie Wix Scaling to 100 Million Users. Lesen Sie den Eintrag hier .

    Als wir gerade Wix gestartet haben, haben wir den Tomcat-, Hibernate- und Ehcache-Stack mit einer MySQL-Datenbank und einem Flash-Frontend verwendet. Warum haben wir diesen Stapel gewählt? Ja, einfach, weil unser erster Backend-Entwickler bereits Erfahrung mit ihm hatte. Teil dieser Architektur war Ehcache, eine großartige Cache-Bibliothek für Hibernate und die JVM, die eine Kartenabstraktion für den Speichercache erstellt hat und die auch als verteilter Cache konfiguriert werden kann. Ehcache wird im Gegensatz zu Memcached als Prozess in der JVM ausgeführt und repliziert den Cache-Status für alle Knoten im Cluster genau. Bitte beachten Sie, dass Encache zu diesem Zeitpunkt (um 2006–2008) noch ein unabhängiges Open Source-Projekt war und nicht Teil von Terracotta (das Replikations- und Verteilungsmodell kann innerhalb von Terracotta unterschiedlich sein, dies ist jedoch für diesen Artikel nicht so wichtig).

    Aspekte der Verwendung des Caches




    Da wir bereits echte Kunden hatten, haben wir zwei Tomcat-Server installiert, um die Zuverlässigkeit zu erhöhen. Gemäß den Regeln für die Erstellung der Architektur haben wir einen verteilten Ehcache-Cluster zwischen den Servern installiert. Wir gingen davon aus, dass MySQL langsam läuft (wie jedes andere SQL-System), was bedeutet, dass der RAM-Cache eine viel höhere Lesegeschwindigkeit bietet und die Datenbank entlastet.

    Aber was passiert, wenn wir auf ein Datenproblem stoßen, wie z. B. Datenbeschädigung oder Datenmüll? Wir nennen ein solches Problem einen "falschen Zustand". Ein solcher Fall trat auf, als wir eine Version des Wix-Editors herausbrachten, die eine falsche Site-Definition erzeugte. Das Symptom dieses Problems sind beschädigte Benutzer-Sites, d.h. Benutzer konnten ihre Websites nicht anzeigen und bearbeiten. Glücklicherweise haben Benutzer dieses Problem sofort entdeckt und gemeldet, da wir eine sehr große Anwenderbasis hatten (und haben). Wir haben die problematische Version zurückgesetzt und die beschädigten Definitionsdateien in der Datenbank behoben. Leider haben sich die Nutzer auch nach Korrekturen an allen Orten, an denen diese Daten gespeichert waren, weiterhin über beschädigte Websites beschwert. Der Grund war

    Ehcache ist eine Art „Black Box“: eine Java-Bibliothek ohne SQL-Abfrageoberfläche und ohne Steueranwendung zum Anzeigen des Cache-Inhalts. Da wir keine einfache Möglichkeit hatten, in den Cache zu "schauen", konnten wir ihn nicht diagnostizieren und analysieren, da Daten beschädigt wurden (beachten Sie, dass einige andere Cache-Lösungen Steueranwendungen haben, die sie in eine "weiße Box" verwandeln) hat mit keinem von ihnen gearbeitet). Als wir feststellten, dass sich der falsche Status anscheinend noch im Cache befand, mussten wir zunächst den falschen Status in der Datenbank korrigieren, um das Problem zu beheben. Beide Anwendungsserver haben einen falschen Status in ihrem Cache gespeichert. Daher haben wir zuerst einen der Server angehalten, um den Speichercache zu leeren und neu zu starten. Aber da der Cache verteilt wurde, Selbst nach dem Neustart des Servers wurde die Darstellung seines Speichercaches vom zweiten Anwendungsserver repliziert. Infolgedessen sind wir wieder in einen falschen Zustand zurückgekehrt. Ein Neustart des zweiten Servers in dieser Phase würde nicht helfen, der zweite Server würde eine Replikation des falschen Status vom ersten Server erhalten. Die einzige Möglichkeit, diesen inkorrekten Zustand zu beseitigen, bestand darin, beide Server anzuhalten und neu zu starten, was zu einer kurzfristigen Ausfallzeit unserer Dienste führte.

    Wie wäre es mit Cache-Invalidierung?


    Da wir Ehcache verwendet haben, das eine Steuer-API mit Unterstützung für die Ungültigmachung hat, konnten wir speziellen Code schreiben, der beide Server anweist, den Cache als ungültig zu betrachten (ungültiger Schalter). Wenn wir jedoch keinen ungültigen Switch für die Arbeit mit einem bestimmten Datentyp vorbereitet hätten, müssten wir beide Server gleichzeitig neu starten, um den falschen Status zu beseitigen. Natürlich können wir eine Verwaltungsanwendung für Ehcache erstellen, mit der Daten angezeigt und ungültig gemacht werden können. Aber in dem Moment, als es notwendig war, diese Entscheidung zu treffen, dachten wir: "Brauchen wir wirklich einen Cache?"

    Zuerst haben wir die MySQL-Statistiken überprüft. Es stellte sich heraus, dass Lesevorgänge bei ordnungsgemäßer Verwendung von MySQL selbst bei großen Tabellen Bruchteile von Millisekunden in Anspruch nehmen. Heute haben wir Tabellen mit über 100 Millionen Zeilen und lesen sie im Bruchteil einer Millisekunde. Wir haben dies erreicht, indem wir dem MySQL-Prozess genügend Speicher zur Verfügung gestellt haben, um mit dem Festplatten-Cache zu arbeiten, und indem wir einzelne Zeilen nach Primärschlüssel oder Index ohne Tabellenverknüpfung (JOIN) gelesen haben. Am Ende wurde uns klar, dass wir keinen Cache brauchten. Tatsächlich wird ein Cache in den meisten Fällen, in denen Benutzer ihn verwenden, nicht wirklich benötigt. Wir glauben, dass der Cache nicht Teil der Architektur ist. Es ist vielmehr eine der möglichen Lösungen für das Leistungsproblem und nicht die beste.

    Unsere Empfehlungen für die Verwendung des Caches sind:
    1. Sie brauchen keinen Cache.
    2. Nein, wirklich nicht benötigt.
    3. Wenn Sie immer noch Leistungsprobleme haben, sortieren Sie die Quelle aus. Was ist langsam? Warum läuft es langsam? Ist es möglich, die Architektur so zu ändern, dass sie nicht so langsam arbeitet? Ist es möglich, Daten zum Lesen zu optimieren?

    Wenn Sie einen Cache verwenden müssen, beachten Sie Folgendes:
    • Wie stellen Sie die Ungültigkeit des Cache sicher?
    • Wie werden die Daten im Cache angezeigt („Black Box“ oder „White Box“)?
    • Wie startet das System kalt? Kann das System den Datenverkehr mit einem leeren Cache bewältigen?
    • Welche Leistungseinbußen bringt der Cache mit sich?

    Chefarchitekt für Wix Website Designer Software,
    Yoav Abrahami
    Originalartikel: Wix Engineers Blog

    Jetzt auch beliebt: