In einem verteilten System kann der Ausfall eines Computers, von dessen Existenz Sie nicht einmal wussten, dazu führen, dass Ihr eigener Computer unbrauchbar wird.
Dieses berühmte Zitat von Leslie Lamport, Preisträger des AM Turing Award, fasst die Herausforderungen beim Aufbau und der Wartung eines verteilten Systems zusammen. Aber warum sind derart komplizierte Systeme erforderlich?
Mit dem Aufkommen des Internets und intelligenterer Geräte ist die Menge der zu verarbeitenden Daten explosionsartig angestiegen. Einfache Alltagsaktivitäten wie die Bestellung eines Uber, das Ansehen einer Sendung auf Netflix, eine einfache Google-Suche, Online-Shopping oder die Interaktion mit sozialen Medien – alles triviale Aktionen, die wir für selbstverständlich halten, werden von Hunderten von Verteilungsdiensten unterstützt. All diese Dienste basieren auf einigen grundlegenden Dokumenten zu verteilten Systemen.
Obwohl diese Liste bei weitem nicht vollständig ist, sind hier einige meiner Lieblingsartikel, die einen massiven Einfluss auf die Welt der verteilten Systeme hatten.
Obwohl es sich nicht um ein traditionelles Papier handelt, stellte Eric Brewer es erstmals als Vermutung in einer Grundsatzrede auf dem ACM Symposium on Principles of Distributed Computing (PODC) im Jahr 2000 vor. Das Papier wurde später von Nancy Lynch und Seth Gilbert in dem Papier Brewer's Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services formalisiert und bewiesen.
Eric Brewers CAP-Theorem ist ein grundlegendes Konzept in der Theorie verteilter Systeme. Es besagt, dass es für einen verteilten Datenspeicher unmöglich ist, gleichzeitig mehr als zwei von drei Garantien zu erfüllen: Konsistenz, Verfügbarkeit und Partitionstoleranz. Alle anderen hier erwähnten Arbeiten wenden das obige Prinzip an und treffen die erforderlichen Kompromisse in ihrem System.
Der CAP-Satz führt immer zu zahlreichen Diskussionen, die auf dem Verständnis des Artikels durch den Leser beruhen. Martin Kleppmanns „ Eine Kritik des CAP-Satzes “ bietet einen besseren Rahmen für die Diskussion der Kompromisse.
In diesem wegweisenden Artikel aus dem Jahr 2001 stellt Leslie Lamport den Paxos-Algorithmus zur Konsensfindung in einem verteilten System auf einfache und leicht zugängliche Weise vor. Paxos-basierte Konsensprotokolle bilden das Rückgrat vieler verteilter Datenbanken, Speichersysteme, Messaging-Plattformen und Koordinierungsdienste, die von vielen Technologieunternehmen verwendet werden. Sie haben andere Technologien wie Googles Chubby, Googles Spanner, Apache ZooKeeper, Apache BookKeeper usw. stark beeinflusst.
Das Dokument zum Google File System (GFS) stellt ein skalierbares verteiltes Dateisystem für große verteilte datenintensive Anwendungen auf Standardhardware vor, das die Grundlage für viele nachfolgende verteilte Dateisysteme bildet. GFS diente als wichtige Inspiration für HDFS, das verteilte Dateisystem, das vom Apache Hadoop-Framework und schließlich von Amazon S3 verwendet wurde (obwohl S3 grundlegend anders ist).
In diesem Dokument wird das MapReduce-Programmiermodell vorgestellt, das einen skalierbaren Ansatz zur Verarbeitung großer Datensätze mithilfe einer verteilten Computerinfrastruktur darstellt. MapReduce spielte eine entscheidende Rolle in der „Big Data“-Revolution und ermöglichte es Unternehmen, die Leistungsfähigkeit des verteilten Computings zu nutzen, um riesige Datensätze zu analysieren und Erkenntnisse daraus abzuleiten. Sie können sehen, wie Google durch die Kombination von GFS und MapReduce Petabytes an Daten verarbeiten konnte, um Daten des „Internets“ zu organisieren.
Das MapReduce-Dokument (zusammen mit GFS) inspirierte die Entwicklung eines ganzen Ökosystems aus Tools und Bibliotheken rund um Apache Hadoop, wie etwa Apache Hive (auf Hadoop basierende Data Warehouse-Infrastruktur), Apache Pig (höhere Datenflusssprache für Hadoop), Apache Spark (In-Memory-Datenverarbeitungs-Engine), Apache HBase (verteilte NoSQL-Datenbank) und viele andere.
Das Bigtable-Dokument stellt ein verteiltes Speichersystem zur Verwaltung strukturierter Daten bei Google dar. Nachdem Google mit MapReduce und GFS in der Lage war, Daten in großem Maßstab und auf kostengünstige Weise zu verarbeiten, bestand der nächste Schritt darin, einen zuverlässigen und hochverfügbaren Zugriff auf die Daten zu ermöglichen. BigTable konnte eine flexible, leistungsstarke Lösung für Anwendungen wie Web-Indizierung, Google Earth und Google Finance bereitstellen.
So wie MapReduce das Zeitalter von „Big Data“ revolutionierte, war das BigTable-Papier die treibende Kraft für das Zeitalter von „NoSQL“. Viele der im Bigtable-Papier vorgestellten Designprinzipien und Architekturkonzepte wurden in Technologien wie „Apache HBase“, „Cassandra“, „MongoD“ usw. verwendet. Während einige dieser Anwendungen möglicherweise andere Datenmodelle verwenden (z. B. MongoDB), haben sie gemeinsame Prinzipien wie horizontale Skalierbarkeit, Fehlertoleranz und automatisches Sharding.
Das Dynamo-Dokument präsentiert das Design und die Implementierung eines hochverfügbaren Key-Value-Stores, der von Amazon entwickelt wurde. Dynamo befasst sich mit der Notwendigkeit des Echtzeitzugriffs auf hochdynamische Daten, wie z. B. Artikel in Ihrem Einkaufswagen. Das Dokument führte das Konzept der „Eventual Consistency“ als Kernprinzip des Designs verteilter Systeme ein, das lockere Konsistenzgarantien ermöglicht, um hohe Verfügbarkeit und Leistung zu erreichen (Hallo, CAP-Theorem!).
Aus dem Dokument selbst geht hervor: „Im Vergleich zu Bigtable zielt Dynamo auf Anwendungen ab, die nur Schlüssel-/Wertzugriff erfordern, wobei der Schwerpunkt in erster Linie auf hoher Verfügbarkeit liegt, sodass Updates auch bei Netzwerkpartitionierungen oder Serverausfällen nicht abgelehnt werden.“
Ähnlich wie BigTable hatte das Dynamo-Papier großen Einfluss auf nachfolgende Technologien wie Riak, Voldemort, Cassandra und sogar Event-Streaming-Technologien wie Apache Kafka.
Das schnelle Wachstum von Facebook machte eine Datenbanklösung erforderlich, die in der Lage war, riesige Datenmengen zu verarbeiten und eine große Anzahl gleichzeitiger Benutzer zu unterstützen. BigTable und Dynamo waren zwar für sich genommen recht einflussreich, doch Cassandra war die erste Technologie, die anderen einen Schritt voraus war. Indem Facebook sie als Open-Source-Beitrag unter der Apache-Lizenz veröffentlichte und das Dokument veröffentlichte, trug es maßgeblich dazu bei, der gesamten Branche Zugang zu dieser Technologie zu verschaffen.
Cassandra unterschied sich von den beiden Vorgängern durch die Bereitstellung eines anpassbaren Konsistenzmodells, sodass Benutzer je nach Anwendungsanforderungen zwischen starker Konsistenz (wie BigTable) und eventueller Konsistenz (wie Dynamo) wählen konnten.
Dieses Dokument stellt Apache ZooKeeper vor und präsentiert seine Designprinzipien und Algorithmen zur Bereitstellung äußerst zuverlässiger und skalierbarer Koordinierungsdienste in verteilten Systemen. Vor der Einführung von ZooKeeper mussten Softwareentwickler häufig ihre eigenen Ad-hoc-Lösungen für verteilte Koordinierung und Konsens in verteilten Systemen implementieren.
ZooKeeper schlug einen zentralisierten Dienst für verteilte Koordination vor, der Grundelemente wie verteilte Sperren, Leiterwahl und Konfigurationsmanagement anbot. Dies ermöglichte die Vereinfachung der Entwicklung verteilter Anwendungen durch Auslagerung komplexer Koordinationslogik auf ZooKeeper. Einer der häufigsten Anwendungsfälle für Zookeeper ist die Diensterkennung.
In diesem Dokument wird Apache Kafka vorgestellt, ein verteiltes Nachrichtensystem, das für die fehlertolerante Verarbeitung von Ereignisströmen mit hohem Durchsatz entwickelt wurde. Kafkas Veröffentlichung als Forschungsdokument und seine Open-Source-Veröffentlichung als Apache-Projekt etablierten es als Standardnachrichtensystem für hoch skalierbare und fehlertolerante Echtzeit-Datenverarbeitung und ereignisgesteuerte Architekturen.
Kafka führte ein hochgradig skalierbares und fehlertolerantes Nachrichtensystem ein, das für die Verarbeitung großer Datenmengen in Echtzeit konzipiert ist. Kafka war maßgeblich an der Entwicklung der Lambda-Architektur beteiligt, die Batch- und Stream-Verarbeitung kombiniert, um große Datenmengen mit geringer Latenz und hohem Durchsatz zu verarbeiten.
In diesem Dokument werden Resilient Distributed Datasets (RDDs) vorgestellt, die Kernabstraktion in Apache Spark, die fehlertolerante In-Memory-Datenverarbeitung über verteilte Cluster hinweg ermöglicht. Die In-Memory-Ausführungs-Engine von Spark bietet im Vergleich zu MapReduce (das ein festplattenbasiertes Ausführungsmodell hat) eine deutlich schnellere Leistung, insbesondere für iterative Algorithmen, maschinelles Lernen und interaktive Analysen.
Diese Dokumente decken ein breites Themenspektrum verteilter Systeme ab, darunter Speichersysteme, Konsensalgorithmen, Fehlertoleranz und Skalierbarkeit. Die Lektüre dieser Dokumente vermittelt Ihnen eine solide Grundlage in den Prinzipien und Praktiken des Aufbaus und der Verwaltung verteilter Systeme.
Wenn Sie Ihre Reise in verteilte Systeme beginnen und mehr erfahren möchten oder wenn Sie bereits ein Experte sind und einfach Ihre Grundlagenkenntnisse auffrischen möchten, gibt es keinen besseren Weg zum Lernen als die Lektüre einiger dieser grundlegenden Dokumente zu verteilten Systemen.