Einführung in Reliable Collections in zustandsbehafteten Azure Service Fabric-Diensten

Reliable Collections ermöglichen es Ihnen, hoch verfügbare, skalierbare Cloudanwendungen mit geringer Latenz auf die gleiche Weise wie Anwendungen für einen einzelnen Computer zu schreiben. Die Klassen im Namespace Microsoft.ServiceFabric.Data.Collections stellen eine Reihe von Sammlungen bereit, die automatisch einen hochverfügbaren Zustand ermöglichen. Als Entwickler programmieren Sie lediglich die Reliable Collections-APIs. Reliable Collections verwalten anschließend den replizierten lokalen Zustand automatisch.

Der Hauptunterschied zwischen zuverlässigen Auflistungen und anderen Hochverfügbarkeitstechnologien (z. B. Redis, Azure-Tabellendienst und Azure-Warteschlangendienst) ist, dass der Zustand lokal in der Dienstinstanz gespeichert wird und gleichzeitig hoch verfügbar ist. Dies bedeutet Folgendes:

  • Alle Lesevorgänge erfolgen lokal, was eine geringe Latenz und einen hohen Lesedurchsatz zur Folge hat.
  • Alle Schreibvorgänge lösen die Mindestanzahl von Netzwerk-E/As aus, was eine geringe Latenz und einen hohen Schreibdurchsatz zur Folge hat.

Image of evolution of collections.

Reliable Collections können als natürliche Weiterentwicklung der System.Collections -Klassen betrachtet werden: Der neue Satz von Auflistungen wurde für Cloudanwendungen und Umgebungen mit mehreren Computern konzipiert, ohne die Komplexität für den Entwickler zu erhöhen. Reliable Collections sind damit:

  • Repliziert: Zustandsänderungen werden für Hochverfügbarkeit repliziert.
  • Asynchron: APIs sind asynchron, um sicherzustellen, dass Threads bei einer E/A nicht blockiert werden.
  • Transaktional: APIs nutzen die Abstraktion von Transaktionen, damit Sie mehrere Reliable Collections (zuverlässige Sammlungen) auf einfache Weise in einem Dienst verwalten können.
  • Persistent oder flüchtig: Daten können persistent auf Datenträgern gespeichert werden, um sie vor größeren Ausfällen (etwa einem Stromausfall im Datencenter) zu schützen. Von einigen zuverlässigen Sammlungen wird auch ein flüchtiger Modus (mit Einschränkungen) unterstützt, bei dem sich alle Daten im Arbeitsspeicher befinden (beispielsweise ein replizierter In-Memory-Cache).

Reliable Collections zeichnen sich durch von Anfang an starke Konsistenzgarantien aus, was die Argumentation hinsichtlich Anwendungszuständen erleichtert. Eine starke Konsistenz wird erreicht, indem Transaktionscommits erst abgeschlossen werden, nachdem die gesamte Transaktion in einem Mehrheitsquorum von Replikaten (einschließlich des primären Replikats) protokolliert wurde. Um eine schwächere Konsistenz zu erreichen, können Anwendungen eine Bestätigung zurück an den Client/Antragsteller senden, bevor der asynchrone Commit zurückgegeben wird.

Die Reliable Collections-APIs sind eine Weiterentwicklung der APIs für gleichzeitige Auflistungen (im Namespace System.Collections.Concurrent ):

  • Asynchron: Gibt eine Aufgabe zurück, da die Vorgänge im Gegensatz zu gleichzeitigen Auflistungen repliziert und persistent gespeichert werden.
  • Keine out-Parameter: Gibt mithilfe von ConditionalValue<T>bool und einen Wert anstelle von out-Parametern zurück. ConditionalValue<T> entspricht Nullable<T>, erfordert aber für „struct“ nicht „T“.
  • Transaktionen: Verwendet ein Transaktionsobjekt, um dem Benutzer Gruppenaktionen für mehrere zuverlässige Auflistungen in einer Transaktion zu ermöglichen.

Aktuell enthält Microsoft.ServiceFabric.Data.Collections drei Sammlungen:

  • Zuverlässiges Wörterbuch: Stellt eine replizierte, transaktionale und asynchrone Auflistung von Schlüssel-Wert-Paaren dar. Ähnlich wie bei ConcurrentDictionarykönnen der Schlüssel und der Wert von beliebigem Typ sein.
  • Zuverlässige Warteschlange: Stellt eine replizierte, transaktionale und asynchrone strenge FIFO-Warteschlange (First In, First Out) dar. Ähnlich wie bei ConcurrentQueuekann der Wert von beliebigem Typ sein.
  • Reliable Concurrent Queue: Stellt eine replizierte, transaktionale und asynchrone Warteschlange dar, die für einen hohen Durchsatz eine optimale Reihenfolge herstellt. Ähnlich wie bei ConcurrentQueue kann der Wert einen beliebigem Typ aufweisen.

Nächste Schritte