Sdílet prostřednictvím

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

  • Článek

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.

Reliable Collection guildelines

Pokyny jsou uspořádané jako jednoduchá doporučení s předponou Termíny Do, Zvažte, Vyhněte se a Ne.

  • 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 jsou pass-by-value, nemusíte s nimi provádět hloubkovou kopii, pokud neobsahují pole nebo vlastnosti typu odkaz, které chcete upravit.
  • TimeSpan.MaxValue Nepoužívejte pro časové limity. K detekci zablokování by měly být použity časové limity.
  • Po potvrzení, přerušení nebo vyřazení nepoužívejte transakci.
  • Nepoužívejte výčet mimo obor transakce, ve které byl vytvořen.
  • Nevytvořte transakci v rámci příkazu jiné transakce using , protože může způsobit zablokování.
  • Nevytvádřujte spolehlivý stav se IReliableStateManager.GetOrAddAsync stejnou transakcí a nepoužívejte spolehlivý stav. Výsledkem je invalidOperationException.
  • Ujistěte se, že je vaše IComparable<TKey> implementace správná. Systém závisí na IComparable<TKey> 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, 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.
  • Zpracovat 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 odstranit transakci, zkontrolujte, zda byl token zrušení signalizován (nebo role repliky byla změněna), a pokud nevytvoří novou transakci a opakovat.
  • 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í nevracení paměti a problémy se zámkem.
  • 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 se řetězec používá jako klíč pro spolehlivý slovník, pořadí řazení používá výchozí porovnávač řetězců CurrentCulture. Všimněte si, že pořadí řazení CurrentCulture se liší od porovnávače řadových řetězců.
  • Nelikvidujte ani nerušte potvrzení transakce. Toto není podporováno a mohlo by dojít k chybě 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 spolehlivé kolekce. 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 spolehlivých kolekcí, každá služba by měla mít alespoň cílovou a minimální velikost repliky 3.
  • Operace čtení na sekundárním serveru mohou číst verze, které nejsou potvrzeny kvorem. To znamená, že u verze dat, která se čtou z jedné sekundární, může dojít k nepravdivému průběhu. Č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í, přidají se potvrzení do dočasné hashtable a později se přesunou do hlavní seřazené datové struktury po kontrolním bodu. Moduly adds/Aktualizace/Delete mají v případě ověření přítomnosti klíče nejlepší modul runtime O(1) a modul runtime nejhoršího případu 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 volatilní 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 vytvořit zachované. 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 nestálého oddílu způsobí úplnou ztrátu dat.
  • Zálohování a obnovení není dostupné pro nestálé služby

Další kroky