Dela via

Riktlinjer och rekommendationer för tillförlitliga samlingar i Azure Service Fabric

  • Artikel

Det här avsnittet innehåller riktlinjer för användning av Reliable State Manager och Reliable Collections. Målet är att hjälpa användarna att undvika vanliga fallgropar.

Reliable Collection guildelines

Riktlinjerna är ordnade som enkla rekommendationer som prefixet med termerna Do, Consider, Avoid och Do not.

  • Ändra inte ett objekt av anpassad typ som returneras av läsåtgärder (till exempel TryPeekAsync eller TryGetValueAsync). Tillförlitliga samlingar, precis som samtidiga samlingar, returnerar en referens till objekten och inte en kopia.
  • Kopiera det returnerade objektet av en anpassad typ innan du ändrar det. Eftersom structs och inbyggda typer är direktvärde behöver du inte göra en djupkopia på dem om de inte innehåller referenstypade fält eller egenskaper som du tänker ändra.
  • Använd inte TimeSpan.MaxValue för timeouter. Tidsgränser ska användas för att identifiera dödlägen.
  • Använd inte en transaktion när den har checkats in, avbrutits eller tagits bort.
  • Använd inte en uppräkning utanför transaktionsomfånget som den skapades i.
  • Skapa inte en transaktion i en annan transaktions using -instruktion eftersom det kan orsaka dödlägen.
  • Skapa inte tillförlitligt tillstånd med IReliableStateManager.GetOrAddAsync och använd det tillförlitliga tillståndet i samma transaktion. Detta resulterar i en InvalidOperationException.
  • Se till att implementeringen IComparable<TKey> är korrekt. Systemet är beroende IComparable<TKey> av sammanslagning av kontrollpunkter och rader.
  • Använd Uppdateringslås när du läser ett objekt med avsikt att uppdatera det för att förhindra en viss klass av dödlägen.
  • Överväg att behålla antalet tillförlitliga samlingar per partition till mindre än 1 000. Föredrar Tillförlitliga samlingar med fler objekt än mer tillförlitliga samlingar med färre objekt.
  • Överväg att hålla dina objekt (till exempel TKey + TValue för Reliable Dictionary) under 80 KByte: mindre desto bättre. Detta minskar mängden användning av stora objekts heap samt disk- och nätverks-I/O-krav. Ofta minskar replikeringen av duplicerade data när endast en liten del av värdet uppdateras. Ett vanligt sätt att uppnå detta i Reliable Dictionary är att dela upp raderna i flera rader.
  • Överväg att använda säkerhetskopierings- och återställningsfunktioner för haveriberedskap.
  • Undvik att blanda enstaka entitetsåtgärder och åtgärder med flera entiteter (t.ex GetCountAsync. , CreateEnumerableAsync) i samma transaktion på grund av de olika isoleringsnivåerna.
  • Hantera InvalidOperationException. Användartransaktioner kan avbrytas av systemet av olika orsaker. Till exempel när Reliable State Manager ändrar sin roll från Primär eller när en tidskrävande transaktion blockerar trunkering av transaktionsloggen. I sådana fall kan användaren få InvalidOperationException som anger att deras transaktion redan har avslutats. Förutsatt att avslutningen av transaktionen inte begärdes av användaren, är det bästa sättet att hantera det här undantaget att ta bort transaktionen, kontrollera om annulleringstoken har signalerats (eller om replikens roll har ändrats) och om inte skapa en ny transaktion och försöka igen.
  • Använd inte parallella eller samtidiga åtgärder i en transaktion. Endast en användartrådsåtgärd stöds i en transaktion. Annars orsakar det problem med minnesläckage och lås.
  • Överväg att avyttra transaktionen så snart som möjligt när incheckningen har slutförts (särskilt om du använder ConcurrentQueue).
  • Utför inte någon blockerande kod i en transaktion.
  • När strängen används som nyckel för en tillförlitlig ordlista använder sorteringsordningen standardsträngsjäxeraren CurrentCulture. Observera att sorteringsordningen CurrentCulture skiljer sig från jämförelsen av ordningstalssträngar.
  • Ta inte bort eller avbryt inte en incheckningstransaktion. Detta stöds inte och kan krascha värdprocessen.
  • Se till att åtgärdsordningen för olika ordlistor förblir densamma för alla samtidiga transaktioner när du läser eller skriver flera ordlistor för att undvika dödläge.

Här följer några saker att tänka på:

  • Standardtimeouten är 4 sekunder för alla API:er för reliable collection. De flesta användare bör använda standardtimeouten.
  • Standardtoken för annullering finns CancellationToken.None i alla API:er för Reliable Collections.
  • Nyckeltypsparametern (TKey) för en tillförlitlig ordlista måste implementera GetHashCode() och Equals(). Nycklar måste vara oföränderliga.
  • För att uppnå hög tillgänglighet för Reliable Collections bör varje tjänst ha minst en mål- och minsta replikuppsättningsstorlek på 3.
  • Läsåtgärder på den sekundära kan läsa versioner som inte är kvorum-incheckade. Det innebär att en version av data som läss från en enda sekundär kan vara falsk. Läsningar från Primär är alltid stabila: kan aldrig vara falska förlopp.
  • Säkerhet/sekretess för data som sparas av ditt program i en tillförlitlig samling är ditt beslut och omfattas av de skydd som tillhandahålls av din lagringshantering; Dvs. Diskkryptering av operativsystem kan användas för att skydda dina vilande data.
  • ReliableDictionary uppräkning använder en sorterad datastruktur sorterad efter nyckel. För att göra uppräkning effektiv läggs incheckningar till i en tillfällig hashtable och flyttas senare till den huvudsakliga sorterade datastrukturen efter kontrollpunkten. Tillägg/Uppdateringar/borttagningar har bästa möjliga körning av O(1) och värsta fall-körning av O(log n), vid valideringskontroller av förekomsten av nyckeln. Hämtar kan vara O(1) eller O(log n) beroende på om du läser från en incheckning nyligen eller från en äldre incheckning.

Ytterligare riktlinjer för flyktiga tillförlitliga samlingar

När du bestämmer dig för att använda flyktiga tillförlitliga samlingar bör du tänka på följande:

  • ReliableDictionary har flyktigt stöd
  • ReliableQueue har flyktigt stöd
  • ReliableConcurrentQueue har INTE flyktigt stöd
  • Beständiga tjänster kan inte göras flyktiga. Om du HasPersistedState ändrar flaggan till false måste hela tjänsten återskapas från grunden
  • Det går inte att spara flyktiga tjänster. Om du HasPersistedState ändrar flaggan till true måste hela tjänsten återskapas från grunden
  • HasPersistedState är en konfiguration på servicenivå. Det innebär att ALLA samlingar antingen bevaras eller är flyktiga. Du kan inte blanda flyktiga och bevarade samlingar
  • Kvorumförlust av en flyktig partition resulterar i fullständig dataförlust
  • Säkerhetskopiering och återställning är INTE tillgängligt för flyktiga tjänster

Nästa steg