Hinweis: Dieser Beitrag ist veraltet. Die aktuellste Version finden Sie hier.
Dieser Beitrag ist veraltet. Die aktualisierte Version finden Sie hier. Ich verlasse diesen Artikel absichtlich hier, damit ich andere Websites, die auf mich verweisen, nicht störe.
Vor einigen Jahren war es einfach, Leistung in ein Softwaresystem zu integrieren – Sie haben entweder Ihre Hardwareressourcen erhöht (Skalierung) oder Ihre Anwendung geändert, um effizienter zu arbeiten (Leistungsoptimierung). Heute gibt es eine dritte Option: horizontale Skalierung (Scale out).
Die horizontale Skalierung von Softwaresystemen ist in den letzten Jahren aufgrund der globalen Natur des Computing und der ständig steigenden Leistungsanforderungen an Anwendungen notwendig geworden. In vielen Fällen ist es nicht mehr akzeptabel, einen einzelnen Server mit einer einzigen Datenbank in einem einzigen Rechenzentrum neben dem Hauptsitz Ihres Unternehmens zu betreiben. Wir brauchen wirklich verteilte Umgebungen, um die geschäftlichen Herausforderungen von heute zu bewältigen.
Leider sind die Leistungsvorteile der horizontalen Skalierung mit Kosten verbunden – Komplexität. Verteilte Systeme führen viel mehr Faktoren in die Leistungsgleichung ein als zuvor. Datensätze variieren zwischen Clients / Knoten an verschiedenen Standorten. Einzelne Fehlerpunkte zerstören die Systemverfügbarkeit, und intermittierende Netzwerkprobleme schleichen sich zum ungünstigsten Zeitpunkt ein.
Diese Bedenken hinsichtlich Konsistenz (C), Verfügbarkeit (A) und Partitionstoleranz (P) in verteilten Systemen machen das aus, was ~~ Eric Brewer ~~ als CAP-Theorem geprägt hat. Einfach ausgedrückt zeigt das CAP-Theorem, dass jedes verteilte System C, A und P nicht gleichzeitig garantieren kann, sondern Kompromisse zu einem bestimmten Zeitpunkt eingehen muss, um das für eine bestimmte Aufgabe erforderliche Leistungs- und Verfügbarkeitsniveau zu erreichen.
Konsistenz – Alle Knoten sehen die gleichen Daten zur gleichen Zeit.
Einfach ausgedrückt gibt das Ausführen einer Leseoperation den Wert der letzten Schreiboperation zurück, wodurch alle Knoten dieselben Daten zurückgeben. Ein System hat Konsistenz, wenn eine Transaktion mit dem System in einem konsistenten Zustand beginnt und mit dem System in einem konsistenten Zustand endet. In diesem Modell kann (und wird) ein System während einer Transaktion in einen inkonsistenten Zustand versetzt, aber die gesamte Transaktion wird zurückgesetzt, wenn in einer Phase des Prozesses ein Fehler auftritt.
Typische relationale Datenbanken sind konsistent: SQL Server, MySQL und PostgreSQL.
Verfügbarkeit – Jede Anfrage erhält eine Antwort auf Erfolg / Misserfolg.
Um Verfügbarkeit in einem verteilten System zu erreichen, muss das System 100% der Zeit betriebsbereit bleiben. Jeder Client erhält eine Antwort, unabhängig vom Status eines einzelnen Knotens im System. Diese Metrik ist trivial zu messen: Entweder können Sie Lese- / Schreibbefehle senden oder nicht.
Typische relationale Datenbanken sind ebenfalls verfügbar: SQL Server, MySQL und PostgreSQL. Dies bedeutet, dass relationale Datenbanken im CA-Bereich vorhanden sind – Konsistenz und Verfügbarkeit. CA ist jedoch nicht nur relationalen Datenbanken vorbehalten – auch einige dokumentorientierte Tools wie ElasticSearch fallen unter das Dach von CA.
Partitionstoleranz – System funktioniert trotz Nachrichtenverlust oder partiellem Ausfall weiter.
Die meisten Menschen betrachten ihren Datenspeicher als einen einzigen Knoten im Netzwerk. „Dies ist unsere Produktions-SQL Server-Instanz“. Wer eine Produktionsinstanz länger als vier Minuten laufen lässt, merkt schnell, dass dadurch ein Single Point of Failure entsteht. Ein partitionstolerantes System kann jede Menge Netzwerkfehler aushalten, die nicht zu einem Ausfall des gesamten Netzwerks führen. Datensätze werden über Kombinationen von Knoten und Netzwerken hinweg ausreichend repliziert, um das System durch intermittierende Ausfälle aufrechtzuerhalten.
Speichersysteme, die unter Partitionstoleranz mit Konsistenz (CP) fallen: MongoDB, Redis, AppFabric-Caching und MemcacheDB. CP-Systeme eignen sich hervorragend für verteilte Caches, da jeder Client die gleichen Daten erhält und das System über Netzwerkgrenzen hinweg partitioniert ist.
Speichersysteme, die unter Partitionstoleranz mit Verfügbarkeit (AP) fallen, umfassen DynamoDB, CouchDB und Cassandra.
Fazit
Verteilte Systeme ermöglichen es uns, ein Maß an Rechenleistung und Verfügbarkeit zu erreichen, das in früheren Jahren einfach nicht verfügbar war. Unsere Systeme haben eine höhere Leistung, eine geringere Latenz und eine Verfügbarkeit von nahezu 100% in Rechenzentren, die sich über den gesamten Globus erstrecken. Das Beste von allem ist, dass die Systeme von heute auf Standardhardware laufen, die leicht erhältlich und konfigurierbar ist und Kosten verursacht, die sich $ 0 nähern.
All diese Rechenleistung und Vorteile haben jedoch ihren Preis. Verteilte Systeme sind komplexer als ihre Pendants in einem Netzwerk. Es gibt viele weitere Tools und Fähigkeiten, die erworben werden müssen, um ein wirklich skalierbares, leistungsstarkes System zu erstellen. Die Komplexität verteilter Systeme zu verstehen, die entsprechenden Kompromisse für die jeweilige Aufgabe (CAP) einzugehen und das richtige Werkzeug für den Job auszuwählen, sind alles wichtige Fähigkeiten in einer Welt, in der Computersysteme aus- und nicht aufsteigen.
