Atomares Commit - Atomic commit
Im Bereich der Informatik ist ein atomarer Commit eine Operation, die eine Reihe von unterschiedlichen Änderungen als eine einzige Operation anwendet. Wenn die Änderungen übernommen werden, gilt der atomare Commit als erfolgreich. Wenn ein Fehler auftritt, bevor die atomare Festschreibung abgeschlossen werden kann, werden alle in der atomaren Festschreibung abgeschlossenen Änderungen rückgängig gemacht. Dadurch wird sichergestellt, dass das System immer in einem konsistenten Zustand belassen wird. Die andere Schlüsseleigenschaft der Isolation ergibt sich aus ihrer Natur als atomare Operationen. Isolation stellt sicher, dass jeweils nur ein atomarer Commit verarbeitet wird. Am häufigsten werden atomare Commits in Datenbanksystemen und Versionskontrollsystemen verwendet .
Das Problem bei atomaren Commits besteht darin, dass sie eine Koordination zwischen mehreren Systemen erfordern. Da Computernetzwerke unzuverlässige Dienste sind, bedeutet dies, dass kein Algorithmus mit allen Systemen koordinieren kann, wie im Two Generals Problem bewiesen . Da Datenbanken immer mehr verteilt werden, wird diese Koordination die Schwierigkeit erhöhen, wirklich atomare Commits durchzuführen.
Verwendungszweck
Atomare Commits sind für mehrstufige Datenaktualisierungen unerlässlich. Dies lässt sich an einem einfachen Beispiel einer Geldüberweisung zwischen zwei Girokonten anschaulich zeigen.
Dieses Beispiel wird durch eine Transaktion zum Überprüfen des Saldos von Konto Y während einer Transaktion zur Überweisung von 100 Dollar von Konto X auf Y kompliziert. Zu Beginn werden zuerst 100 Dollar von Konto X abgezogen. Zweitens werden 100 Dollar auf Konto Y hinzugefügt. Wenn Wird die gesamte Operation nicht als ein atomarer Commit abgeschlossen, können mehrere Probleme auftreten. Wenn das System mitten in der Operation ausfällt, nachdem das Geld von X entfernt wurde und bevor es zu Y hinzugefügt wurde, sind 100 Dollar einfach verschwunden. Ein weiteres Problem besteht darin, dass, wenn der Saldo von Y überprüft wird, bevor die 100 Dollar hinzugefügt werden, der falsche Saldo für Y gemeldet wird.
Bei atomaren Commits kann keiner dieser Fälle auftreten, im ersten Fall des Systemausfalls würde der atomare Commit rückgängig gemacht und das Geld an X zurückgegeben. Im zweiten Fall kann die Anforderung des Saldos von Y erst erfolgen, wenn das atomare Commit ist vollständig abgeschlossen.
Datenbanksysteme
Atomare Commits in Datenbanksystemen erfüllen zwei der Schlüsseleigenschaften von ACID , Atomizität und Konsistenz . Konsistenz wird nur erreicht, wenn jede Änderung im atomaren Commit konsistent ist.
Wie im Beispiel gezeigt, sind atomare Commits für mehrstufige Operationen in Datenbanken von entscheidender Bedeutung. Aufgrund des modernen Hardwaredesigns der physischen Festplatte, auf der sich die Datenbank befindet, können keine echten atomaren Commits existieren. Der kleinste beschreibbare Bereich auf der Festplatte wird als Sektor bezeichnet. Ein einzelner Datenbankeintrag kann mehrere verschiedene Sektoren umfassen. Es kann jeweils nur ein Sektor geschrieben werden. Dieses Schreiblimit ist der Grund, warum echte atomare Commits nicht möglich sind. Nachdem die Datenbankeinträge im Speicher geändert wurden, werden sie in die Warteschlange gestellt, um auf die Festplatte geschrieben zu werden. Dies bedeutet, dass die gleichen Probleme, die im Beispiel identifiziert wurden, erneut aufgetreten sind. Jede algorithmische Lösung dieses Problems wird immer noch auf das Problem der zwei Generäle stoßen. Das Zwei-Phasen-Commit-Protokoll und das Drei-Phasen-Commit-Protokoll versuchen, dieses und einige der anderen Probleme im Zusammenhang mit atomaren Commits zu lösen.
Das Zweiphasen-Commit-Protokoll erfordert, dass ein Koordinator alle Informationen verwaltet, die erforderlich sind, um den ursprünglichen Zustand der Datenbank wiederherzustellen, wenn etwas schief geht. Wie der Name schon sagt, gibt es zwei Phasen, Voting und Commit .
Während der Abstimmungsphase schreibt jeder Knoten die Änderungen im atomaren Commit auf seine eigene Platte. Die Knoten melden dann ihren Status an den Koordinator. Wenn ein Knoten dem Koordinator keinen Bericht erstattet oder seine Statusnachricht verloren geht, geht der Koordinator davon aus, dass der Schreibvorgang des Knotens fehlgeschlagen ist. Nachdem sich alle Knoten beim Koordinator gemeldet haben, beginnt die zweite Phase.
Während der Festschreibungsphase sendet der Koordinator eine Festschreibungsnachricht an jeden der Knoten, um sie in ihren individuellen Protokollen aufzuzeichnen. Bis diese Nachricht zum Protokoll eines Knotens hinzugefügt wird, werden alle vorgenommenen Änderungen als unvollständig aufgezeichnet. Wenn einer der Knoten einen Fehler gemeldet hat, sendet der Koordinator stattdessen eine Rollback-Nachricht. Dadurch werden alle Änderungen entfernt, die die Knoten auf die Festplatte geschrieben haben.
Das dreiphasige Festschreibungsprotokoll versucht, das Hauptproblem mit dem zweiphasigen Festschreibungsprotokoll zu beseitigen, das auftritt, wenn ein Koordinator und ein anderer Knoten gleichzeitig während der Festschreibungsphase ausfallen und keiner sagen kann, welche Aktion ausgeführt werden soll. Um dieses Problem zu lösen, wird dem Protokoll eine dritte Phase hinzugefügt. Die Vorbereitungsphase zum Festschreiben erfolgt nach der Abstimmungsphase und vor der Festschreibungsphase .
In der Abstimmungsphase fordert der Koordinator ähnlich wie beim zweiphasigen Festschreiben an, dass jeder Knoten zum Festschreiben bereit ist. Wenn ein Knoten ausfällt, tritt beim Koordinator eine Zeitüberschreitung ein, während er auf den ausgefallenen Knoten wartet. In diesem Fall sendet der Koordinator eine Abbruchnachricht an jeden Knoten. Die gleiche Aktion wird ausgeführt, wenn einer der Knoten eine Fehlermeldung zurückgibt.
Nach dem Empfang von Erfolgsnachrichten von jedem Knoten in der Abstimmungsphase beginnt die Vorbereitungsphase für die Festschreibung. Während dieser Phase sendet der Koordinator eine Vorbereitungsnachricht an jeden Knoten. Jeder Knoten muss die Vorbereitungsnachricht bestätigen und antworten. Wenn eine Antwort verpasst wird oder ein Knoten zurückgibt, dass er nicht vorbereitet ist, sendet der Koordinator eine Abbruchnachricht. Jeder Knoten, der vor Ablauf des Timeouts keine Vorbereitungsnachricht empfängt, bricht den Commit ab.
Nachdem alle Knoten auf die Vorbereitungsnachricht geantwortet haben , beginnt die Festschreibungsphase . In dieser Phase sendet der Koordinator eine Commit-Nachricht an jeden Knoten. Wenn jeder Knoten diese Nachricht empfängt, führt er den eigentlichen Commit durch. Wenn die Commit-Nachricht einen Knoten nicht erreicht, weil die Nachricht verloren geht oder der Koordinator fehlschlägt, wird der Commit ausgeführt, wenn die Zeitüberschreitung abläuft. Wenn der Koordinator bei der Wiederherstellung ausfällt, sendet er eine Festschreibungsnachricht an jeden Knoten.
Revisionskontrolle
Atomare Commits sind ein übliches Merkmal von Versionskontrollsoftware und entscheidend für die Aufrechterhaltung eines konsistenten Zustands im Repository. Die meisten Versionskontrollsoftware wendet keinen Teil eines fehlgeschlagenen Commits an. Bemerkenswerte Ausnahmen sind CVS , VSS und IBM Rational ClearCase (im UCM-Modus).
Wenn beispielsweise die Versionskontrollsoftware auf einen Zusammenführungskonflikt stößt , der nicht automatisch gelöst werden kann, wird kein Teil des Änderungssatzes zusammengeführt. Stattdessen erhält der Entwickler die Möglichkeit, seine Änderungen entweder rückgängig zu machen oder den Konflikt manuell zu lösen.
Dadurch wird verhindert, dass das gesamte Projekt aufgrund eines teilweise angewendeten Änderungssatzes in einen fehlerhaften Zustand übergeht, bei dem eine Datei aus einem Commit erfolgreich festgeschrieben wird, eine andere Datei mit abhängigen Änderungen jedoch fehlschlägt.
Atomic Commits können sich auch auf die Fähigkeit beziehen, gleichzeitig Änderungen in mehreren Projekten mit Versionskontrollsoftware in einem einzigen Vorgang vorzunehmen , wobei eine Versionskontrollsoftware-Entwicklungsstrategie, bekannt als Monorepo, verwendet wird .
Atomare Commit-Konvention
Bei der Verwendung eines Revisionskontrollsystems ist es eine übliche Konvention, kleine Commits zu verwenden. Diese werden manchmal als atomare Commits bezeichnet, da sie (idealerweise) nur einen einzelnen Aspekt des Systems betreffen. Diese atomaren Commits ermöglichen eine bessere Verständlichkeit, weniger Aufwand, Änderungen rückgängig zu machen, und eine einfachere Fehlererkennung.
Die größere Verständlichkeit ergibt sich aus der geringen Größe und dem fokussierten Charakter des Commits. Es ist viel einfacher zu verstehen, was geändert wird und was hinter den Änderungen steckt, wenn man nur nach einer Art von Änderung sucht. Dies wird besonders wichtig, wenn Formatänderungen am Quellcode vorgenommen werden. Wenn Format- und Funktionsänderungen kombiniert werden, wird es sehr schwierig, sinnvolle Änderungen zu identifizieren. Stellen Sie sich vor, wenn der Abstand in einer Datei von Tabulatoren auf drei Leerzeichen geändert wird, wird jeder Tabulator in der Datei als geändert angezeigt. Dies wird kritisch, wenn auch einige funktionale Änderungen vorgenommen werden, da ein Prüfer die funktionalen Änderungen möglicherweise einfach nicht sieht.
Wenn nur atomare Commits gemacht werden, sind Commits, die Fehler einführen, viel einfacher zu identifizieren. Man muss nicht jedes Commit durchsuchen, um festzustellen, ob es die Ursache des Fehlers war, es müssen nur die Commits untersucht werden, die sich mit dieser Funktionalität befassen. Wenn der Fehler zurückgesetzt werden soll, machen atomare Commits die Arbeit wieder viel einfacher. Statt zu haben , zurückkommen auf die säumige Revision und die Änderungen manuell entfernen , bevor Sie später Änderungen zu integrieren; der Entwickler kann alle Änderungen im identifizierten Commit einfach rückgängig machen. Dies verringert auch das Risiko, dass ein Entwickler versehentlich nicht verwandte Änderungen entfernt, die sich zufällig im selben Commit befinden.
Atomic-Commits ermöglichen auch eine einfache Überprüfung von Bugfixes, wenn nur ein einziger Bugfix gleichzeitig begangen wird. Anstatt mehrere potenziell nicht verwandte Dateien überprüfen zu müssen, muss der Prüfer nur Dateien und Änderungen überprüfen, die sich direkt auf den zu behebenden Fehler auswirken. Dies bedeutet auch, dass Fehlerkorrekturen einfach zum Testen gepackt werden können, da nur die Änderungen, die den Fehler beheben, im Commit enthalten sind.
