Udostępnij za pośrednictwem

Wskazówki i zalecenia dotyczące niezawodnych kolekcji w usłudze Azure Service Fabric

  • Artykuł

Ta sekcja zawiera wskazówki dotyczące używania niezawodnego menedżera stanu i niezawodnych kolekcji. Celem jest pomoc użytkownikom w unikaniu typowych pułapek.

Wytyczne dotyczące niezawodnej kolekcji

Wytyczne są zorganizowane jako proste rekomendacje poprzedzone terminami Do, Consider, Avoid and Do not.

  • Nie należy modyfikować obiektu typu niestandardowego zwracanego przez operacje odczytu (na przykład TryPeekAsync lub TryGetValueAsync). Kolekcje reliable, podobnie jak kolekcje concurrent, zwracają odwołanie do obiektów, a nie kopię.
  • Przed zmodyfikowaniem obiektu niestandardowego wykonaj głębokie kopiowanie zwróconego obiektu typu niestandardowego. Ponieważ struktury i wbudowane typy są przekazywane po wartości, nie trzeba wykonywać na nich głębokiej kopii, chyba że zawierają pola lub właściwości, które mają być modyfikowane.
  • Nie należy używać TimeSpan.MaxValue w przypadku przekroczenia limitu czasu. Limity czasu powinny być używane do wykrywania zakleszczeń.
  • Nie należy używać transakcji po jej zatwierdzeniu, przerwaniu lub usunięciu.
  • Nie używaj wyliczenia poza zakresem transakcji, w której został utworzony.
  • Nie twórz transakcji w ramach instrukcji innej transakcji using , ponieważ może to spowodować zakleszczenia.
  • Nie twórz niezawodnego stanu i IReliableStateManager.GetOrAddAsync używaj niezawodnego stanu w tej samej transakcji. Spowoduje to wyjątek InvalidOperationException.
  • Upewnij się, że implementacja IComparable<TKey> jest poprawna. System przyjmuje zależność od IComparable<TKey> scalania punktów kontrolnych i wierszy.
  • Należy użyć blokady aktualizacji podczas odczytywania elementu z zamiarem aktualizacji, aby zapobiec określonej klasie zakleszczeń.
  • Rozważ utrzymanie liczby niezawodnych kolekcji na partycję, która będzie mniejsza niż 1000. Preferuj niezawodne kolekcje z większą liczbą elementów w bardziej niezawodnych kolekcjach z mniejszą liczbą elementów.
  • Rozważ zachowanie elementów (na przykład TKey + TValue dla niezawodnego słownika) poniżej 80 KBytes: mniejsze niżej. Zmniejsza to ilość dużego użycia stert obiektów, a także wymagania dotyczące operacji we/wy dysku i sieci. Często zmniejsza replikowanie zduplikowanych danych, gdy jest aktualizowana tylko jedna mała część wartości. Typowym sposobem osiągnięcia tego celu w języku Reliable Dictionary jest podzielenie wierszy na wiele wierszy.
  • Rozważ użycie funkcji tworzenia kopii zapasowej i przywracania w celu odzyskania po awarii.
  • Unikaj mieszania operacji pojedynczej jednostki i operacji z wieloma jednostkami (np GetCountAsync. ) CreateEnumerableAsyncw tej samej transakcji ze względu na różne poziomy izolacji.
  • Do obsługi InvalidOperationException. Transakcje użytkowników mogą zostać przerwane przez system z różnych powodów. Na przykład gdy menedżer niezawodnego stanu zmienia swoją rolę poza podstawową lub gdy długotrwała transakcja blokuje obcinanie dziennika transakcyjnego. W takich przypadkach użytkownik może otrzymać wyjątek InvalidOperationException wskazujący, że transakcja została już zakończona. Zakładając, że zakończenie transakcji nie zostało żądane przez użytkownika, najlepszym sposobem obsługi tego wyjątku jest usunięcie transakcji, sprawdzenie, czy token anulowania został zasygnalizowany (lub rola repliki została zmieniona), a jeśli nie utworzyć nowej transakcji i ponowić próbę.
  • Nie należy stosować operacji równoległych ani współbieżnych w ramach transakcji. Tylko jedna operacja wątku użytkownika jest obsługiwana w ramach transakcji. W przeciwnym razie spowoduje to przeciek pamięci i problemy z blokadą.
  • Rozważ jak najszybsze usunięcie transakcji po zakończeniu zatwierdzania (zwłaszcza w przypadku korzystania z funkcji ConcurrentQueue).
  • Nie należy wykonywać żadnego kodu blokującego wewnątrz transakcji.
  • Gdy ciąg jest używany jako klucz dla niezawodnego słownika, kolejność sortowania używa domyślnego modułu porównywania ciągów CurrentCulture. Należy pamiętać, że kolejność sortowania CurrentCulture różni się od modułu porównania ciągów porządkowych.
  • Nie usuwaj ani nie anuluj transakcji zatwierdzającej. Nie jest to obsługiwane i może spowodować awarię procesu hosta.
  • Upewnij się, że kolejność operacji różnych słowników pozostaje taka sama dla wszystkich współbieżnych transakcji podczas odczytywania lub zapisywania wielu słowników, aby uniknąć zakleszczenia.

Oto kilka kwestii, o których warto pamiętać:

  • Domyślny limit czasu wynosi 4 sekundy dla wszystkich interfejsów API niezawodnej kolekcji. Większość użytkowników powinna używać domyślnego limitu czasu.
  • Domyślny token anulowania znajduje się CancellationToken.None we wszystkich interfejsach API reliable collections.
  • Parametr typu klucza (TKey) dla niezawodnego słownika musi poprawnie implementować GetHashCode() wartości i Equals(). Klucze muszą być niezmienne.
  • Aby uzyskać wysoką dostępność dla kolekcji Reliable Collections, każda usługa powinna mieć co najmniej docelowy i minimalny rozmiar zestawu replik 3.
  • Operacje odczytu w pomocniczej wersji mogą odczytywać wersje, które nie są zatwierdzane kworum. Oznacza to, że postęp wersji danych odczytywanych z pojedynczego pomocniczego elementu pomocniczego może być fałszywy. Odczyty z podstawowego są zawsze stabilne: nigdy nie może być w toku false.
  • Bezpieczeństwo/prywatność danych utrwalone przez aplikację w niezawodnej kolekcji to decyzja i podlega ochronie zapewnianej przez zarządzanie magazynem; Szyfrowanie dysków systemu operacyjnego może służyć do ochrony danych magazynowanych.
  • ReliableDictionary Wyliczenie używa posortowanej struktury danych uporządkowanej według klucza. Aby zapewnić wydajność wyliczania, zatwierdzenia są dodawane do tymczasowej tabeli skrótów, a później przenoszone do głównego posortowanego punktu kontrolnego struktury danych. Moduły Adds/Updates/Delete mają najlepsze przypadki środowiska uruchomieniowego O(1) i najgorszego przypadku środowiska uruchomieniowego O(log n), w przypadku sprawdzania poprawności obecności klucza. Pobieranie może mieć wartość O(1) lub O(log n) w zależności od tego, czy odczytujesz z ostatniego zatwierdzenia, czy ze starszego zatwierdzenia.

Dodatkowe wytyczne dotyczące nietrwałych kolekcji niezawodnych

Podczas podejmowania decyzji o użyciu nietrwałych niezawodnych kolekcji należy wziąć pod uwagę następujące kwestie:

  • ReliableDictionary ma nietrwałe wsparcie
  • ReliableQueue ma nietrwałe wsparcie
  • ReliableConcurrentQueue nie ma nietrwałej obsługi
  • Utrwalone usługi NIE MOGĄ być nietrwałe. Zmiana flagi HasPersistedState na false wymaga ponownego utworzenia całej usługi od podstaw
  • Nie można utrwalić nietrwałych usług. Zmiana flagi HasPersistedState na true wymaga ponownego utworzenia całej usługi od podstaw
  • HasPersistedState jest konfiguracją poziomu usługi. Oznacza to, że wszystkie kolekcje będą utrwalane lub nietrwałe. Nie można mieszać nietrwałych i utrwalanych kolekcji
  • Utrata kworum partycji nietrwałej powoduje całkowitą utratę danych
  • Tworzenie kopii zapasowej i przywracanie nie jest dostępne dla usług volatile

Następne kroki