Parallelitätsmodell in Azure-In-Role Cache
Wichtig
Microsoft empfiehlt, alle neuen Entwicklungen azure Redis Cache zu verwenden. Für aktuelle Dokumentation und Anleitungen zur Auswahl eines Azure Cache-Angebots finden Sie unter Welches Azure Cache-Angebot ist für mich richtig?
Die Cachearchitektur gestattet jedem Cacheclient den Zugriff auf zwischengespeicherte Daten, wenn diese Clients über die geeigneten Netzwerkzugriffs- und Konfigurationseinstellungen verfügen. Dies stellt für den parallelen Zugriff eine Herausforderung dar.
Zur Unterstützung Ihrer Anwendung beim Umgang mit Problemen mit dem parallelen Zugriff werden optimistische und pessimistischen Parallelitätsmodelle unterstützt.
Optimistisches Parallelitätsmodell
Im optimistischen Parallelitätsmodell werden für Aktualisierungen zwischengespeicherter Objekte keine Sperren verwendet. Stattdessen erhält und speichert der Cacheclient auch die aktuelle Version eines Objekts, wenn er ein Objekt aus dem Cache abruft. Wenn eine Aktualisierung erforderlich wird, sendet der Cacheclient den neuen Wert für das Objekt zusammen mit der gespeicherten Version des Objekts. Das System aktualisiert das Objekt nur dann, wenn die gesendete Version mit der aktuellen Version des Objekts im Cache übereinstimmt. Mit jeder Aktualisierung eines Objekts wird dessen Versionsnummer geändert. Auf diese Weise wird verhindert, dass mit einer Aktualisierung die Änderungen eines anderen Cacheclients überschrieben werden.
Das Beispiel in diesem Thema zeigt, wie bei der optimistischen Parallelität die Datenkonsistenz sichergestellt wird.
Beispiel
In diesem Beispiel versuchen zwei Cacheclients (cacheClientA und cacheClientB), das gleiche zwischengespeicherte Objekt mit dem gleichen Schlüssel RadioInventory zu aktualisieren.
Uhrzeit Null: Beide Clients rufen das gleiche Objekt ab
Zum Zeitpunkt Null (T0) instanziieren beide Cacheclients eine Klasse DataCacheItem, um das zwischengespeicherte Objekt zu erfassen, das sie aktualisieren möchten, zusammen mit zusätzlichen Informationen zum zwischengespeicherten Objekt wie etwa Versions- und Taginformationen. Dies wird im folgenden Codebeispiel veranschaulicht.
'cacheClientA pulls the FM radio inventory from cache
Dim clientACacheFactory As DataCacheFactory = New DataCacheFactory()
Dim cacheClientA As DataCache = _
clientACacheFactory.GetCache("catalog")
Dim radioInventoryA As DataCacheItem = _
cacheClientA.GetCacheItem("RadioInventory")
'cacheClientB pulls the same FM radio inventory from cache
Dim clientBCacheFactory As DataCacheFactory = New DataCacheFactory()
Dim cacheClientB As DataCache = _
clientBCacheFactory.GetCache("catalog")
Dim radioInventoryB As DataCacheItem = _
cacheClientB.GetCacheItem("RadioInventory")
//cacheClientA pulls the FM radio inventory from cache
DataCacheFactory clientACacheFactory = new DataCacheFactory();
DataCache cacheClientA = clientACacheFactory.GetCache("catalog");
DataCacheItem radioInventoryA =
cacheClientA.GetCacheItem("RadioInventory");
//cacheClientB pulls the same FM radio inventory from cache
DataCacheFactory clientBCacheFactory = new DataCacheFactory();
DataCache cacheClientB = clientBCacheFactory.GetCache("catalog");
DataCacheItem radioInventoryB=
cacheClientB.GetCacheItem("RadioInventory");
Hinweis
Obwohl in diesem Beispiel die Versionsinformationen mithilfe der GetCacheItem-Methode abgerufen werden, um das DataCacheItem-Objekt abzurufen, ist es auch möglich, die Get-Methode zum Abrufen des DataCacheItemVersion-Objekts zu verwenden, das dem abgerufenen Cacheelement zugeordnet ist.
Time One: Das erste Update erfolgreich
Zum Zeitpunkt Eins (T1) aktualisiert cacheClientA das zwischengespeicherte Objekt RadioInventory mit einem neuen Wert. Wenn cacheClientA die Put-Methode ausführt, wird die dem RadioInventory-Cache zugeordnete Version erhöht. Zu diesem Zeitpunkt verfügt cacheClientB über ein veraltetes Cacheelement. Dies wird im folgenden Beispiel veranschaulicht.
'at time T1, cacheClientA updates the FM radio inventory
Dim newRadioInventoryA As Integer = 155
cacheClientA.Put("RadioInventory", newRadioInventoryA, _
radioInventoryA.Version)
//at time T1, cacheClientA updates the FM radio inventory
int newRadioInventoryA = 155;
cacheClientA.Put("RadioInventory", newRadioInventoryA,
radioInventoryA.Version);
Zeit zwei: Das zweite Update schlägt fehl
Zum Zeitpunkt Zwei (T2) versucht cacheClientB, das zwischengespeicherte RadioInventory-Objekt zu aktualisieren, indem die nun veraltete Versionsnummer verwendet wird. Damit verhindert wird, dass die Änderungen von cacheClientA überschrieben werden, schlägt der Aufruf der Put-Methode durch cacheClientB fehl. Der Cacheclient löst ein DataCacheException-Objekt mit der ErrorCode-Eigenschaft , die auf CacheItemVersionMismatch festgelegt ist. Dies wird im folgenden Codebeispiel veranschaulicht.
'later, at time T2, cacheClientB tries to
'update the FM radio inventory, receives DataCacheException with
'an error code equal to DataCacheErrorCode.CacheItemVersionMismatch.
Dim newRadioInventoryB As Integer = 130
cacheClientB.Put("RadioInventory", newRadioInventoryB, _
radioInventoryB.Version)
//later, at time T2, cacheClientB tries to
//update the FM radio inventory, receives DataCacheException with
//an error code equal to DataCacheErrorCode.CacheItemVersionMismatch.
int newRadioInventoryB = 130;
cacheClientB.Put("RadioInventory", newRadioInventoryB,
radioInventoryB.Version);
Pessimistisches Parallelitätsmodell
Im pessimistischen Parallelitätsmodell sperrt der Client Objekte ausdrücklich, um Vorgänge auszuführen. Andere Vorgänge, die Sperren anfordern, werden zurückgewiesen (das System blockiert Anforderungen nicht), bis die Sperren freigegeben wurden. Wenn Objekte gesperrt sind, wird ein Sperrhandle als ein Ausgabeparameter zurückgegeben. Das Sperrhandle ist zum Aufheben der Sperre des Objekts erforderlich. Falls die Clientanwendung vor der Freigabe eines gesperrten Objekts beendet wird, werden Timeouts bereitgestellt, um die Sperren freizugeben. Gesperrte Objekte laufen niemals ab, sie können jedoch nach dem Aufheben ihrer Sperre sofort ablaufen, wenn ihre Ablaufzeit überschritten wurde.
Weitere Informationen zu den Methoden, die mit dem pessimistischen Concurrency-Modell verwendet werden, finden Sie unter Concurrency-Methoden
Hinweis
Vorgangsübergreifende Transaktionen werden nicht unterstützt.
Hinweis
Die Anwendung, die den Cache verwendet, ist für die Ermittlung der Reihenfolge der Sperren und ggf. das Erkennen von Deadlocks verantwortlich.
Warnung
Gesperrte Objekte im Cache können dennoch durch beliebige Cacheclients mit der Methode Put ersetzt werden. Cacheaktivierte Anwendungen sind für die konsistente Verwendung von PutAndUnlock für Elemente verantwortlich, die das pessimistische Parallelitätsmodell verwenden.