Sdílet prostřednictvím

Pokyny a doporučení pro spolehlivé kolekce v Azure Service Fabric

Tato část obsahuje pokyny pro používání Reliable State Manageru a spolehlivých kolekcí. Cílem je pomoct uživatelům vyhnout se běžným nástrahám.

Pokyny pro spolehlivé shromažďování

Pokyny jsou uspořádané jako jednoduchá doporučení s výrazy Do, Zvažte, Vyhněte se a Nedělejte.

  • Neupravujte objekt vlastního typu vráceného operacemi čtení (například TryPeekAsyncTryGetValueAsync). Spolehlivé kolekce, stejně jako Souběžné kolekce, vrací odkaz na objekty a ne kopii.
  • Před úpravou do hloubky zkopírujte vrácený objekt vlastního typu. Vzhledem k tomu, že struktury a předdefinované typy se předávají hodnotou, nemusíte je kopírovat do hloubky, s výjimkou případů, kdy obsahují pole nebo vlastnosti odkazového typu, které chcete upravit.
  • TimeSpan.MaxValue nepoužívejte pro časové limity. K detekci zablokování by měly být použity časové limity.
  • Jakmile byla transakce potvrzena, zrušena nebo odstraněna, nepoužívejte ji.
  • Nepoužívejte výčet mimo obor transakce, ve které byl vytvořen.
  • Nevytvořte transakci v rámci příkazu using jiné transakce, protože to může způsobit vznik zablokování.
  • Nevytvářejte spolehlivý stav pomocí IReliableStateManager.GetOrAddAsync a nepoužívejte tento spolehlivý stav ve stejné transakci. Výsledkem je invalidOperationException.
  • Ujistěte se, že je vaše IComparable<TKey> implementace správná. Systém závisí na IComparable<TKey> při slučování kontrolních bodů a řádků.
  • Zámek aktualizace použijte při čtení položky se záměrem ji aktualizovat, aby se zabránilo určité třídě zablokování.
  • Zvažte zachování počtu spolehlivých kolekcí na oddíl tak, aby byl menší než 1 000. Upřednostňujte spolehlivé kolekce s více položkami oproti spolehlivějším kolekcím s menším počtem položek.
  • Zvažte zachování položek (například TKey + TValue pro Reliable Dictionary) pod 80 KBytes: menší tím lépe. Tím se sníží využití haldy velkých objektů a také požadavky na vstupně-výstupní operace disku a sítě. Často snižuje replikaci duplicitních dat, když se aktualizuje jenom jedna malá část hodnoty. Běžným způsobem, jak toho dosáhnout ve Spolehlivém slovníku, je rozdělit řádky na více řádků.
  • Zvažte použití funkcí zálohování a obnovení k zotavení po havárii.
  • Vyhněte se kombinování operací s jednou entitou a operací s více entitou (napřGetCountAsyncCreateEnumerableAsync. ) ve stejné transakci kvůli různým úrovním izolace.
  • Zpracujte InvalidOperationException. Uživatelské transakce může systém přerušit z různých důvodů. Například když Správce spolehlivého stavu mění svou roli z primární nebo když dlouhotrvající transakce blokuje zkrácení transakčního protokolu. V takových případech může uživatel obdržet InvalidOperationException označující, že jejich transakce již byla ukončena. Za předpokladu, že ukončení transakce nebylo požadováno uživatelem, nejlepším způsobem, jak tuto výjimku zpracovat, je zrušit transakci, zkontrolovat, zda byl token zrušení signalizován (nebo zda došlo ke změně role repliky), a pokud ne, vytvořit novou transakci a zopakovat pokus.
  • Nepoužívejte paralelní ani souběžné operace v rámci transakce. V rámci transakce je podporována pouze jedna operace vlákna uživatele. Jinak způsobí únik paměti a problémy se zámky.
  • Po dokončení potvrzení zvažte odstranění transakce (zejména pokud používáte ConcurrentQueue).
  • Neprovádějte žádný blokující kód uvnitř transakce.
  • Pokud je řetězec používán jako klíč pro slovník, pořadí řazení využívá výchozího porovnávače řetězců CurrentCulture. Všimněte si, že třídení CurrentCulture se liší od ordinalního porovnávače řetězců.
  • Nelikvidujte ani nerušte probíhající transakci. Toto není podporováno a mohlo by způsobit pád hostitelského procesu.
  • Ujistěte se, že pořadí operací různých slovníků zůstává stejné pro všechny souběžné transakce při čtení nebo zápisu více slovníků, abyste se vyhnuli vzájemnému zablokování.

Tady je několik věcí, které je potřeba mít na paměti:

  • Výchozí časový limit je 4 sekundy pro všechna rozhraní API Reliable Collection. Většina uživatelů by měla použít výchozí časový limit.
  • Výchozí token zrušení je CancellationToken.None ve všech rozhraních API Reliable Collections.
  • Parametr typu klíče (TKey) pro Reliable Dictionary musí správně implementovat GetHashCode() a Equals(). Klíče musí být neměnné.
  • Aby bylo možné dosáhnout vysoké dostupnosti pro Spolehlivé kolekce, každá služba by měla mít alespoň cílovou a minimální velikost sady replik ve výši 3.
  • Operace čtení na sekundárním serveru mohou číst verze, které nejsou potvrzeny kvorem. To znamená, že verze dat, která se čtou z jedné sekundární repliky, může vykazovat nesprávný vývoj. Čtení z primárního serveru jsou vždy stabilní: nelze nikdy považovat za nepravdivé.
  • Zabezpečení a ochrana osobních údajů dat uchováných vaší aplikací ve spolehlivé kolekci je vaše rozhodnutí a podléhá ochraně poskytovaným správou úložiště; Šifrování disku operačního systému se dá použít k ochraně neaktivních uložených dat.
  • ReliableDictionary Výčet používá seřazenou datovou strukturu seřazenou podle klíče. Aby byl výčet efektivní, commity se přidají do dočasné vyhledávací tabulky a později se přesunou do hlavní seřazené datové struktury po dosažení kontrolního bodu. Moduly adds/Updates/Delete mají v případě ověření přítomnosti klíče nejlepší modul runtime O(1) a modul runtime nejhorších případů V(log n). Může to být O(1) nebo O(log n) v závislosti na tom, jestli čtete z posledního potvrzení nebo ze staršího potvrzení.

Další pokyny pro nestálé spolehlivé kolekce

Při rozhodování o používání nestálých spolehlivých kolekcí zvažte následující:

  • ReliableDictionary má volatilní podporu
  • ReliableQueue má volatilní podporu
  • ReliableConcurrentQueue nemá volatilní podporu
  • Trvalé služby nemohou být nestálé. Změna příznaku HasPersistedState tak, aby false vyžadovala opětovné vytvoření celé služby od začátku
  • Nestálé služby nelze trvale uložit. Změna příznaku HasPersistedState tak, aby true vyžadovala opětovné vytvoření celé služby od začátku
  • HasPersistedState je konfigurace na úrovni služby. To znamená, že všechny kolekce budou buď trvalé, nebo nestálé. Nedají se kombinovat nestálé a trvalé kolekce
  • Ztráta kvora volatilního oddílu způsobí úplnou ztrátu dat.
  • Zálohování a obnovení není dostupné pro nestálé služby

Další kroky