Java-basierte Webanwendung mit hohem Transaktionsvolumen

Question

Ich habe so gut wie keine Erfahrung im Umgang mit Websites mit hohem Transaktionsvolumen und bin kürzlich auf diese interessante Frage gestoßen. Ich möchte wissen, wo die Engpässe in einer Java-Webanwendung bei hoher Last (Tausende von Anfragen pro Sekunde) auftreten. Wenn mir jemand einen allgemeinen Ansatz für die folgende Frage geben könnte, wäre das großartig!

Das Einzige, was mir eingefallen ist, ist die Verwendung von Memcached zum Zwischenspeichern der Datenbankabfragen, aber ich weiß nicht, wie ich die Zeit berechnen kann, die jede Anfrage benötigt, und wie viele Anfragen pro Sekunde das System daher bewältigen könnte.

Frage: Anwendungen im Internet müssen so konzipiert sein, dass sie ein hohes Transaktionsvolumen verarbeiten können. Beschreiben Sie einen Entwurf für ein System, das durchschnittlich 30.000 HTTP-Anfragen pro Sekunde verarbeiten muss. Für jede Anfrage muss das System eine Suche in einem Wörterbuch mit 50 Millionen Wörtern durchführen, wobei ein Schlüsselwort verwendet wird, das über den URL-Abfrage-String eingegeben wird. Jede Antwort besteht aus einem String, der die Definition des Wortes enthält (100 Bytes oder weniger).

Beschreiben Sie die Hauptbestandteile des Systems, und notieren Sie, welche Bestandteile und welche Komponenten auf Anwendungen Dritter zurückgreifen könnten. Geben Sie für jede Komponente eine Schätzung der Hardware an. Bitte beachten Sie, dass der Entwurf maximale Leistung bei minimalen Hardware-/Software-Lizenzkosten beinhalten sollte.

Dokumentieren Sie die Gründe, die zu den Schätzungen geführt haben.

Beschreiben Sie, wie sich der Entwurf ändern würde, wenn die Definitionen jeweils 10 Kilobyte groß wären.

Answer 1

Als Hintergrund können Sie Bechmarks wie die folgenden sehen specmarks . Verglichen mit Ihrem Szenario ist die Verarbeitung deutlich höher, aber Sie werden sehen, dass Ihre 30.000 Anforderungen pro Sekunde eine vergleichsweise hohe, aber nicht wahnsinnig hohe Zahl ist.

Sie können auch Folgendes finden Joines und andere nützlich. (Haftungsausschluss: Sie sind Kollegen.)

In Ihrem Szenario würde ich erwarten, dass die Kosten in absteigender Reihenfolge anfallen:

1. Datenbankabfrage
2. Netzwerkaktivität Lesen und Zurücksenden von Anfragen
3. Einfache Verarbeitung

Sie führen keine komplexen Verarbeitungen durch (z. B. grafisches Rendering oder raketenartige Mathematik). Erste Vermutung: Wenn Ihr Wörterbuch eine Datenbank wäre, dann würden die Kosten für eine Abfrage alles andere dominieren. Traditionell skalieren wir bei Engpässen in der Web-/App-Server-Ebene, indem wir mehr Instanzen hinzufügen, aber wenn die Datenbank der Engpass ist, ist das eher ein Problem. Also in eine Richtung: Welche Leistung können Sie von einer Datenbank-Engine erwarten - scheinen 30k tps machbar zu sein?

Ihre erste Beobachtung: Cache-Sachen sind eine häufig verwendete Strategie. Hier haben Sie (vermutlich) zufällige Treffer im gesamten Wörterbuch, so dass die Zwischenspeicherung der letzten Suchanfragen an sich wahrscheinlich nicht helfen wird, es sei denn ... können Sie die ganze Sache zwischenspeichern?

50.000.000 * (100 + Gemeinkosten) == ??

Auf einer 64bit JVM auf einem 64bit OS passt es vielleicht?

Wenn nicht (und wenn die Daten wirklich groß werden, dann wahrscheinlich nicht), dann müssen wir skalieren. Daher kann eine Strategie der Aufteilung des Cache verwendet werden. Man hat (zum Beispiel) 4 Server, die jeweils A-F, G-M, N-P, T-Z bedienen (und, wohlgemerkt, 4 separate Caches oder 4 separate Datenbanken). Ein Dispatcher leitet die Anfragen.

Answer 2

Als erstes würde ich die Zahlen in Frage stellen. Die englische Sprache hat etwa 170.000 Wörter im allgemeinen Sprachgebrauch. Zählt man alle anderen gebräuchlichen Sprachen hinzu, kommt man auf nicht mehr als ein paar Millionen. Wenn das nicht der Fall ist, könnte man die gebräuchlichsten Wörter in einem schnellen Cache und die weniger gebräuchlichen Wörter in einem langsameren Cache speichern. Selbst bei 30.000 Anfragen pro Sekunde würde es etwa 30 Minuten dauern, jedes einzelne Wort zu finden.

Im Grunde ist es sinnlos, ein großes System zu entwerfen, wenn die Zahlen nicht real sind.

Auf einer 64-Bit-JVM ist dies problemlos möglich. 50 Millionen * (100 + Overhead) sind etwa 10 GB (der Overhead ist hoch, da Sie den Schlüssel haben und die Daten indizieren müssen) Ein 12-GB-Server kostet etwa 2.500 $.

Das Problem ist wohl die Anzahl der Anfragen. Sie müssen mehrere Rechner haben, aber wie andere Poster bereits angedeutet haben, ist es sehr unwahrscheinlich, dass die Zahlen real sind. Ich kann mir nicht vorstellen, dass dieser Dienst so teuer ist wie Facebook, aber man braucht wahrscheinlich Dutzende bis Hunderte von Servern, um so viele Anfragen zu bearbeiten.