Udostępnij za pośrednictwem


Zarządzanie stanem elementów Reliable Actors

Element Reliable Actors to jednowątkowy obiekt, który może hermetyzować zarówno logikę, jak i stan. Ponieważ aktorzy działają w usługach Reliable Services, mogą niezawodnie utrzymywać stan przy użyciu tych samych mechanizmów trwałości i replikacji. W ten sposób aktorzy nie tracą stanu po awarii, po ponownym aktywowaniu po odśmiecaniu pamięci lub po przeniesieniu między węzłami w klastrze z powodu równoważenia zasobów lub uaktualnień.

Trwałość stanu i replikacja

Wszystkie elementy Reliable Actors są uznawane za stanowe , ponieważ każde wystąpienie aktora jest mapowane na unikatowy identyfikator. Oznacza to, że powtarzające się wywołania tego samego identyfikatora aktora są kierowane do tego samego wystąpienia aktora. W systemie bezstanowym wywołania klienta nie są jednak zawsze kierowane do tego samego serwera. Z tego powodu usługi aktorów są zawsze usługami stanowymi.

Mimo że aktorzy są uważane za stanowe, nie oznacza to, że muszą niezawodnie przechowywać stan. Aktorzy mogą wybrać poziom trwałości stanu i replikacji na podstawie wymagań dotyczących magazynu danych:

  • Stan utrwalony: stan jest utrwalany na dysku i jest replikowany do co najmniej trzech replik. Stan utrwalone to najbardziej trwała opcja magazynu stanu, w której stan może być utrwalany w przypadku całkowitej awarii klastra.
  • Stan nietrwały: stan jest replikowany do co najmniej trzech replik i jest przechowywany tylko w pamięci. Stan volatile zapewnia odporność na awarię węzła i awarię aktora oraz podczas uaktualniania i równoważenia zasobów. Jednak stan nie jest utrwalany na dysku. Dlatego jeśli wszystkie repliki zostaną utracone jednocześnie, stan również zostanie utracony.
  • Brak stanu utrwalonego: stan nie jest replikowany ani zapisywany na dysku, tylko w przypadku aktorów, którzy nie muszą niezawodnie utrzymywać stanu.

Każdy poziom trwałości jest po prostu innym dostawcą stanu i konfiguracją replikacji usługi. Niezależnie od tego, czy stan jest zapisywany na dysku, zależy od dostawcy stanu — składnika w niezawodnej usłudze, która przechowuje stan. Replikacja zależy od liczby replik wdrażanych w usłudze. Podobnie jak w przypadku usług Reliable Services, zarówno dostawca stanu, jak i liczba replik można łatwo ustawić ręcznie. Platforma aktora udostępnia atrybut, który w przypadku użycia na aktorze automatycznie wybiera domyślnego dostawcę stanu i automatycznie generuje ustawienia liczby replik w celu osiągnięcia jednego z tych trzech ustawień trwałości. Atrybut StatePersistence nie jest dziedziczony przez klasę pochodną. Każdy typ aktora musi podać poziom StatePersistence.

Stan utrwalonego

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

To ustawienie używa dostawcy stanu, który przechowuje dane na dysku i automatycznie ustawia liczbę replik usługi na 3.

Stan nietrwały

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

To ustawienie używa dostawcy stanu tylko w pamięci i ustawia liczbę replik na 3.

Brak utrwalonego stanu

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

To ustawienie używa dostawcy stanu tylko w pamięci i ustawia liczbę replik na 1.

Ustawienia domyślne i wygenerowane

Gdy używasz atrybutu StatePersistence , dostawca stanu jest automatycznie wybierany w czasie wykonywania po uruchomieniu usługi aktora. Jednak liczba replik jest ustawiana w czasie kompilacji przez narzędzia kompilacji aktora programu Visual Studio. Narzędzia kompilacji automatycznie generują usługę domyślną dla usługi aktora w ApplicationManifest.xml. Parametry są tworzone dla minimalnego rozmiaru zestawu replik i docelowego rozmiaru zestawu replik.

Te parametry można zmienić ręcznie. Jednak za każdym razem, gdy StatePersistence atrybut jest zmieniany, parametry są ustawione na domyślne wartości rozmiaru zestawu repliki dla wybranego StatePersistence atrybutu, przesłaniając wszystkie poprzednie wartości. Innymi słowy, wartości ustawione w ServiceManifest.xml są zastępowane tylko w czasie kompilacji podczas zmiany wartości atrybutu StatePersistence .

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

Menedżer stanu

Każde wystąpienie aktora ma własnego menedżera stanu: strukturę danych przypominającą słownik, która niezawodnie przechowuje pary klucz/wartość. Menedżer stanu jest otoką dostawcy stanu. Można go użyć do przechowywania danych niezależnie od tego, które ustawienie trwałości jest używane. Nie zapewnia żadnych gwarancji, że uruchomiona usługa aktora może zostać zmieniona z nietrwałego (tylko w pamięci) ustawienia stanu na utrwalone ustawienie stanu przez uaktualnienie stopniowe przy jednoczesnym zachowaniu danych. Można jednak zmienić liczbę replik dla uruchomionej usługi.

Klucze menedżera stanu muszą być ciągami. Wartości są ogólne i mogą być dowolnym typem, w tym typami niestandardowymi. Wartości przechowywane w menedżerze stanu muszą być możliwe do serializacji kontraktu danych, ponieważ mogą być przesyłane przez sieć do innych węzłów podczas replikacji i mogą być zapisywane na dysku, w zależności od ustawienia trwałości stanu aktora.

Menedżer stanu uwidacznia typowe metody słownika do zarządzania stanem, podobnie jak te znalezione w reliable dictionary.

Przykłady zarządzania stanem aktora, odczyt dostępu, zapisywania i usuwania stanu elementów Reliable Actors.

Najlepsze rozwiązania

Poniżej przedstawiono kilka sugerowanych rozwiązań i wskazówek dotyczących rozwiązywania problemów dotyczących zarządzania stanem aktora.

Umożliw, aby aktor był tak szczegółowy, jak to możliwe

Ma to kluczowe znaczenie dla wydajności i użycia zasobów aplikacji. Za każdym razem, gdy istnieje jakakolwiek aktualizacja/zapis do "nazwanego stanu" aktora, cała wartość odpowiadająca temu "nazwany stan" jest serializowana i wysyłana przez sieć do replik pomocniczych. Serwery pomocnicze zapisują go na dysku lokalnym i odpowiadają z powrotem do repliki podstawowej. Gdy podstawowy odbiera potwierdzenia z kworum replik pomocniczych, zapisuje stan na dysku lokalnym. Załóżmy na przykład, że wartość jest klasą zawierającą 20 elementów członkowskich i rozmiarem 1 MB. Nawet jeśli zmodyfikowano tylko jeden z elementów członkowskich klasy o rozmiarze 1 KB, w końcu płacisz koszt serializacji i zapisu sieciowego i dysku dla pełnego 1 MB. Podobnie, jeśli wartość jest kolekcją (taką jak lista, tablica lub słownik), płacisz koszt całej kolekcji, nawet jeśli zmodyfikujesz jeden z jego elementów członkowskich. Interfejs StateManager klasy aktora jest jak słownik. Zawsze należy modelować strukturę danych reprezentującą stan aktora na podstawie tego słownika.

Poprawne zarządzanie cyklem życia aktora

Należy mieć jasne zasady dotyczące zarządzania rozmiarem stanu w każdej partycji usługi aktora. Usługa aktora powinna mieć stałą liczbę aktorów i jak najwięcej ich używać. Jeśli stale tworzysz nowych aktorów, musisz je usunąć po zakończeniu pracy. Struktura aktora przechowuje pewne metadane dotyczące każdego aktora, który istnieje. Usunięcie całego stanu aktora nie powoduje usunięcia metadanych dotyczących tego aktora. Aby usunąć wszystkie informacje o nim przechowywane w systemie, należy usunąć aktora (zobacz usuwanie aktorów i ich stanu). W ramach dodatkowego sprawdzenia należy wykonać zapytanie dotyczące usługi aktora (zobacz wyliczanie aktorów) raz na chwilę, aby upewnić się, że liczba aktorów mieści się w oczekiwanym zakresie.

Jeśli kiedykolwiek zobaczysz, że rozmiar pliku bazy danych usługi aktora przekracza oczekiwany rozmiar, upewnij się, że przestrzegasz powyższych wytycznych. Jeśli przestrzegasz tych wytycznych i nadal występują problemy z rozmiarem plików bazy danych, otwórz bilet pomocy technicznej z zespołem produktu, aby uzyskać pomoc.

Następne kroki

Stan przechowywany w elementach Reliable Actors musi zostać zserializowany przed zapisaną na dysku i zreplikowany w celu zapewnienia wysokiej dostępności. Dowiedz się więcej o serializacji typu aktora.

Następnie dowiedz się więcej o diagnostyce aktora i monitorowaniu wydajności.