Share via

Richtlijnen en aanbevelingen voor Reliable Collections in Azure Service Fabric

  • Artikel

Deze sectie bevat richtlijnen voor het gebruik van Reliable State Manager en Reliable Collections. Het doel is om gebruikers te helpen veelvoorkomende valkuilen te voorkomen.

Reliable Collection guildelines

De richtlijnen zijn ingedeeld als eenvoudige aanbevelingen voorafgegaan door de termen Do, Consider, Avoid en Do not.

  • Wijzig geen object van aangepast type dat wordt geretourneerd door leesbewerkingen (bijvoorbeeldTryPeekAsync).TryGetValueAsync Betrouwbare verzamelingen, net als gelijktijdige verzamelingen, retourneren een verwijzing naar de objecten en niet naar een kopie.
  • Kopieer het geretourneerde object van een aangepast type voordat u het wijzigt. Omdat structs en ingebouwde typen pass-by-value zijn, hoeft u er geen grondige kopie van uit te voeren, tenzij deze velden of eigenschappen bevatten die u wilt wijzigen.
  • Niet gebruiken TimeSpan.MaxValue voor time-outs. Time-outs moeten worden gebruikt om impasses te detecteren.
  • Gebruik geen transactie nadat deze is doorgevoerd, afgebroken of verwijderd.
  • Gebruik geen opsomming buiten het transactiebereik waarin deze is gemaakt.
  • Maak geen transactie binnen de instructie van using een andere transactie omdat deze impasses kan veroorzaken.
  • Maak geen betrouwbare status met IReliableStateManager.GetOrAddAsync en gebruik de betrouwbare status in dezelfde transactie. Dit resulteert in een InvalidOperationException.
  • Zorg ervoor dat uw IComparable<TKey> implementatie juist is. Het systeem is afhankelijk van IComparable<TKey> het samenvoegen van controlepunten en rijen.
  • Gebruik Updatevergrendeling bij het lezen van een item met de bedoeling het bij te werken om een bepaalde klasse impasses te voorkomen.
  • Overweeg om het aantal betrouwbare verzamelingen per partitie kleiner dan 1000 te houden. Geef de voorkeur aan Betrouwbare verzamelingen met meer items dan meer Betrouwbare verzamelingen met minder items.
  • Overweeg om uw items (bijvoorbeeld TKey + TValue voor betrouwbare woordenlijst) onder de 80 KBytes te houden: kleiner hoe beter. Dit vermindert de hoeveelheid heap-gebruik van grote objecten, evenals schijf- en netwerk-IO-vereisten. Vaak vermindert het repliceren van dubbele gegevens wanneer slechts één klein deel van de waarde wordt bijgewerkt. Een veelgebruikte manier om dit in Reliable Dictionary te bereiken, is door uw rijen in meerdere rijen te verbreken.
  • Overweeg het gebruik van back-up- en herstelfunctionaliteit voor herstel na noodgevallen.
  • Vermijd het combineren van bewerkingen met één entiteit en bewerkingen met meerdere entiteiten (bijvoorbeeld GetCountAsyncCreateEnumerableAsync) in dezelfde transactie vanwege de verschillende isolatieniveaus.
  • Do handle InvalidOperationException. Gebruikerstransacties kunnen om verschillende redenen door het systeem worden afgebroken. Als de rol van Reliable State Manager bijvoorbeeld wordt gewijzigd van primair of wanneer een langlopende transactie afkapping van het transactionele logboek blokkeert. In dergelijke gevallen kan de gebruiker InvalidOperationException ontvangen die aangeeft dat de transactie al is beëindigd. Ervan uitgaande dat de beëindiging van de transactie niet is aangevraagd door de gebruiker, kunt u deze uitzondering het beste afhandelen door de transactie te verwijderen, te controleren of het annuleringstoken is gesignaleerd (of de rol van de replica is gewijzigd) en als u geen nieuwe transactie maakt en het opnieuw probeert.
  • Pas geen parallelle of gelijktijdige bewerkingen toe binnen een transactie. Er wordt slechts één gebruikersthreadbewerking ondersteund binnen een transactie. Anders veroorzaakt dit geheugenlekken en vergrendelingsproblemen.
  • Overweeg de transactie zo snel mogelijk te verwijderen nadat het doorvoeren is voltooid (met name als u ConcurrentQueue gebruikt).
  • Voer geen blokkeringscode uit binnen een transactie.
  • Wanneer een tekenreeks wordt gebruikt als sleutel voor een betrouwbare woordenlijst, gebruikt de sorteervolgorde de standaardreeks comparer CurrentCulture. Houd er rekening mee dat de sorteervolgorde CurrentCulture verschilt van ordinale tekenreeksen vergelijken.
  • Een doorvoertransactie niet verwijderen of annuleren. Dit wordt niet ondersteund en kan het hostproces vastlopen.
  • Zorg ervoor dat de werkingsvolgorde van verschillende woordenlijsten hetzelfde blijft voor alle gelijktijdige transacties bij het lezen of schrijven van meerdere woordenlijsten om impasse te voorkomen.

Hier zijn een aantal zaken waar u rekening mee moet houden:

  • De standaardtime-out is 4 seconden voor alle Reliable Collection-API's. De meeste gebruikers moeten de standaardtime-out gebruiken.
  • Het standaardannuleringstoken bevindt zich CancellationToken.None in alle Reliable Collections-API's.
  • De parameter van het sleuteltype (TKey) voor een betrouwbare woordenlijst moet correct worden geïmplementeerd GetHashCode() en Equals(). Sleutels moeten onveranderbaar zijn.
  • Om hoge beschikbaarheid voor de Reliable Collections te bereiken, moet elke service ten minste een doel en minimale replicasetgrootte van 3 hebben.
  • Leesbewerkingen op de secundaire versie kunnen versies lezen die geen quorum zijn doorgevoerd. Dit betekent dat een versie van gegevens die uit één secundaire gegevens worden gelezen, mogelijk onwaar wordt uitgevoerd. Leesbewerkingen van primair zijn altijd stabiel: kan nooit onwaar worden uitgevoerd.
  • Beveiliging/privacy van de gegevens die door uw toepassing in een betrouwbare verzameling worden bewaard, is uw beslissing en onderhevig aan de beveiligingen die door uw opslagbeheer worden geboden; Schijfversleuteling van het besturingssysteem kan worden gebruikt om uw data-at-rest te beveiligen.
  • ReliableDictionary opsomming maakt gebruik van een gesorteerde gegevensstructuur gesorteerd op sleutel. Om opsomming efficiënt te maken, worden doorvoeringen toegevoegd aan een tijdelijke hashtabel en later verplaatst naar het belangrijkste gesorteerde gegevensstructuur na controlepunt. Adds/Updates/Deletes hebben de beste runtime van O(1) en slechtste runtime van O(log n), in het geval van validatiecontroles op de aanwezigheid van de sleutel. Dit kan O(1) of O(log n) zijn, afhankelijk van of u leest van een recente doorvoering of van een oudere doorvoering.

Aanvullende richtlijnen voor vluchtige betrouwbare verzamelingen

Houd rekening met het volgende wanneer u besluit vluchtige betrouwbare verzamelingen te gebruiken:

  • ReliableDictionary heeft vluchtige ondersteuning
  • ReliableQueue heeft vluchtige ondersteuning
  • ReliableConcurrentQueue heeft GEEN vluchtige ondersteuning
  • Persistente services kunnen niet vluchtig worden gemaakt. Als u de HasPersistedState vlag wijzigt, false moet u de hele service helemaal opnieuw maken
  • Vluchtige services kunnen niet persistent worden gemaakt. Als u de HasPersistedState vlag wijzigt, true moet u de hele service helemaal opnieuw maken
  • HasPersistedState is een configuratie op serviceniveau. Dit betekent dat ALLE verzamelingen behouden blijven of vluchtig zijn. U kunt vluchtige en persistente verzamelingen niet combineren
  • Quorumverlies van een vluchtige partitie resulteert in volledig gegevensverlies
  • Back-up en herstel is NIET beschikbaar voor vluchtige services

Volgende stappen