Eine gründliche Einführung in verteilte Systeme

Was ist ein verteiltes System und warum ist es so kompliziert?

Mit der stetig wachsenden technologischen Expansion der Welt werden verteilte Systeme immer weiter verbreitet. Sie sind ein weites und komplexes Studienfach in der Informatik.

Dieser Artikel soll Sie auf grundlegende Weise in verteilte Systeme einführen und Ihnen einen Einblick in die verschiedenen Kategorien solcher Systeme geben, ohne tief in die Details einzutauchen.

Was ist ein verteiltes System?

Ein verteiltes System in seiner einfachsten Definition ist eine Gruppe von Computern, die zusammenarbeiten, um dem Endbenutzer als ein einziger Computer zu erscheinen.

Diese Maschinen haben einen gemeinsamen Status, arbeiten gleichzeitig und können unabhängig voneinander ausfallen, ohne die Betriebszeit des gesamten Systems zu beeinträchtigen.

Ich schlage vor, wir arbeiten schrittweise an einem Beispiel für die Verteilung eines Systems, damit Sie ein besseres Gefühl dafür bekommen:

Lass uns mit einer Datenbank gehen! Herkömmliche Datenbanken werden im Dateisystem eines einzelnen Computers gespeichert, wenn Sie Informationen abrufen / einfügen möchten - Sie sprechen direkt mit diesem Computer.

Damit wir dieses Datenbanksystem verteilen können, muss diese Datenbank auf mehreren Computern gleichzeitig ausgeführt werden. Der Benutzer muss in der Lage sein, mit dem von ihm ausgewählten Computer zu sprechen, und sollte nicht erkennen können, dass er nicht mit einem einzelnen Computer spricht. Wenn er einen Datensatz in Knoten 1 einfügt, muss Knoten 3 diesen Datensatz zurückgeben können.

Warum ein System vertreiben?

Systeme werden immer nach Bedarf verteilt. Die Wahrheit ist, dass die Verwaltung verteilter Systeme ein komplexes Thema ist, das voller Fallstricke und Landminen steckt. Das Bereitstellen, Warten und Debuggen verteilter Systeme bereitet Kopfschmerzen. Warum also überhaupt dorthin gehen?

Mit einem verteilten System können Sie horizontal skalieren . Zurück zu unserem vorherigen Beispiel für den einzelnen Datenbankserver: Die einzige Möglichkeit, mehr Datenverkehr zu verarbeiten, besteht darin, die Hardware zu aktualisieren, auf der die Datenbank ausgeführt wird. Dies wird als vertikale Skalierung bezeichnet .

Vertikales Skalieren ist gut und schön, solange Sie können, aber nach einem bestimmten Punkt werden Sie feststellen, dass selbst die beste Hardware nicht für genügend Datenverkehr ausreicht, ganz zu schweigen davon, dass dies für den Host unpraktisch ist.

Horizontale Skalierung bedeutet einfach, mehr Computer hinzuzufügen, anstatt die Hardware eines einzelnen zu aktualisieren.

Es ist deutlich billiger als die vertikale Skalierung nach einem bestimmten Schwellenwert, aber das ist nicht der Hauptfall für die Präferenz.

Die vertikale Skalierung kann Ihre Leistung nur auf die neuesten Hardwarefunktionen bringen. Diese Fähigkeiten erweisen sich für Technologieunternehmen mit mittlerer bis hoher Arbeitsbelastung als unzureichend .

Das Beste an der horizontalen Skalierung ist, dass Sie keine Begrenzung für die Skalierbarkeit haben. Wenn sich die Leistung verschlechtert, fügen Sie einfach eine weitere Maschine hinzu, möglicherweise bis zu unendlich.

Einfache Skalierung ist nicht der einzige Vorteil, den Sie von verteilten Systemen erhalten. Ebenso wichtig sind Fehlertoleranz und geringe Latenz .

Fehlertoleranz - Ein Cluster von zehn Computern in zwei Rechenzentren ist von Natur aus fehlertoleranter als ein einzelner Computer. Selbst wenn ein Rechenzentrum in Brand gerät, funktioniert Ihre Anwendung weiterhin.

Geringe Latenz - Die Zeit, die ein Netzwerkpaket benötigt, um die Welt zu bereisen, ist physisch durch die Lichtgeschwindigkeit begrenzt. Zum Beispiel ist die kürzestmögliche Zeit für eine Anfrage Umlaufzeit (das heißt, geht hin und her) in einem Glasfaserkabel zwischen New York nach Sydney ist 160ms. Mit verteilten Systemen können Sie in beiden Städten einen Knoten haben, sodass der Datenverkehr auf den Knoten trifft, der ihm am nächsten liegt.

Damit ein verteiltes System funktioniert, muss die auf diesen Computern ausgeführte Software speziell dafür ausgelegt sein, auf mehreren Computern gleichzeitig ausgeführt zu werden und die damit verbundenen Probleme zu lösen. Dies stellt sich als keine leichte Aufgabe heraus.

Skalierung unserer Datenbank

Stellen Sie sich vor, unsere Webanwendung wurde wahnsinnig beliebt. Stellen Sie sich außerdem vor, dass unsere Datenbank doppelt so viele Abfragen pro Sekunde erhält, wie sie verarbeiten kann. Ihre Anwendung würde sofort an Leistung verlieren und dies würde von Ihren Benutzern bemerkt werden.

Lassen Sie uns zusammenarbeiten und unsere Datenbank skalieren, um unseren hohen Anforderungen gerecht zu werden.

In einer typischen Webanwendung lesen Sie Informationen normalerweise viel häufiger als Sie neue Informationen einfügen oder alte ändern.

Es gibt eine Möglichkeit, die Leseleistung zu steigern, und zwar durch die sogenannte Primary-Replica-Replikationsstrategie . Hier erstellen Sie zwei neue Datenbankserver, die mit dem Hauptserver synchronisiert werden. Der Haken ist, dass Sie nur von diesen neuen Instanzen lesen können .

Wann immer Sie Informationen einfügen oder ändern, sprechen Sie mit der Primärdatenbank. Es wiederum informiert die Replikate asynchron über die Änderung und sie speichern sie ebenfalls.

Herzlichen Glückwunsch, Sie können jetzt dreimal so viele Leseabfragen ausführen! Ist das nicht toll?

Falle

Erwischt! Wir haben sofort das C in den ACID- Garantien unserer relationalen Datenbank verloren , was für Konsistenz steht.

Sie sehen, es gibt jetzt eine Möglichkeit, in der wir einen neuen Datensatz in die Datenbank einfügen, unmittelbar danach eine Leseabfrage dafür ausgeben und nichts zurückbekommen, als ob er nicht existiert hätte!

Die Weitergabe der neuen Informationen vom primären zum Replikat erfolgt nicht sofort. Es gibt tatsächlich ein Zeitfenster, in dem Sie veraltete Informationen abrufen können. Wenn dies nicht der Fall wäre, würde Ihre Schreibleistung darunter leiden, da synchron auf die Weitergabe der Daten gewartet werden müsste.

Verteilte Systeme weisen eine Handvoll Kompromisse auf. Mit diesem speziellen Problem müssen Sie leben, wenn Sie angemessen skalieren möchten.

Weiter zur Skalierung

Mit dem Replikatdatenbank-Ansatz können wir unseren Leseverkehr bis zu einem gewissen Grad horizontal skalieren. Das ist großartig, aber wir haben in Bezug auf unseren Schreibverkehr eine Mauer getroffen - es ist immer noch alles auf einem Server!

Wir haben hier nicht viele Optionen. Wir müssen lediglich unseren Schreibverkehr in mehrere Server aufteilen, da einer nicht in der Lage ist, damit umzugehen.

Eine Möglichkeit besteht darin, eine Multi-Primär-Replikationsstrategie zu wählen. Dort haben Sie anstelle von Replikaten, von denen Sie nur lesen können, mehrere Primärknoten, die Lese- und Schreibvorgänge unterstützen. Leider wird dies sehr schnell kompliziert, da Sie jetzt Konflikte erstellen können (z. B. zwei Datensätze mit derselben ID einfügen).

Gehen wir mit einer anderen Technik namens Sharding(auch Partitionierung genannt ).

Mit Sharding teilen Sie Ihren Server in mehrere kleinere Server auf, die als Shards bezeichnet werden. Diese Shards enthalten alle unterschiedliche Datensätze. Sie erstellen eine Regel, welche Art von Datensätzen in welchen Shard aufgenommen werden. Es ist sehr wichtig, die Regel so zu erstellen, dass die Daten gleichmäßig verteilt werden .

Ein möglicher Ansatz hierfür besteht darin, Bereiche gemäß einigen Informationen zu einem Datensatz zu definieren (z. B. Benutzer mit dem Namen AD).

Dieser Sharding-Schlüssel sollte sehr sorgfältig ausgewählt werden, da die Last aufgrund beliebiger Spalten nicht immer gleich ist. (zB haben mehr Leute einen Namen, der mit C anstatt mit Z beginnt ). Ein einzelner Shard, der mehr Anfragen als andere empfängt, wird als Hot Spot bezeichnet und muss vermieden werden. Nach dem Aufteilen wird das erneute Sharding von Daten unglaublich teuer und kann zu erheblichen Ausfallzeiten führen, wie dies bei FourSquares berüchtigtem 11-Stunden-Ausfall der Fall war.

Um unser Beispiel einfach zu halten, nehmen wir an, dass unser Client (die Rails-App) weiß, welche Datenbank für jeden Datensatz verwendet werden soll. Es ist auch erwähnenswert, dass es viele Strategien zum Scherben gibt, und dies ist ein einfaches Beispiel, um das Konzept zu veranschaulichen.

Wir haben im Moment ziemlich viel gewonnen - wir können unseren Schreibverkehr N- mal erhöhen, wobei N die Anzahl der Shards ist. Dies gibt uns praktisch keine Grenzen - stellen Sie sich vor, wie feinkörnig wir mit dieser Partitionierung werden können.

Falle

Alles in der Softwareentwicklung ist mehr oder weniger ein Kompromiss, und dies ist keine Ausnahme. Sharding ist keine einfache Aufgabe und wird am besten vermieden, bis es wirklich gebraucht wird.

Wir haben jetzt Abfragen nach Schlüsseln durchgeführtaußer dem partitionierten Schlüssel unglaublich ineffizient (sie müssen alle Shards durchlaufen). SQL- JOINAbfragen sind noch schlimmer und komplexe werden praktisch unbrauchbar.

Dezentral oder verteilt

Bevor wir weiter gehen, möchte ich zwischen den beiden Begriffen unterscheiden.

Obwohl die Wörter ähnlich klingen und logisch als gleichbedeutend angesehen werden können, hat ihr Unterschied erhebliche technologische und politische Auswirkungen.

Dezentrale noch verteilte im technischen Sinne, sondern die ganzen dezentralen Systeme werden nicht von einem Schauspieler gehört. Kein Unternehmen kann ein dezentrales System besitzen, sonst wäre es nicht mehr dezentralisiert.

Dies bedeutet, dass die meisten Systeme, auf die wir heute noch eingehen werden, als verteilte zentralisierte Systeme betrachtet werden können - und genau dafür sind sie gemacht.

Wenn Sie darüber nachdenken, ist es schwieriger, ein dezentrales System zu erstellen, da Sie dann den Fall behandeln müssen, in dem einige der Teilnehmer böswillig sind. Dies ist bei normalverteilten Systemen nicht der Fall, da Sie wissen, dass Sie alle Knoten besitzen.

Hinweis: Diese Definition wurde viel diskutiert und kann mit anderen (Peer-to-Peer, Verbund) verwechselt werden. In der frühen Literatur wurde es auch anders definiert. Unabhängig davon, was ich Ihnen als Definition gegeben habe, ist das, was meiner Meinung nach am weitesten verbreitet ist, seit Blockchain und Kryptowährungen den Begriff populär gemacht haben.

Verteilte Systemkategorien

Wir werden nun einige verteilte Systemkategorien durchgehen und ihre größte öffentlich bekannte Produktionsnutzung auflisten. Denken Sie daran, dass die meisten dieser angezeigten Zahlen veraltet sind und zum Zeitpunkt des Lesens höchstwahrscheinlich erheblich größer sind.

Verteilte Datenspeicher

Verteilte Datenspeicher werden am häufigsten als verteilte Datenbanken verwendet und anerkannt. Die meisten verteilten Datenbanken sind nicht relationale NoSQL-Datenbanken, die auf die Schlüsselwertsemantik beschränkt sind. Sie bieten eine unglaubliche Leistung und Skalierbarkeit auf Kosten der Konsistenz oder Verfügbarkeit.

Bekannte Skalierung - Apple verwendet bereits 2015 75.000 Apache Cassandra-Knoten, auf denen über 10 Petabyte Daten gespeichert sind

Wir können nicht auf verteilte Datenspeicher eingehen, ohne zuerst den CAP-Satz einzuführen .

CAP-Theorem

Das GAP-Theorem wurde bereits 2002 bewiesen und besagt, dass ein verteilter Datenspeicher nicht gleichzeitig konsistent, verfügbar und partitionstolerant sein kann.

Einige schnelle Definitionen:

  • Konsistenz - Was Sie nacheinander lesen und schreiben, wird erwartet (erinnern Sie sich an das Problem mit der Datenbankreplikation vor einigen Absätzen?)
  • Verfügbarkeit - das gesamte System stirbt nicht - jeder nicht fehlerhafte Knoten gibt immer eine Antwort zurück.
  • Partitionstolerant - Das System funktioniert trotz Netzwerkpartitionen weiterhin und behält seine Konsistenz- / Verfügbarkeitsgarantien bei

In der Realität muss die Partitionstoleranz für jeden verteilten Datenspeicher gegeben sein. Wie an vielen Stellen erwähnt, von denen einer dieser großartige Artikel ist, können Sie ohne Partitionstoleranz keine Konsistenz und Verfügbarkeit haben.

Denken Sie darüber nach: Wenn Sie zwei Knoten haben, die Informationen akzeptieren und deren Verbindung unterbrochen wird - wie werden beide verfügbar sein und Ihnen gleichzeitig Konsistenz bieten? Sie haben keine Möglichkeit zu wissen, was der andere Knoten tut, und können daher entweder offline (nicht verfügbar) oder mit veralteten Informationen (inkonsistent) arbeiten .

Am Ende können Sie entscheiden, ob Ihr System unter einer Netzwerkpartition stark konsistent oder hoch verfügbar sein soll .

Die Praxis zeigt, dass die meisten Anwendungen die Verfügbarkeit mehr schätzen. Sie brauchen nicht unbedingt immer eine starke Konsistenz. Selbst dann wird dieser Kompromiss nicht unbedingt gemacht, weil Sie die 100% ige Verfügbarkeitsgarantie benötigen, sondern weil die Netzwerklatenz ein Problem sein kann, wenn Maschinen synchronisiert werden müssen, um eine starke Konsistenz zu erzielen. Aufgrund dieser und weiterer Faktoren entscheiden sich Anwendungen in der Regel für Lösungen mit hoher Verfügbarkeit.

Solche Datenbanken haben das schwächste Konsistenzmodell - die eventuelle Konsistenz (Erklärung der starken vs. eventuellen Konsistenz) . Dieses Modell stellt sicher , dass , wenn kein neues Updates zu einem bestimmten Punkt gemacht werden, schließlich alle Zugriffe auf das Element wird den neuesten Wert zurück.

Diese Systeme bieten BASE- Eigenschaften (im Gegensatz zur ACID herkömmlicher Datenbanken).

  • B asisch A verfügbar - Das System gibt immer eine Antwort zurück
  • S oft state - Das System kann sich im Laufe der Zeit ändern, auch wenn keine Eingabe erfolgt (aufgrund eventueller Konsistenz).
  • E ventuale Konsistenz - Wenn keine Eingabe erfolgt, werden die Daten früher oder später auf jeden Knoten verteilt und somit konsistent

Beispiele für solche verfügbaren verteilten Datenbanken - Cassandra, Riak, Voldemort

Natürlich gibt es andere Datenspeicher, die eine stärkere Konsistenz bevorzugen - HBase, Couchbase, Redis, Zookeeper

Das CAP-Theorem verdient mehrere Artikel für sich - einige davon, wie Sie die CAP-Eigenschaften eines Systems anpassen können, je nachdem, wie sich der Client verhält, und andere, wie es nicht richtig verstanden wird.

Kassandra

Cassandra ist, wie oben erwähnt, eine verteilte No-SQL-Datenbank, die die AP-Eigenschaften aus der GAP bevorzugt und sich mit eventueller Konsistenz zufrieden gibt. Ich muss zugeben, dass dies etwas irreführend sein kann, da Cassandra in hohem Maße konfigurierbar ist - Sie können dafür sorgen, dass es auch auf Kosten der Verfügbarkeit eine starke Konsistenz bietet, aber das ist nicht der übliche Anwendungsfall.

Cassandra verwendet konsistentes Hashing, um zu bestimmen, welche Knoten aus Ihrem Cluster die von Ihnen übergebenen Daten verwalten müssen. Sie legen einen Replikationsfaktor fest , der im Wesentlichen angibt, wie viele Knoten Sie Ihre Daten replizieren möchten.

Beim Lesen lesen Sie nur von diesen Knoten.

Cassandra ist massiv skalierbar und bietet einen absurd hohen Schreibdurchsatz.

Auch wenn dieses Diagramm möglicherweise voreingenommen ist und Cassandra anscheinend mit Datenbanken vergleicht, die so eingestellt sind, dass sie eine starke Konsistenz bieten (ansonsten kann ich nicht erkennen, warum MongoDB die Leistung beim Upgrade von 4 auf 8 Knoten verringert), sollte dies dennoch zeigen, was für eine ordnungsgemäße Einstellung bis Cassandra Cluster ist in der Lage.

Unabhängig davon bietet Cassandra im Kompromiss zwischen verteilten Systemen, der eine horizontale Skalierung und einen unglaublich hohen Durchsatz ermöglicht, einige grundlegende Funktionen von ACID-Datenbanken nicht - nämlich Transaktionen.

Konsens

Datenbanktransaktionen sind in verteilten Systemen schwierig zu implementieren, da jeder Knoten die richtigen Maßnahmen (Abbruch oder Festschreiben) vereinbaren muss. Dies ist als Konsens bekannt und ein grundlegendes Problem in verteilten Systemen.

Das Erreichen der Art der Vereinbarung, die für das Problem des „Transaktions-Commits“ erforderlich ist, ist unkompliziert, wenn die beteiligten Prozesse und das Netzwerk vollständig zuverlässig sind. Reale Systeme sind jedoch einer Reihe möglicher Fehler ausgesetzt, z. B. Prozessabstürze, Netzwerkpartitionierung sowie verlorene, verzerrte oder doppelte Nachrichten.

Dies wirft ein Problem auf - es hat sich als unmöglich erwiesen, zu gewährleisten, dass innerhalb eines begrenzten Zeitrahmens in einem nicht zuverlässigen Netzwerk ein korrekter Konsens erzielt wird.

In der Praxis gibt es jedoch Algorithmen, die ziemlich schnell einen Konsens über ein nicht zuverlässiges Netzwerk erzielen. Cassandra bietet tatsächlich einfache Transaktionen mithilfe des Paxos-Algorithmus für verteilten Konsens.

Verteiltes Rechnen

Distributed Computing ist der Schlüssel zum Zustrom von Big Data-Verarbeitung, den wir in den letzten Jahren gesehen haben. Es ist die Technik, eine enorme Aufgabe (z. B. insgesamt 100 Milliarden Datensätze), von der kein einzelner Computer praktisch alleine ausgeführt werden kann, in viele kleinere Aufgaben aufzuteilen, von denen jede in eine einzelne Warenmaschine passen kann. Sie teilen Ihre große Aufgabe in viele kleinere auf, lassen sie parallel auf vielen Computern ausführen, aggregieren die Daten entsprechend und haben Ihr ursprüngliches Problem gelöst. Mit diesem Ansatz können Sie wieder horizontal skalieren. Wenn Sie eine größere Aufgabe haben, nehmen Sie einfach mehr Knoten in die Berechnung auf.

Bekannte Skala - Folding @ Home hatte 2012 160.000 aktive Maschinen

Ein früher Innovator in diesem Bereich war Google, das aufgrund seiner großen Datenmengen ein neues Paradigma für verteilte Berechnungen erfinden musste - MapReduce. Sie veröffentlichten 2004 ein Papier darüber und die Open-Source-Community schuf später Apache Hadoop darauf basierend.

Karte verkleinern

MapReduce kann einfach in zwei Schritten definiert werden: Zuordnen der Daten und Reduzieren auf etwas Sinnvolles.

Lassen Sie uns noch einmal mit einem Beispiel darauf eingehen:

Angenommen, wir sind mittelgroß und haben unsere enormen Informationen zu Lagerzwecken in einer sekundären verteilten Datenbank gespeichert. Wir möchten Daten abrufen, die die Anzahl der Klatschen darstellen, die im April 2017 (vor einem Jahr) täglich ausgegeben wurden.

Dieses Beispiel ist so kurz, klar und einfach wie möglich gehalten. Stellen Sie sich jedoch vor, wir arbeiten mit einer Vielzahl von Daten (z. B. der Analyse von Milliarden von Klatschen). Wir werden offensichtlich nicht alle diese Informationen auf einem Computer speichern und dies alles nicht mit nur einem Computer analysieren. Wir werden auch nicht die Produktionsdatenbank abfragen, sondern eine "Lager" -Datenbank, die speziell für Offline-Jobs mit niedriger Priorität erstellt wurde.

Jeder Map-Job ist ein separater Knoten, der so viele Daten wie möglich transformiert. Jeder Job durchläuft alle Daten im angegebenen Speicherknoten und ordnet sie einem einfachen Tupel aus Datum und Nummer eins zu. Dann werden drei Zwischenschritte ausgeführt (über die niemand spricht) - Mischen, Sortieren und Partitionieren. Grundsätzlich ordnen sie die Daten weiter an und löschen sie an den entsprechenden Reduzierungsjob. Da es sich um Big Data handelt, wird jeder Reduce-Job getrennt, um nur an einem einzigen Datum zu arbeiten.

Dies ist ein gutes Paradigma und ermöglicht es Ihnen überraschenderweise, viel damit zu tun - Sie können beispielsweise mehrere MapReduce-Jobs verketten.

Bessere Techniken

MapReduce ist heutzutage ein Vermächtnis und bringt einige Probleme mit sich. Da es in Stapeln (Jobs) funktioniert, tritt ein Problem auf, bei dem Sie das Ganze neu starten müssen, wenn Ihr Job fehlschlägt. Ein 2-Stunden-Jobfehler kann Ihre gesamte Datenverarbeitungs-Pipeline wirklich verlangsamen, und Sie möchten dies nicht im Geringsten, insbesondere in Spitzenzeiten.

Ein weiteres Problem ist die Zeit, die Sie warten, bis Sie Ergebnisse erhalten. In Echtzeit-Analysesystemen (die alle über Big Data verfügen und daher verteiltes Computing verwenden) ist es wichtig, dass Ihre neuesten Daten so aktuell wie möglich sind und sicherlich nicht vor einigen Stunden.

Als solche sind andere Architekturen entstanden, die diese Probleme angehen. Nämlich Lambda-Architektur (Mischung aus Stapelverarbeitung und Stream-Verarbeitung) und Kappa-Architektur (nur Stream-Verarbeitung). Diese Fortschritte auf diesem Gebiet haben neue Tools mit sich gebracht, die sie ermöglichen - Kafka Streams, Apache Spark, Apache Storm und Apache Samza.

Verteilte Dateisysteme

Verteilte Dateisysteme können als verteilte Datenspeicher betrachtet werden. Sie sind dasselbe wie ein Konzept - Speichern und Zugreifen auf eine große Datenmenge in einem Cluster von Maschinen, die alle als eine Einheit angezeigt werden. Sie gehen in der Regel Hand in Hand mit Distributed Computing.

Bekannte Skalierung - Yahoo ist bekannt dafür, dass HDFS bereits 201 auf über 42.000 Knoten ausgeführt wurde, um 600 Petabyte Daten zu speichern

Wikipedia definiert den Unterschied darin, dass verteilte Dateisysteme den Zugriff auf Dateien über dieselben Schnittstellen und dieselbe Semantik wie lokale Dateien ermöglichen, nicht über eine benutzerdefinierte API wie die Cassandra Query Language (CQL).

HDFS

Hadoop Distributed File System (HDFS) ist das verteilte Dateisystem, das für verteiltes Computing über das Hadoop-Framework verwendet wird. Es ist weit verbreitet und wird zum Speichern und Replizieren großer Dateien (GB oder TB) auf vielen Computern verwendet.

Die Architektur besteht hauptsächlich aus NameNodes und DataNodes . NameNodes sind dafür verantwortlich, Metadaten über den Cluster zu speichern, z. B. welcher Knoten welche Dateiblöcke enthält. Sie fungieren als Koordinatoren für das Netzwerk, indem sie herausfinden, wo Dateien am besten gespeichert und repliziert werden können, und den Systemzustand verfolgen. DataNodes speichern einfach Dateien und führen Befehle wie das Replizieren einer Datei, das Schreiben einer neuen und andere aus.

Es überrascht nicht, dass HDFS am besten mit Hadoop für die Berechnung verwendet wird, da es den Rechenjobs Datenbewusstsein verleiht. Diese Jobs werden dann auf den Knoten ausgeführt, auf denen die Daten gespeichert sind. Dies nutzt die Datenlokalität - optimiert die Berechnungen und reduziert den Datenverkehr über das Netzwerk.

IPFS

Das Interplanetary File System (IPFS) ist ein aufregendes neues Peer-to-Peer-Protokoll / Netzwerk für ein verteiltes Dateisystem. Dank der Blockchain-Technologie verfügt es über eine vollständig dezentrale Architektur ohne einzelnen Eigentümer und ohne Fehlerquelle.

IPFS bietet ein Namenssystem (ähnlich wie DNS) namens IPNS und ermöglicht Benutzern den einfachen Zugriff auf Informationen. Es speichert Dateien über die historische Versionierung, ähnlich wie Git. Dies ermöglicht den Zugriff auf alle vorherigen Zustände einer Datei.

Es befindet sich noch in einer intensiven Entwicklung (v0.4 zum Zeitpunkt des Schreibens), hat jedoch bereits Projekte gesehen, die daran interessiert sind, darüber aufzubauen (FileCoin).

Verteiltes Messaging

Messaging-Systeme bieten einen zentralen Ort für die Speicherung und Weitergabe von Nachrichten / Ereignissen in Ihrem Gesamtsystem. Mit ihnen können Sie Ihre Anwendungslogik vom direkten Gespräch mit Ihren anderen Systemen entkoppeln.

Bekannte Skala - Der Kafka-Cluster von LinkedIn verarbeitete täglich 1 Billion Nachrichten mit Spitzenwerten von 4,5 Millionen Nachrichten pro Sekunde.

Einfach ausgedrückt funktioniert eine Messaging-Plattform folgendermaßen:

Eine Nachricht wird von der Anwendung gesendet, die sie möglicherweise erstellt (als Produzent bezeichnet ), auf die Plattform gelangt und von potenziell mehreren Anwendungen gelesen, die daran interessiert sind (als Verbraucher bezeichnet ).

Wenn Sie ein bestimmtes Ereignis an einigen Stellen speichern müssen (z. B. Benutzererstellung in Datenbank, Lager, E-Mail-Versanddienst und was auch immer Sie sonst noch tun können), ist eine Messaging-Plattform der sauberste Weg, um diese Nachricht zu verbreiten.

Verbraucher können entweder Informationen aus den Brokern abrufen (Pull-Modell) oder die Broker Informationen direkt in die Verbraucher übertragen lassen (Push-Modell).

Es gibt einige beliebte erstklassige Messaging-Plattformen:

RabbitMQ - Nachrichtenbroker, mit dem Sie die Nachrichtenverläufe über Routing-Regeln und andere leicht konfigurierbare Einstellungen genauer steuern können. Kann als intelligenter Broker bezeichnet werden, da er eine Menge Logik enthält und die Nachrichten, die ihn durchlaufen, genau verfolgt. Bietet Einstellungen für AP und CP aus CAP . Verwendet ein Push-Modell zur Benachrichtigung der Verbraucher.

Kafka - Message Broker (und die gesamte Plattform), der etwas niedriger ist, da er nicht nachverfolgt, welche Nachrichten gelesen wurden, und keine komplexe Routing-Logik zulässt. Dies hilft ihm, eine erstaunliche Leistung zu erzielen. Meiner Meinung nach ist dies die größte Perspektive in diesem Bereich mit aktiver Entwicklung durch die Open-Source-Community und Unterstützung durch das Confluent-Team. Kafka wird wohl am häufigsten von Top-Tech-Unternehmen eingesetzt. Ich habe eine gründliche Einführung dazu geschrieben, in der ich auf all seine Güte eingehen werde.

Apache ActiveMQ - Das älteste der Reihe aus dem Jahr 2004. Verwendet die JMS-API, dh sie ist auf Java EE-Anwendungen ausgerichtet. Es wurde als ActiveMQ Artemis umgeschrieben, das eine herausragende Leistung auf dem Niveau von Kafka bietet.

Amazon SQS - Ein von AWS bereitgestellter Messaging-Dienst. Ermöglicht die schnelle Integration in vorhandene Anwendungen und macht die Verwaltung Ihrer eigenen Infrastruktur überflüssig, was ein großer Vorteil sein kann, da die Einrichtung von Systemen wie Kafka bekanntermaßen schwierig ist. Amazon bietet auch zwei ähnliche Dienste an - SNS und MQ, wobei letzterer im Wesentlichen ActiveMQ ist, aber von Amazon verwaltet wird.

Verteilte Anwendungen

Wenn Sie 5 Rails-Server hinter einem einzelnen Load Balancer zusammenfassen, die alle mit einer Datenbank verbunden sind, können Sie dies als verteilte Anwendung bezeichnen? Erinnern Sie sich an meine Definition von oben:

Ein verteiltes System ist eine Gruppe von Computern, die zusammenarbeiten, um dem Endbenutzer als ein einziger Computer angezeigt zu werden. Diese Maschinen haben einen gemeinsamen Status, arbeiten gleichzeitig und können unabhängig voneinander ausfallen, ohne die Betriebszeit des gesamten Systems zu beeinträchtigen.

Wenn Sie die Datenbank als gemeinsam genutzten Status zählen, können Sie argumentieren, dass dies als verteiltes System klassifiziert werden kann - aber Sie würden sich irren, da Sie den Teil „ Zusammenarbeiten “ der Definition verpasst haben .

Ein System wird nur verteilt, wenn die Knoten miteinander kommunizieren, um ihre Aktionen zu koordinieren.

Daher kann so etwas wie eine Anwendung, die ihren Back-End-Code in einem Peer-to-Peer-Netzwerk ausführt, besser als verteilte Anwendung klassifiziert werden. Unabhängig davon ist dies alles eine unnötige Klassifizierung, die keinen Zweck erfüllt, sondern zeigt, wie pingelig wir sind, Dinge zusammenzufassen.

Bekannte Skala - BitTorrent-Schwarm von 193.000 Knoten für eine Episode von Game of Thrones, April 2014

Erlang Virtual Machine

Erlang ist eine funktionale Sprache mit einer hervorragenden Semantik für Parallelität, Verteilung und Fehlertoleranz. Die Erlang Virtual Machine selbst übernimmt die Verteilung einer Erlang-Anwendung.

Das Modell verfügt über viele isolierte Lightweight-Prozesse, die alle über ein integriertes System zur Nachrichtenübermittlung miteinander kommunizieren können. Dies wird als Akteurmodell bezeichnetund die Erlang OTP-Bibliotheken können als verteiltes Akteur-Framework betrachtet werden (nach dem Vorbild von Akka für die JVM).

Das Modell hilft dabei, eine große Parallelität zu erreichen - die Prozesse sind auf die verfügbaren Kerne des Systems verteilt, auf dem sie ausgeführt werden. Da dies nicht von einer Netzwerkeinstellung zu unterscheiden ist (abgesehen von der Möglichkeit, Nachrichten zu löschen), kann die Erlang-VM eine Verbindung zu anderen Erlang-VMs herstellen, die im selben Rechenzentrum oder sogar auf einem anderen Kontinent ausgeführt werden. Dieser Schwarm virtueller Maschinen führt eine einzelne Anwendung aus und behandelt Maschinenausfälle über die Übernahme (die Ausführung eines anderen Knotens wird geplant).

Tatsächlich wurde die verteilte Schicht der Sprache hinzugefügt, um Fehlertoleranz bereitzustellen. Bei Software, die auf einem einzelnen Computer ausgeführt wird, besteht immer das Risiko, dass dieser einzelne Computer stirbt und Ihre Anwendung offline geschaltet wird. Software, die auf vielen Knoten ausgeführt wird, ermöglicht eine einfachere Behandlung von Hardwarefehlern, sofern die Anwendung unter diesem Gesichtspunkt erstellt wurde.

BitTorrent

BitTorrent ist eines der am häufigsten verwendeten Protokolle für die Übertragung großer Dateien über das Internet über Torrents. Die Hauptidee besteht darin, die Dateiübertragung zwischen verschiedenen Peers im Netzwerk zu erleichtern, ohne einen Hauptserver durchlaufen zu müssen.

Mit einem BitTorrent-Client stellen Sie eine Verbindung zu mehreren Computern auf der ganzen Welt her, um eine Datei herunterzuladen. Wenn Sie eine Torrent-Datei öffnen, stellen Sie eine Verbindung zu einem sogenannten Tracker her , einem Computer, der als Koordinator fungiert. Es hilft bei der Peer-Erkennung und zeigt Ihnen die Knoten im Netzwerk, die die gewünschte Datei haben.

Sie haben die Vorstellung von zwei Benutzertypen, einem Blutegel und einem Sämaschinen . Ein Blutegel ist der Benutzer, der eine Datei herunterlädt, und ein Seeder ist der Benutzer, der diese Datei hochlädt.

Das Lustige an Peer-to-Peer-Netzwerken ist, dass Sie als normaler Benutzer die Möglichkeit haben, dem Netzwerk beizutreten und einen Beitrag dazu zu leisten.

Mit BitTorrent und seinen Vorläufern (Gnutella, Napster) können Sie freiwillig Dateien hosten und auf andere Benutzer hochladen, die sie möchten. Der Grund, warum BitTorrent so beliebt ist, ist, dass es das erste seiner Art war, das Anreize für einen Beitrag zum Netzwerk bot. Freeriding , bei dem ein Benutzer nur Dateien herunterladen würde, war ein Problem mit den vorherigen Dateifreigabeprotokollen.

BitTorrent löste das Freeriden bis zu einem gewissen Grad, indem Seeders mehr zu denen hochgeladen wurden, die die besten Download-Raten bieten. Es funktioniert, indem es Sie zum Hochladen anregt, während Sie eine Datei herunterladen. Nachdem Sie fertig sind, bleiben Sie leider durch nichts im Netzwerk aktiv. Dies führt zu einem Mangel an Seedern im Netzwerk, die über die vollständige Datei verfügen, und da das Protokoll stark von solchen Benutzern abhängt, wurden Lösungen wie private Tracker zum Tragen gebracht. Bei privaten Trackern müssen Sie Mitglied einer Community sein (häufig nur auf Einladung), um am verteilten Netzwerk teilnehmen zu können.

Nach Fortschritten auf diesem Gebiet wurden verfolgerlose Torrents erfunden. Dies war ein Upgrade des BitTorrent-Protokolls, bei dem keine zentralen Tracker zum Sammeln von Metadaten und zum Auffinden von Peers verwendet wurden, sondern stattdessen neue Algorithmen verwendet wurden. Eine solche Instanz ist Kademlia (Mainline DHT), eine verteilte Hash-Tabelle (DHT), mit der Sie Peers über andere Peers finden können. Tatsächlich führt jeder Benutzer die Aufgaben eines Trackers aus.

Verteilte Ledger

Ein verteiltes Ledger kann als unveränderliche Datenbank nur zum Anhängen betrachtet werden, die repliziert, synchronisiert und von allen Knoten im verteilten Netzwerk gemeinsam genutzt wird.

Bekannte Größenordnung - Ethereum Network verzeichnete am 4. Januar 2018 einen Höchststand von 1,3 Millionen Transaktionen pro Tag.

Sie nutzen das Ereignisbeschaffungsmuster und ermöglichen es Ihnen, den Status des Hauptbuchs jederzeit in seinem Verlauf wiederherzustellen.

Blockchain

Blockchain ist die derzeit zugrunde liegende Technologie, die für verteilte Hauptbücher verwendet wird und deren Start markiert ist. Diese neueste und größte Innovation im verteilten Bereich ermöglichte die Erstellung des ersten wirklich verteilten Zahlungsprotokolls - Bitcoin.

Blockchain ist ein verteiltes Hauptbuch mit einer geordneten Liste aller Transaktionen, die jemals in seinem Netzwerk stattgefunden haben. Transaktionen werden gruppiert und in Blöcken gespeichert. Die gesamte Blockchain ist im Wesentlichen eine verknüpfte Liste von Blöcken (daher der Name) . Die Erstellung dieser Blöcke ist rechenintensiv und durch Kryptographie eng miteinander verbunden.

Einfach gesagt, enthält jeder Block einen speziellen Hash (der mit einer X-Anzahl von Nullen beginnt) des Inhalts des aktuellen Blocks (in Form eines Merkle-Baums) sowie den Hash des vorherigen Blocks. Für diesen Hash muss viel CPU-Leistung erzeugt werden, da der einzige Weg, dies zu erreichen, Brute-Force ist.

Miner sind die Knoten, die versuchen, den Hash zu berechnen (über Bruteforce). Die Bergleute konkurrieren alle miteinander um die Frage, wer eine zufällige Zeichenfolge ( Nonce genannt ) erstellen kann , die in Kombination mit dem Inhalt den oben genannten Hash erzeugt. Sobald jemand die richtige Nonce gefunden hat, sendet er sie an das gesamte Netzwerk. Diese Zeichenfolge wird dann von jedem Knoten für sich überprüft und in seine Kette aufgenommen.

Dies führt zu einem System, in dem es absurd teuer ist, die Blockchain zu modifizieren, und absurd einfach zu überprüfen, ob sie nicht manipuliert wurde.

Es ist kostspielig, den Inhalt eines Blocks zu ändern, da dies einen anderen Hash erzeugen würde. Denken Sie daran, dass der Hash jedes nachfolgenden Blocks davon abhängig ist. Wenn Sie eine Transaktion im ersten Block des obigen Bildes ändern würden, würden Sie die Merkle-Wurzel ändern. Dies würde wiederum den Hash des Blocks ändern (höchstwahrscheinlich ohne die erforderlichen führenden Nullen) - das würde den Hash von Block 2 ändern und so weiter und so fort. Dies bedeutet, dass Sie für jeden Block nach dem gerade geänderten Block eine neue Nonce brutal erzwingen müssen.

Das Netzwerk vertraut immer der längsten gültigen Kette und repliziert sie. Um das System zu betrügen und schließlich eine längere Kette zu erzeugen, benötigen Sie mehr als 50% der gesamten CPU-Leistung, die von allen Knoten verbraucht wird.

Blockchain kann als verteilter Mechanismus für einen sich abzeichnenden Konsens angesehen werden . Ein Konsens wird nicht explizit erreicht - es gibt keine Wahl oder einen festen Zeitpunkt, zu dem ein Konsens erzielt wird. Stattdessen ist Konsens ein aufstrebendes Produkt der asynchronen Interaktion von Tausenden unabhängiger Knoten, die alle Protokollregeln folgen.

Diese beispiellose Innovation ist in letzter Zeit zu einem Boom im Technologiebereich geworden, und die Leute sagen voraus, dass sie die Schaffung des Web 3.0 markieren wird. Es ist definitiv der aufregendste Bereich in der Welt der Softwareentwicklung, der mit äußerst herausfordernden und interessanten Problemen gefüllt ist, die darauf warten, gelöst zu werden.

Bitcoin

Was früheren Protokollen für verteilte Zahlungen fehlte, war eine Möglichkeit, das Problem der doppelten Ausgaben in Echtzeit auf verteilte Weise praktisch zu verhindern. Die Forschung hat interessante Vorschläge gemacht [1], aber Bitcoin war der erste, der eine praktische Lösung mit klaren Vorteilen gegenüber anderen implementiert hat.

Das Problem der doppelten Ausgaben besagt, dass ein Schauspieler (z. B. Bob) seine einzelne Ressource nicht an zwei Orten ausgeben kann. Wenn Bob 1 US-Dollar hat, sollte er ihn nicht sowohl Alice als auch Zack geben können - es ist nur ein Vermögenswert, er kann nicht dupliziert werden. Es stellt sich heraus, dass es wirklich schwierig ist, diese Garantie in einem verteilten System wirklich zu erreichen. Es gibt einige interessante Abhilfemaßnahmen vor der Blockchain, die das Problem jedoch auf praktische Weise nicht vollständig lösen.

Doppelte Ausgaben werden von Bitcoin leicht gelöst, da jeweils nur ein Block zur Kette hinzugefügt wird. Doppelte Ausgaben sind innerhalb eines einzelnen Blocks nicht möglich. Selbst wenn zwei Blöcke gleichzeitig erstellt werden, befindet sich nur einer in der letztendlich längsten Kette.

Bitcoin beruht auf der Schwierigkeit, CPU-Leistung zu akkumulieren.

Während in einem Abstimmungssystem ein Angreifer nur Knoten zum Netzwerk hinzufügen muss (was einfach ist, da der freie Zugriff auf das Netzwerk ein Entwurfsziel ist), sieht sich ein Angreifer in einem auf CPU-Leistung basierenden Schema einer physischen Einschränkung gegenüber: Zugriff auf immer mehr leistungsstarke Hardware.

Dies ist auch der Grund, warum böswillige Gruppen von Knoten über 50% der Rechenleistung des Netzwerks kontrollieren müssen, um tatsächlich einen erfolgreichen Angriff auszuführen. Weniger als das, und der Rest des Netzwerks wird schneller eine längere Blockchain erstellen.

Äther

Ethereum kann als programmierbare Blockchain-basierte Softwareplattform betrachtet werden. Es verfügt über eine eigene Kryptowährung (Ether), die die Bereitstellung intelligenter Verträge in seiner Blockchain fördert.

Intelligente Verträge sind ein Code, der als einzelne Transaktion in der Ethereum-Blockchain gespeichert wird. Um den Code auszuführen, müssen Sie lediglich eine Transaktion mit einem intelligenten Vertrag als Ziel ausgeben. Dies wiederum veranlasst die Miner-Knoten, den Code und alle damit verbundenen Änderungen auszuführen. Der Code wird in der virtuellen Maschine von Ethereum ausgeführt.

Solidity , die native Programmiersprache von Ethereum, wird zum Schreiben intelligenter Verträge verwendet. Es handelt sich um eine vollständige Programmiersprache, die direkt mit der Ethereum-Blockchain verbunden ist und es Ihnen ermöglicht, Status wie Salden oder andere intelligente Vertragsergebnisse abzufragen. Um Endlosschleifen zu vermeiden, erfordert das Ausführen des Codes eine gewisse Menge Ether.

Da die blockchain als eine Reihe von interpretiert werden können Zustandsänderungen wurden auf gebaut viele verteilte Anwendungen (DApps) von Astraleum und ähnlichen Plattformen.

Weitere Verwendungen von verteilten Ledgern

Existenznachweis - Ein Dienst zum anonymen und sicheren Speichern des Nachweises, dass ein bestimmtes digitales Dokument zu einem bestimmten Zeitpunkt vorhanden war. Nützlich zur Gewährleistung der Integrität, des Eigentums und der Zeitstempelung von Dokumenten.

Dezentrale autonome Organisationen (DAO) - Organisationen, die Blockchain verwenden, um einen Konsens über die Verbesserungsvorschläge der Organisation zu erzielen. Beispiele sind das Governance-System von Dash, das SmartCash-Projekt

Dezentrale Authentifizierung - Speichern Sie Ihre Identität in der Blockchain, sodass Sie überall Single Sign-On (SSO) verwenden können. Sovrin, Civic

Und viele, viele mehr. Die verteilte Hauptbuchtechnologie eröffnete wirklich endlose Möglichkeiten. Einige werden höchstwahrscheinlich erfunden, während wir sprechen!

Zusammenfassung

In der kurzen Zeitspanne dieses Artikels haben wir definiert, was ein verteiltes System ist, warum Sie eines verwenden und jede Kategorie ein wenig durchgehen. Einige wichtige Dinge, an die Sie sich erinnern sollten, sind:

  • Verteilte Systeme sind komplex
  • Sie werden nach Maßgabe von Größe und Preis ausgewählt
  • Es ist schwieriger, mit ihnen zu arbeiten
  • CAP-Theorem - Kompromiss zwischen Konsistenz und Verfügbarkeit
  • Sie haben 6 Kategorien - Datenspeicher, Computer, Dateisysteme, Messagingsysteme, Hauptbücher, Anwendungen

Um ehrlich zu sein, haben wir die Oberfläche verteilter Systeme kaum berührt. Ich hatte nicht die Möglichkeit, Kernprobleme wie Konsens, Replikationsstrategien, Reihenfolge und Zeit von Ereignissen, Fehlertoleranz, Übertragung einer Nachricht über das Netzwerk und andere gründlich anzugehen und zu erklären.

Vorsicht

Lassen Sie mich Sie mit einer Abschiedswarnung verlassen:

Sie müssen sich so weit wie möglich von verteilten Systemen entfernen. Der mit sich selbst verbundene Komplexitätsaufwand ist die Mühe nicht wert, wenn Sie das Problem vermeiden können, indem Sie es entweder auf eine andere Weise oder durch eine andere sofort einsatzbereite Lösung lösen.

[1]

Bekämpfung von Doppelausgaben mit kooperativen P2P-Systemen, 25. bis 27. Juni 2007 - eine vorgeschlagene Lösung, bei der jede „Münze“ verfallen kann und ein Zeuge (Validator) für ihre Ausgabe zugewiesen wird.

Bitgold , Dezember 2005 - Ein allgemeiner Überblick über ein Protokoll, das dem von Bitcoin sehr ähnlich ist. Es wird gesagt, dass dies der Vorläufer von Bitcoin ist.

Weitere Informationen zu verteilten Systemen:

Entwerfen datenintensiver Anwendungen, Martin Kleppmann - Ein großartiges Buch, das alles in verteilten Systemen und mehr behandelt.

Cloud Computing-Spezialisierung, Universität von Illinois, Coursera - Eine lange Reihe von Kursen (6), die sich mit verteilten Systemkonzepten und -anwendungen befassen

Jepsen - Blog, der viele verteilte Technologien erklärt (ElasticSearch, Redis, MongoDB usw.)

Vielen Dank, dass Sie sich die Zeit genommen haben, diesen langen Artikel (~ 5600 Wörter) durchzulesen!

Wenn Sie dies zufällig als informativ empfunden haben oder der Meinung sind, dass es Ihnen einen Mehrwert bietet, stellen Sie bitte sicher, dass Sie so viele Klatschen geben, wie Sie für verdient halten, und erwägen Sie, sie mit einem Freund zu teilen, der eine Einführung in dieses wunderbare Fachgebiet gebrauchen könnte.

~ Stanislav Kozlovski

Aktualisieren

Ich arbeite derzeit bei Confluent. Confluent ist ein Big Data-Unternehmen, das von den Machern von Apache Kafka selbst gegründet wurde! Ich bin sehr dankbar für die Gelegenheit, die sie mir gegeben haben - ich arbeite derzeit an Kafka selbst, was einfach großartig ist! Wir bei Confluent gestalten das gesamte Open-Source-Kafka-Ökosystem mit, einschließlich eines neuen verwalteten Kafka-as-a-Service-Cloud-Angebots.

Wir stellen für viele Stellen (insbesondere SRE / Software Engineers) in Europa und den USA ein! Wenn Sie daran interessiert sind, an Kafka selbst zu arbeiten, nach neuen Möglichkeiten suchen oder einfach nur neugierig sind, schreiben Sie mir bitte eine Nachricht auf Twitter, und ich werde Ihnen alle großartigen Vorteile mitteilen, die sich aus der Arbeit in einem Unternehmen in der Bay Area ergeben.