Dela via

Reliable Actors tillståndshantering

  • Artikel

Reliable Actors är entrådade objekt som kan kapsla in både logik och tillstånd. Eftersom aktörer körs på Reliable Services kan de upprätthålla tillståndet på ett tillförlitligt sätt med hjälp av samma mekanismer för beständighet och replikering. På så sätt förlorar aktörer inte sitt tillstånd efter fel, vid återaktivering efter skräpinsamling eller när de flyttas runt mellan noder i ett kluster på grund av resursutjämning eller uppgraderingar.

Tillståndsbeständighet och replikering

Alla Reliable Actors anses tillståndskänsliga eftersom varje aktörsinstans mappar till ett unikt ID. Det innebär att upprepade anrop till samma aktörs-ID dirigeras till samma aktörsinstans. I ett tillståndslöst system är klientanrop däremot inte garanterade att dirigeras till samma server varje gång. Därför är aktörstjänster alltid tillståndskänsliga tjänster.

Även om aktörer anses vara tillståndskänsliga betyder det inte att de måste lagra tillståndet på ett tillförlitligt sätt. Aktörer kan välja nivån för tillståndspersistence och replikering baserat på deras datalagringskrav:

  • Beständiga tillstånd: Tillståndet sparas på disken och replikeras till tre eller flera repliker. Beständiga tillstånd är det mest varaktiga tillståndslagringsalternativet, där tillståndet kan bevaras genom fullständigt klusteravbrott.
  • Flyktigt tillstånd: Tillståndet replikeras till tre eller flera repliker och sparas endast i minnet. Flyktigt tillstånd ger motståndskraft mot nodfel och aktörsfel samt under uppgraderingar och resursbalansering. Tillståndet sparas dock inte på disken. Så om alla repliker går förlorade samtidigt går även tillståndet förlorat.
  • Inget beständiga tillstånd: Tillstånd replikeras inte eller skrivs till disk, endast för aktörer som inte behöver underhålla tillståndet på ett tillförlitligt sätt.

Varje nivå av beständighet är helt enkelt en annan tillståndsprovider och replikeringskonfiguration för din tjänst. Om tillståndet skrivs till disken eller inte beror på tillståndsprovidern – komponenten i en tillförlitlig tjänst som lagrar tillstånd. Replikering beror på hur många repliker en tjänst distribueras med. Precis som med Reliable Services kan både tillståndsprovidern och antalet repliker enkelt ställas in manuellt. Aktörsramverket tillhandahåller ett attribut som, när det används på en aktör, automatiskt väljer en standardtillståndsprovider och automatiskt genererar inställningar för antal repliker för att uppnå någon av dessa tre beständighetsinställningar. Attributet StatePersistence ärvs inte av härledd klass. Varje aktörstyp måste ange sin StatePersistence-nivå.

Beständiga tillstånd

[StatePersistence(StatePersistence.Persisted)]
class MyActor : Actor, IMyActor
{
}

@StatePersistenceAttribute(statePersistence = StatePersistence.Persisted)
class MyActorImpl  extends FabricActor implements MyActor
{
}

Den här inställningen använder en tillståndsprovider som lagrar data på disken och automatiskt anger antalet tjänstrepliker till 3.

Flyktigt tillstånd

[StatePersistence(StatePersistence.Volatile)]
class MyActor : Actor, IMyActor
{
}

@StatePersistenceAttribute(statePersistence = StatePersistence.Volatile)
class MyActorImpl extends FabricActor implements MyActor
{
}

Den här inställningen använder en tillståndsprovider med endast minne och anger antalet repliker till 3.

Inget beständiga tillstånd

[StatePersistence(StatePersistence.None)]
class MyActor : Actor, IMyActor
{
}

@StatePersistenceAttribute(statePersistence = StatePersistence.None)
class MyActorImpl extends FabricActor implements MyActor
{
}

Den här inställningen använder en tillståndsprovider med endast minne och anger antalet repliker till 1.

Standardinställningar och genererade inställningar

När du använder StatePersistence attributet väljs en tillståndsprovider automatiskt åt dig vid körning när aktörstjänsten startar. Antalet repliker anges dock vid kompileringstid av Visual Studio-aktörens byggverktyg. Byggverktygen genererar automatiskt en standardtjänst för aktörstjänsten i ApplicationManifest.xml. Parametrar skapas för minsta replikuppsättningsstorlek och målreplikuppsättningsstorlek.

Du kan ändra dessa parametrar manuellt. Men varje gång StatePersistence attributet ändras anges parametrarna till standardvärdet för replikuppsättningens storlek för det valda StatePersistence attributet, vilket överskrider alla tidigare värden. Med andra ord åsidosätts de värden som du anger i ServiceManifest.xml endast vid byggtiden när du ändrar StatePersistence attributvärdet.

<ApplicationManifest xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" ApplicationTypeName="Application12Type" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
   <Parameters>
      <Parameter Name="MyActorService_PartitionCount" DefaultValue="10" />
      <Parameter Name="MyActorService_MinReplicaSetSize" DefaultValue="3" />
      <Parameter Name="MyActorService_TargetReplicaSetSize" DefaultValue="3" />
   </Parameters>
   <ServiceManifestImport>
      <ServiceManifestRef ServiceManifestName="MyActorPkg" ServiceManifestVersion="1.0.0" />
   </ServiceManifestImport>
   <DefaultServices>
      <Service Name="MyActorService" GeneratedIdRef="77d965dc-85fb-488c-bd06-c6c1fe29d593|Persisted">
         <StatefulService ServiceTypeName="MyActorServiceType" TargetReplicaSetSize="[MyActorService_TargetReplicaSetSize]" MinReplicaSetSize="[MyActorService_MinReplicaSetSize]">
            <UniformInt64Partition PartitionCount="[MyActorService_PartitionCount]" LowKey="-9223372036854775808" HighKey="9223372036854775807" />
         </StatefulService>
      </Service>
   </DefaultServices>
</ApplicationManifest>

Tillståndshanterare

Varje aktörsinstans har en egen tillståndshanterare: en ordlisteliknande datastruktur som lagrar nyckel/värde-par på ett tillförlitligt sätt. Tillståndshanteraren är en omslutning runt en tillståndsprovider. Du kan använda den för att lagra data oavsett vilken beständighetsinställning som används. Det ger inga garantier för att en aktörstjänst som körs kan ändras från en instabil (endast minnesintern) tillståndsinställning till en bevarad tillståndsinställning via en löpande uppgradering samtidigt som data bevaras. Det går dock att ändra antalet repliker för en tjänst som körs.

Tillståndshanterarens nycklar måste vara strängar. Värden är generiska och kan vara valfri typ, inklusive anpassade typer. Värden som lagras i tillståndshanteraren måste vara seriellt för datakontrakt eftersom de kan överföras via nätverket till andra noder under replikeringen och kan skrivas till disk, beroende på en aktörs inställning för tillståndsbeständighet.

Tillståndshanteraren exponerar vanliga ordlistemetoder för att hantera tillstånd, liknande dem som finns i Reliable Dictionary.

Exempel på hantering av aktörstillstånd finns i Åtkomst, spara och ta bort Reliable Actors-tillstånd.

Bästa praxis

Här följer några föreslagna metoder och felsökningstips för att hantera aktörstillståndet.

Gör aktörstillståndet så detaljerat som möjligt

Detta är viktigt för programmets prestanda och resursanvändning. När det finns någon skrivning/uppdatering av "namngivet tillstånd" för en aktör serialiseras hela värdet som motsvarar det "namngivna tillståndet" och skickas via nätverket till de sekundära replikerna. Sekundärfilerna skriver den till den lokala disken och svarar tillbaka på den primära repliken. När den primära tar emot bekräftelser från ett kvorum med sekundära repliker skriver den tillståndet till sin lokala disk. Anta till exempel att värdet är en klass som har 20 medlemmar och en storlek på 1 MB. Även om du bara har ändrat en av klassmedlemmarna, som är av storlek 1 KB, får du betala kostnaden för serialisering och nätverks- och diskskrivningar för hela 1 MB. Om värdet på samma sätt är en samling (till exempel en lista, matris eller ordlista) betalar du kostnaden för hela samlingen även om du ändrar en av dess medlemmar. StateManager-gränssnittet för aktörsklassen är som en ordlista. Du bör alltid modellera datastrukturen som representerar aktörstillståndet ovanpå den här ordlistan.

Hantera aktörens livscykel korrekt

Du bör ha en tydlig princip för att hantera tillståndets storlek i varje partition i en aktörstjänst. Aktörstjänsten bör ha ett fast antal aktörer och återanvända dem så mycket som möjligt. Om du kontinuerligt skapar nya aktörer måste du ta bort dem när de är klara med sitt arbete. Aktörsramverket lagrar vissa metadata om varje aktör som finns. Om du tar bort alla tillstånd för en aktör tas inte metadata om den aktören bort. Du måste ta bort aktören (se ta bort aktörer och deras tillstånd) för att ta bort all information om den som lagras i systemet. Som en extra kontroll bör du fråga aktörstjänsten (se räkna upp aktörer) då och då för att se till att antalet aktörer ligger inom det förväntade intervallet.

Om du ser att databasfilstorleken för en aktörstjänst ökar utöver den förväntade storleken kontrollerar du att du följer riktlinjerna ovan. Om du följer dessa riktlinjer och fortfarande har problem med databasfilens storlek bör du öppna ett supportärende med produktteamet för att få hjälp.

Nästa steg

Tillstånd som lagras i Reliable Actors måste serialiseras innan det skrivs till disken och replikeras för hög tillgänglighet. Läs mer om serialisering av aktörstyp.

Läs sedan mer om aktörsdiagnostik och prestandaövervakning.