Delen via


Reliable Actors state management

Reliable Actors zijn objecten met één thread die zowel logica als status kunnen inkapselen. Omdat actoren worden uitgevoerd op Reliable Services, kunnen ze de status betrouwbaar onderhouden met behulp van dezelfde persistentie- en replicatiemechanismen. Op deze manier verliezen actoren hun status niet na fouten, bij opnieuw activeren na garbagecollection of wanneer ze worden verplaatst tussen knooppunten in een cluster vanwege resourceverdeling of upgrades.

Statuspersistentie en replicatie

Alle Reliable Actors worden beschouwd als stateful omdat elk actorexemplaren wordt toegewezen aan een unieke id. Dit betekent dat herhaalde aanroepen naar dezelfde actor-id worden doorgestuurd naar hetzelfde actorexemplaren. In een staatloos systeem daarentegen worden clientoproepen niet steeds naar dezelfde server gerouteerd. Daarom zijn actorservices altijd stateful services.

Hoewel actoren als stateful worden beschouwd, betekent dat niet dat ze de status betrouwbaar moeten opslaan. Actoren kunnen het niveau van statuspersistentie en replicatie kiezen op basis van hun vereisten voor gegevensopslag:

  • Persistente status: status blijft behouden op schijf en wordt gerepliceerd naar drie of meer replica's. Persistente status is de meest duurzame opslagoptie voor status, waarbij de status kan blijven bestaan door volledige clusterstoring.
  • Vluchtige status: status wordt gerepliceerd naar drie of meer replica's en wordt alleen in het geheugen bewaard. Vluchtige status biedt tolerantie tegen knooppuntfouten en actorfouten, en tijdens upgrades en resourceverdeling. De status wordt echter niet op schijf bewaard. Dus als alle replica's tegelijk verloren gaan, gaat de status ook verloren.
  • Geen persistente status: status wordt niet gerepliceerd of naar schijf geschreven, alleen gebruikt voor actoren die de status niet betrouwbaar hoeven te onderhouden.

Elk persistentieniveau is gewoon een andere statusprovider en replicatieconfiguratie van uw service. Of de status al dan niet naar de schijf wordt geschreven, is afhankelijk van de statusprovider van het onderdeel in een betrouwbare service waarin de status wordt opgeslagen. Replicatie is afhankelijk van het aantal replica's waarmee een service wordt geïmplementeerd. Net als bij Reliable Services kunnen zowel de statusprovider als het aantal replica's eenvoudig handmatig worden ingesteld. Het actorframework biedt een kenmerk dat, wanneer deze wordt gebruikt voor een actor, automatisch een standaardstatusprovider selecteert en automatisch instellingen voor het aantal replica's genereert om een van deze drie persistentie-instellingen te bereiken. Het kenmerk StatePersistence wordt niet overgenomen door afgeleide klasse. Elk actortype moet het statePersistence-niveau opgeven.

Persistente status

[StatePersistence(StatePersistence.Persisted)]
class MyActor : Actor, IMyActor
{
}
@StatePersistenceAttribute(statePersistence = StatePersistence.Persisted)
class MyActorImpl  extends FabricActor implements MyActor
{
}

Deze instelling maakt gebruik van een statusprovider die gegevens op schijf opslaat en het aantal servicereplica's automatisch instelt op 3.

Vluchtige toestand

[StatePersistence(StatePersistence.Volatile)]
class MyActor : Actor, IMyActor
{
}
@StatePersistenceAttribute(statePersistence = StatePersistence.Volatile)
class MyActorImpl extends FabricActor implements MyActor
{
}

Deze instelling maakt gebruik van een alleen-geheugenstatusprovider en stelt het aantal replica's in op 3.

Geen persistente status

[StatePersistence(StatePersistence.None)]
class MyActor : Actor, IMyActor
{
}
@StatePersistenceAttribute(statePersistence = StatePersistence.None)
class MyActorImpl extends FabricActor implements MyActor
{
}

Deze instelling maakt gebruik van een alleen-geheugenstatusprovider en stelt het aantal replica's in op 1.

Standaardinstellingen en gegenereerde instellingen

Wanneer u het StatePersistence kenmerk gebruikt, wordt tijdens runtime automatisch een statusprovider voor u geselecteerd wanneer de actorservice wordt gestart. Het aantal replica's wordt echter tijdens het compileren ingesteld door de buildhulpprogramma's van Visual Studio Actor. De buildhulpprogramma's genereren automatisch een standaardservice voor de actorservice in ApplicationManifest.xml. Parameters worden gemaakt voor minimale grootte van de replicaset en de grootte van de doelreplicaset.

U kunt deze parameters handmatig wijzigen. Telkens wanneer het StatePersistence kenmerk wordt gewijzigd, worden de parameters echter ingesteld op de standaardwaarden voor de grootte van de replicaset voor het geselecteerde StatePersistence kenmerk, waarbij eventuele eerdere waarden worden overschreven. Met andere woorden, de waarden die u hebt ingesteld in ServiceManifest.xml worden alleen overschreven tijdens het bouwen wanneer u de StatePersistence kenmerkwaarde wijzigt.

<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>

Statusmanager

Elk actorexemplaren heeft een eigen statusbeheerder: een woordenlijstachtige gegevensstructuur waarmee sleutel-waardeparen betrouwbaar worden opgeslagen. De statusbeheerder is een wrapper rond een statusprovider. U kunt deze gebruiken om gegevens op te slaan, ongeacht welke persistentie-instelling wordt gebruikt. Het biedt geen enkele garantie dat een actieve actorservice kan worden gewijzigd van een vluchtige statusinstelling (alleen in het geheugen) naar een persistente statusinstelling via een rolling upgrade terwijl gegevens behouden blijven. Het is echter mogelijk om het aantal replica's voor een actieve service te wijzigen.

Statusbeheersleutels moeten tekenreeksen zijn. Waarden zijn algemeen en kunnen elk type zijn, inclusief aangepaste typen. Waarden die zijn opgeslagen in de statusbeheerder moeten serializeerbaar zijn omdat ze tijdens de replicatie via het netwerk naar andere knooppunten kunnen worden verzonden en naar schijf kunnen worden geschreven, afhankelijk van de statuspersistentie-instelling van een actor.

De statusbeheerder maakt algemene woordenlijstmethoden beschikbaar voor het beheren van de status, vergelijkbaar met die in Reliable Dictionary.

Voor voorbeelden van het beheren van de actorstatus leest u de status Reliable Actors, leest u Access, slaat u op en verwijdert u de status Reliable Actors.

Aanbevolen procedures

Hier volgen enkele voorgestelde procedures en tips voor probleemoplossing voor het beheren van uw actorstatus.

De actorstatus zo gedetailleerd mogelijk maken

Dit is essentieel voor prestaties en resourcegebruik van uw toepassing. Wanneer er schrijf-/updatebewerkingen zijn naar de 'benoemde status' van een actor, wordt de volledige waarde die overeenkomt met die 'benoemde status' geserialiseerd en via het netwerk naar de secundaire replica's verzonden. De secundaire bestanden schrijven deze naar de lokale schijf en reageren op de primaire replica. Wanneer de primaire instantie bevestigingen ontvangt van een quorum van secundaire replica's, wordt de status naar de lokale schijf geschreven. Stel dat de waarde een klasse is met 20 leden en een grootte van 1 MB. Zelfs als u slechts een van de klasseleden hebt gewijzigd van grootte 1 kB, betaalt u uiteindelijk de kosten van serialisatie en schrijfbewerkingen voor het netwerk en de schijf voor de volledige 1 MB. Als de waarde een verzameling is (zoals een lijst, matrix of woordenlijst), betaalt u de kosten voor de volledige verzameling, zelfs als u een van de leden wijzigt. De StateManager-interface van de actorklasse lijkt op een woordenlijst. U moet altijd de gegevensstructuur modelleren die de actorstatus vertegenwoordigt boven op deze woordenlijst.

De levenscyclus van de actor correct beheren

U moet duidelijk beleid hebben over het beheren van de grootte van de status in elke partitie van een actorservice. Uw actorservice moet een vast aantal actoren hebben en ze zoveel mogelijk opnieuw gebruiken. Als u voortdurend nieuwe acteurs maakt, moet u ze verwijderen zodra ze klaar zijn met hun werk. In het actorframework worden enkele metagegevens opgeslagen over elke actor die bestaat. Als u alle status van een actor verwijdert, worden geen metagegevens over die actor verwijderd. U moet de actor verwijderen (zie actoren en hun status verwijderen) om alle informatie over de actor te verwijderen die in het systeem is opgeslagen. Als extra controle moet u een query uitvoeren op de actorservice (zie acteurs inventariseren) eenmaal in een tijdje om ervoor te zorgen dat het aantal acteurs binnen het verwachte bereik valt.

Als u ooit ziet dat de databasebestandsgrootte van een Actor-service groter is dan de verwachte grootte, controleert u of u de voorgaande richtlijnen volgt. Als u deze richtlijnen volgt en nog steeds problemen ondervindt met de bestandsgrootte van de database, moet u een ondersteuningsticket openen bij het productteam om hulp te krijgen.

Volgende stappen

De status die is opgeslagen in Reliable Actors, moet worden geserialiseerd voordat deze naar de schijf wordt geschreven en gerepliceerd voor hoge beschikbaarheid. Meer informatie over serialisatie van actortypen.

Hierna vindt u meer informatie over diagnostische gegevens van actor en prestatiebewaking.