Gibt es eine Liste kanonischer Probleme in verteilten Systemen?


13

Letzte Woche las ich wieder Leslie's Lamport's 1982 Transkript einer Konferenz, die er über gelöste Probleme, ungelöste Probleme und Nicht-Probleme in der Nebenläufigkeit hielt . Das Papier ist leicht lesbar, aber eines der Dinge, an die ich gedacht habe, ist die folgende Behauptung:

Kann ein Problem als ein Problem des gegenseitigen Ausschlusses oder als ein Problem zwischen Hersteller und Verbraucher oder als eine Kombination aus beiden betrachtet werden?

Ich würde gerne wissen, ob diese Frage für den Fall der verteilten Systeme beantwortet wurde.

Gibt es eine Reihe von kanonischen Problemen mit verteilten Systemen, auf die sich alle möglichen Probleme mit verteilten Systemen reduzieren lassen? Was ist diese kanonische Liste?

Wenn es keine kanonische Liste gibt, wie lautet die aktuelle Liste der Probleme und welche Reduzierungen gibt es?

Zum Beispiel würde ich sehr naiv sagen, dass die Probleme der Wahl der Führer und des gegenseitigen Ausschlusses auf das Konsensproblem reduziert werden können. Ich würde auch sagen, dass ein verteilter Schnappschuss auf eine verteilte Uhr reduziert werden kann. Ist es wahr oder einfach falsch?

Wenn möglich, würde ich es vorziehen, dass die Antworten einen Verweis auf ein veröffentlichtes Papier / Buch enthalten, das die Behauptungen stützt :)


Antworten:


9

Gibt es eine Reihe von kanonischen Problemen mit verteilten Systemen, auf die sich alle möglichen Probleme mit verteilten Systemen reduzieren lassen?

Mir ist eine solche veröffentlichte Liste von Problemen nicht bekannt.

Beachten Sie, dass es im verteilten Rechnen viele verschiedene (und etwas unvergleichbare) Modelle gibt, angefangen vom "harmlosen" synchronen (fehlerfreien) Modell, bei dem Knoten in Lock-Step-Runden ausgeführt werden und alle Nachrichten in jeder Runde zuverlässig zugestellt werden Das asynchrone Modell, bei dem Verarbeitungsgeschwindigkeiten und Nachrichtenverzögerungen nicht begrenzt sind und die Knoten selbst abstürzen oder beschädigte Nachrichten senden können. Um diese Vielfalt weiter zu erweitern, gibt es andere Anforderungen und Annahmen, die orthogonal zu Synchronität und Fehlern sind: die anfängliche Kenntnis der Knoten (Netzwerkgröße, Durchmesser des Netzwerks, maximaler Knotengrad usw.), die Fähigkeit, Fehlerdetektoren abzufragen , ob Knoten eindeutige Kennungen haben, Atomarität der Sende- und Empfangsschritte, maximale Größe einer einzelnen Nachricht und vieles mehr.

Das aktuelle Modell impliziert oft eine ganz andere Fragestellung. (Siehe [1] für weitere Ausführungen zu diesen Sub-Communities in verteilten Computing.) Bei den Modellen , die nahe an das fehlerfreien synchrone Modell sind die Forscher sehen oft an der Komplexität der lokalen Berechnung zum Beispiel „Was ist die Zeit und Nachrichtenkomplexität zur Berechnung einer Scheitelpunktfärbung?2

Bei der Betrachtung von Fehlern beziehen sich die Fragen eher auf Lösbarkeitsprobleme wie "Ist Konsens in diesem Modell lösbar?". oder "Können wir diesen ausgefallenen Fehlerdetektor unter diesen Voraussetzungen implementieren?"

Wenn es keine kanonische Liste gibt, wie lautet die aktuelle Liste der Probleme und welche Reduzierungen gibt es?

Es gibt viele Beispiele für solche Reduzierungen bei bestimmten Modellen für verteiltes Rechnen. Ich beschränke meine Antwort auf die folgenden 2:

Lokale Berechnung im (fehlerfreien) Synchronmodell

Ω(Logn+LogΔ)nΔ2EINEIN

Asynchrones Modell mit Absturzfehlern

Hier ist das am meisten untersuchte Problem der fehlertolerante Konsens und seine vielen Variationen, da die Implementierung grundlegender Grundelemente wie Atomic Broadcast und / oder eines Synchronizers selbst einen Konsens erfordern.

S PTPS

PQ.PQ.k

Zum Beispiel würde ich sehr naiv sagen, dass die Probleme der Wahl der Führer und des gegenseitigen Ausschlusses auf das Konsensproblem reduziert werden können.

Klar, wenn Sie einen Konsens lösen können, haben Sie sofort einen Algorithmus für die Führerwahl: Verwenden Sie einfach die ID jedes Knotens als Eingabe für den Konsensalgorithmus. Der umgekehrte Weg gilt nur für Modelle, bei denen garantiert ist, dass der Anführer letztendlich allen bekannt ist.

[1] Pierre Fraigniaud: Verteilte rechnerische Komplexität: Sind Sie volvosüchtig oder von Nascar besessen? PODC 2010. http://doi.acm.org/10.1145/1835698.1835700

[2] Fabian Kuhn, Thomas Moscibroda, Roger Wattenhofer: Lokale Berechnung: Untere und obere Schranken. AdRR abs / 1011.5470 (2010) http://arxiv.org/abs/1011.5470

[3] Tushar Deepak Chandra, Sam Toueg: Unzuverlässige Fehlerdetektoren für zuverlässige verteilte Systeme. J. ACM 43 (2): 225 & ndash; 267 (1996). http://doi.acm.org/10.1145/226643.226647

[4] Prasad Jayanti, Sam Toueg: Jedes Problem hat einen schwächsten Fehlerdetektor. PODC 2008: 75 & ndash; 84. http://doi.acm.org/10.1145/1400751.1400763

[5] Tushar Deepak Chandra, Vassos Hadzilacos, Sam Toueg: Der schwächste Fehlerdetektor zur Lösung des Konsenses. J. ACM 43 (4): 685-722 (1996) http://doi.acm.org/10.1145/234533.234549

[6] Michel Raynal: Fehlerdetektoren bei der Lösung der asynchronen k-Mengen-Vereinbarung: Ein Blick auf die jüngsten Ergebnisse. Bulletin of the EATCS 103: 74-95 (2011) http://albcom.lsi.upc.edu/ojs/index.php/beatcs/article/view/61


1
Hagit Attiya und Faith Ellen haben ein Buch mit dem Titel "Impossibility Results for Distributed Computing" herausgebracht.
Kaveh
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.