Sharding (sic!) Die Webstufe, um einen Engpass für Ladung Balancer zu verhindern?

StackOverflow https://stackoverflow.com/questions/215347

Frage

Wie erreichen große Websites, die in der Webstufe nicht vollständig staatenlos sein können, extreme Skalierbarkeit?

Es gibt Websites wie eBay und Amazon, die nicht völlig staatenlos sein können, da sie einen Einkaufswagen oder ähnliches haben. Es ist nicht möglich, jeden Artikel im Einkaufswagen in die URL zu codieren, und es ist auch nicht möglich, jeden Artikel in einen Keks zu codieren und in jeder Verbindung zu senden. Deshalb speichert Amazon das Session-ID einfach in den Sendungen des Cookies. Ich verstehe also, dass die Skalierbarkeit der Webstufe von eBay und Amazon viel schwieriger sein sollte als die Skalierbarkeit der Google -Suchmaschine, bei der alles in die URL eingestuft werden kann.

Andererseits skalierte sowohl eBay als auch Amazon absolut massiv. Gerüchte sind, dass es bei eBay rund 15000 J2EE -Anwendungsserver gibt.

Wie gehen diese Websites mit beiden um: extreme Skalierbarkeit und Zustandsheit? Da die Website staatlich ist, ist es nicht möglich, einen einfachen DNS-Balancing zu machen. Man würde also annehmen, dass diese Unternehmen über einen Hardware -basierten Lastausgleich wie Bigip, NetScaler oder ähnliches haben, was das einzige Gerät hinter der einzelnen IP -Adresse dieser Website ist. Dieser Lastausgleich würde die SSL entschlüsseln (falls codiert), das Cookie inspizieren und entscheiden, abhängig von der Sitzungs -ID dieses Cookies, welcher Anwendungsserver die Sitzung dieses Kunden enthält.

Aber dies kann unmöglich funktionieren, da kein einzelner Lastballer die Last von Tausenden von Anwendungsservern bewältigen könnte? Ich würde mir vorstellen, dass selbst diese Hardware -Ladungsbalancer nicht auf ein solches Niveau skalieren.

Außerdem wird das Ladungsausgleich für den Benutzer transparent durchgeführt, dh die Benutzer werden nicht an verschiedene Adressen weitergeleitet, bleiben jedoch die ganze Zeit über auf www.amazon.com.

Meine Frage ist also: Gibt es einen besonderen Trick, mit dem man so etwas wie transparentes Sharding der Webebene erreichen kann (nicht die Datenbankstufe wie häufig)? Solange das Cookie nicht überprüft wird, gibt es keine Möglichkeit zu wissen, welcher Anwendungsserver diese Sitzung abhält.

Bearbeiten: Mir wurde klar, dass nur Transparenz erforderlich ist, wenn die Website spinnd und mit einem Lesezeichen versehen ist. ZB der Website ist eine bloße Web -App, so etwas wie ein Flugzeug- oder Zug -Ticket -Reservierungssystem, es sollte kein Problem sein, wenn Sie die Benutzer nur auf bestimmte Cluster von Webservern hinter verschiedenen URLs umleiten, z. B. A17.TicketReervation.com. In diesem speziellen Fall wäre es möglich, nur mehrere Cluster von Anwendungsservern zu verwenden, die jeweils hinter seinem eigenen Lastausgleicher sind. Interessanterweise habe ich keine Website gefunden, die diese Art von Konzept verwendet.Bearbeiten: Ich fand dieses Konzept besprochen bei HighScalability.com, wo die Diskussion auf einen Artikel von Lei Zhu namens bezieht "Client Side Load Balancing für Web 2.0 -Anwendungen". Lei Zhu verwendet Cross -Scripting, um diese Client -Lastausgleich transparent durchzuführen.

Auch wenn es Nachteile wie Lesezeichen, XSS usw. gibt, denke ich, dass dies nach einer äußerst guten Idee für bestimmte besondere Situationen klingt, nämlich fast inhaltsfrei Systeme oder so ähnlich). Dann müssen die Lastausgleich nicht transparent durchführen.

Es könnte eine einfache Weiterleitung von der Hauptseite zum Server geben, z. B. eine Weiterleitung von www.ticketreervation.com zu a17.ticketreervation.com. Von dort aus bleibt der Benutzer auf dem Server A17. A17 ist kein Server, sondern ein Cluster selbst, durch den Redundanz erreicht werden kann.

Der anfängliche Umleitungsserver könnte selbst ein Cluster hinter einem Lastausgleich sein. Auf diese Weise könnte eine wirklich hohe Skalierbarkeit erreicht werden, da der primäre Lastausgleich hinter WWW erst einmal zu Beginn jeder Sitzung getroffen wird.

Natürlich sieht die Umleitung zu verschiedenen URLs äußerst böse aus, aber mit bloßen Webanwendungen (die sowieso nicht spinziert, tiefgeblieben oder tief buchstäbig markiert werden müssen) sollte dies nur ein optisches Problem für den Benutzer sein?

Der Umleitungscluster könnte die Last der Anwendungscluster befragen und die Weiterleitungen entsprechend anpassen, wodurch ein Gleichgewicht erreicht wird und nicht die bloße Lastverteilung.

War es hilfreich?

Lösung

Einfach. Die Webserver, die staatenlos sind, sind ausgeglichen. Die Anwendungsserver (Mittelstufe), die die Sitzungsdaten enthalten, sind nicht. Die Webserver können Ihr Sitzungs -ID -Cookie verwenden, um zu bestimmen, an welchen App -Server Sie kontaktieren sollen.

Memcached und Microsofts Geschwindigkeit sind Produkte, die genau diesen Bedarf lösen.

Bearbeiten: Woher weiß ein Webserver, welcher App -Server Sie kontaktieren sollen? Dies ist in den Sitzungs -ID -Hash eingebettet und könnte allgemein erledigt werden, wie Sie möchten. Es kann so einfach sein wie Ihre Sitzungs -ID -Server: GUID. Memcached stützt es jedoch vom Hash.

Das wichtige Bit ist, dass der Client in der Lage sein muss, herauszufinden, welchen App -Server sie staatenlos kontaktieren soll. Der einfachste Weg, dies zu tun, besteht darin, es in den Schlüssel zu bringen, obwohl auch eine Registrierung (möglicherweise in ihrer eigenen Stufe) funktionieren würde und eine Fehlertoleranz liefern könnte.

Edit2: Zurück gehen etwas Ebay Interviews, Möglicherweise habe ich die Einzelheiten ihrer Implementierung etwas falsch gemacht. Sie zwischengespeichert nicht und geben in der mittleren Stufe nicht an. Was sie tun, ist, eine von der Funktion verteilte Ladung ausbalanciert zu haben (App -Server). Sie hätten also einen Pool von Servern für, z. B. Gegenstände. Und dann ein weiterer Pool zum Verkauf von Artikeln.

Diese App-Server verfügen über einen "intelligenten" Dal, der zu Sharded-Datenbanken leitet (sowohl nach Funktion als auch von Daten partitioniert, sodass Benutzer AL in Database1, Benutzer MZ auf Datenbank2, Elemente 1-10000 auf Elementen1 usw.).

Sie haben keinen Zustand in der mittleren Ebene, weil sie von Funktion aufgeteilt werden. Eine normale Benutzererfahrung würde also mehr als 1 Pool von App -Servern umfassen. Angenommen, Sie sehen einen Artikel (viewAppServerpool) und dann zu einem Artikel (bidappserverpool). Alle diese App -Server müssten synchron bleiben, was dann einen verteilten Cache erfordert, um alles zu verwalten. Ihre Skala ist jedoch so groß, dass kein verteilter Cache ihn effektiv verwalten kann, noch ein einzelner Datenbankserver. Dies bedeutet, dass sie die Datenstufe schärfen müssen, und jede Cache -Implementierung müsste über die gleichen Grenzen aufgeteilt werden.

Das ist ähnlich Zu dem, was ich oben gepostet habe, bewegte sich einfach eine Ebene. Anstatt der Webserver zu bestimmen, an dem der App -Server kontaktiert werden soll, stellt der App -Server fest, an welcher Datenbank Sie sich wenden sollen. Nur in eBays Fall könnte es aufgrund ihrer Partitionsstrategie tatsächlich mehr als 20 Datenbankserver treffen. Aber auch hier hat die staatenlose Stufe eine Art Regel (en), mit der sie die staatliche Stufe kontaktiert. Die Regeln von eBay sind jedoch etwas komplizierter als das simple "user1 is on server10" -Regel, das ich oben erläutert habe.

Andere Tipps

Sie können das folgende Papier nützlich finden, in dem das Design und die Implementierung eines hoch verfügbaren Schlüsselwert-Speichersystems vorgestellt werden, mit dem einige der Kerndienste von Amazon ein „immer-On“ -Lehenserlebnis bieten:

Giuseppe Decandia, Deniz Hastorun, Madan Jampani, Gunavardhan Kakulapati, Avinash Lakshman, Alex Pilchin, Swami Sivasubramanian, Peter Vosshall und Werner Vogels, “Dynamo: Der hoch verfügbar”, Im Verfahren des 21. ACM -Symposiums für Betriebssysteme Prinzipien, Stevenson, WA, Oktober 2007.

Sie müssten wahrscheinlich im Ingenieurteam an einem dieser Orte sein, um sie sicher zu wissen, aber es gibt Menschen, die aus Gesprächen und anderen Informationen, die aus beiden Orten herausgekommen sind, fundierte Vermutungen gemacht haben:

EBay Architektur und Amazon Architektur

Nur ein einzelner Lastausgleich für sich in der heutigen Welt ist das Äquivalent von DNS -Rund -Robin der vergangenen Jahre. Heute hast du Dinge wie wie Anycast Das lässt Sie alle möglichen Tricks spielen. Sie können sich ziemlich sicher sein, dass eBay und Amazon Lastbalancer verwenden und viele von ihnen verwenden.

Möglicherweise möchten Sie es ein wenig mehr abkochen, wenn Sie darüber nachdenken, wie es funktionieren könnte, da ein Großteil des Verkehrs Staatenlos ist. In einer einzigen Anfrage für eine Seite gibt es möglicherweise viele Objekte, die nichts über den Zustand wissen müssen. Nehmen Sie diese Objekte aus dem Bild, indem Sie sie aus einem staatenlosen System bedienen (hier kommt der Anycast ins Spiel) und die Anzahl der Anfragen sinkt dramatisch.

Wenn Sie dies nicht zu dem Punkt bringen, an dem ein einzelner Lastbalancer die Last verarbeiten kann, besteht der nächste Schritt darin, die Transaktionen mithilfe von IP-Routing und/oder Geo-DNs aufzubrechen. Websites, die so groß wie eBay und Amazon sind, werden jeweils in verschiedenen Rechenzentren mit einer großen Anzahl von Internetverbindungen enthalten. Sie nehmen alles von Internet Pop Quest-West und senden es an die "Quest" -Server an die Westküste, alles von Att-West wird an die Westküsten-Datcenter "Att" -Server gesendet, alles von Quest-East und es geht an es zu einem Die "Quest" -Server usw. Die Ostküsten -Rechenzentrum -Server usw. Jedes dieser Systeme könnten eine Insel sein, die ein einzelner Lastausgleich sein kann, der die Ladung bewältigen kann. Einige der Lastballerer können dort Hunderttausende von Transaktionen pro Sekunde verschlüsseln. Auf der Rückseite replizieren Sie ständig in loser Schüttung zu jedem Rechenzentrum, aber es kann nicht synchronisiert sein.

Ich weiß nicht, wie sie es machen, aber hier sind einige Vorschläge:

  • Verwenden Sie Round-Robin-DNs oder, um einen Überlastung eines Hostbalancer-Hosts selbst zu vermeiden oder
  • Umleiten Sie verschiedene Clients auf unterschiedliche Clusteradressen basierend auf Last, Einstellungen, Geolokalisierung usw. um

Um die Mitte der Last zu verteilen,

  • Einbetten Sie die ID des Session -Servers der mittleren Stufe in das Sitzungs -ID -Cookie ein - wie andere vorgeschlagen haben. Auf diese Weise, die von Ihnen geschlagene Front-End-Box ist, ist sie irrelevant, sie können ohne Auswirkungen hinzugefügt/entfernt werden.
  • Wenn es ausreichend wichtig ist, haben Sie einen Mechanismus, um Clients während einer Sitzung zu einem alternativen Mittelstufer -Server umzuleiten, damit man für die Wartung abgenommen werden kann usw.
  • Clients verwenden einen neu beauftragten Middle Tier -Server beim Starten einer neuen Sitzung

So verteilen Sie die Datenbanklast zurück

  • "Konventionelle" Sharding von "Echtzeit" -Ankonzus- oder pro-Benutzer-Daten
  • Asynchron replizieren langsam verändernde oder relativ statische Daten; Benutzer konnten es veraltet sehen (aber nicht die meiste Zeit nicht viel). Mittelstufe und Webserver stellen eine Verbindung zu einer Datenbank, die lokal zu ihrem eigenen Standort vorliegt
Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top