Dela via

Reliable Actors tillståndshantering

  • Artikel

Reliable Actors är entrådiga 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 vara 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 det däremot inte säkert att klientanrop dirigeras till samma server varje gång. Av den anledningen ä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å av tillståndspersistens och replikering baserat på deras datalagringskrav:

  • Beständiga tillstånd: Tillståndet sparas på disken och replikeras till tre eller fler repliker. Beständiga tillstånd är det mest hållbara lagringsalternativet, där tillståndet kan bevaras genom fullständigt klusteravbrott.
  • Flyktigt tillstånd: Tillståndet replikeras till tre eller flera repliker och sparas bara i minnet. Flyktigt tillstånd ger motståndskraft mot nodfel och aktörsfel samt under uppgraderingar och resursutjämning. 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. Huruvida tillstånd skrivs till disk eller inte beror på tillståndsprovidern – komponenten i en tillförlitlig tjänst som lagrar tillstånd. Replikeringen 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 anges 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å en av dessa tre beständighetsinställningar. Attributet StatePersistence ärvs inte av den härledda klassen. 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 anger automatiskt 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 endast i minnet 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 som endast är minnesintern och anger antalet repliker till 1.

Standardinställningar och genererade inställningar

När du använder StatePersistence attributet väljs automatiskt en tillståndsprovider åt dig vid körning när aktörstjänsten startar. Antalet repliker anges dock vid kompileringstiden 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 åsidosätter 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 sin 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 icke-beständiga tillståndsinställning (endast minnesintern) till en beständig 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 serialiserbara 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, ungefär som de 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 aktörens "namngivna tillstånd" 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 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 har storleken 1 kB betalar du i slutändan 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 storleken på tillståndet 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 status 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 de föregående riktlinjerna. Om du följer dessa riktlinjer och fortfarande har problem med databasfilens storlek bör du öppna ett supportärende hos 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.