Transición entre el servicio con estado y la persistencia externa en Azure Service Fabric
orleans azure-service-fabric (2)
El KvsActorStateProvider de hecho almacena el estado del actor en un KeyValueStore que es una estructura similar al ReliableDictionary.
La primera pregunta que me haría es si necesita relegar a los viejos actores a la cámara frigorífica. La limitación de mantener todo en la memoria no lo limita a un número total de actores, sino a un número total por réplica. Por lo tanto, primero debe considerar la estrategia de partición para que sus actores se distribuyan en varias réplicas diferentes. A medida que sus demandas crezcan, puede agregar más máquinas al clúster y ServiceFabric orquestará los movimientos de las réplicas a las nuevas máquinas. Para obtener más información sobre la partición del servicio Actor, visite http://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-actors-platform/
Si desea utilizar el almacenamiento en frío después de algún tiempo, entonces tiene un par de opciones. En primer lugar, podría decorar a sus actores con un ActorStateProviderAttribute personalizado que devuelva su propia implementación de un IActorStateProvider que pueda manejar la persistencia como usted decida.
Alternativamente, podrías manejarlo completamente dentro de tu implementación de Actor. Enganche en el Ciclo de vida del actor y en OnDeactivateAsync, de manera que cuando la instancia se recolecte como basura, o use un recordatorio del actor por un tiempo específico en el futuro, para serializar el estado y almacenar en almacenamiento en frío, como almacenamiento de tablas o blobs, y anular el estado propiedad. La anulación ActivateAsync se puede usar para recuperar este estado del almacenamiento sin conexión y deserializar.
El Azure Service Fabric parece estar centrado en escenarios en los que todos los datos pueden caber dentro de la RAM y la persistencia se utiliza como un almacén de respaldo. Los servicios confiables están diseñados para almacenar información en colecciones confiables, que utilizan un sistema de punto de control de registro donde la información registrada se escribe en la RAM. Mientras tanto, para los actores confiables, el proveedor de estado de actor predeterminado es "el almacén Key-Value distribuido proporcionado por la plataforma Service Fabric". Esto parece indicar que se aplicarían las mismas limitaciones.
Sin embargo, puede haber situaciones en las que a uno le gustaría usar Service Fabric para "datos importantes" pero escribir "datos fríos" en alguna forma de almacenamiento permanente. ¿Cuáles son las mejores prácticas para manejar esta transición?
En Orleans, esto parece manejarse automáticamente, utilizando un almacén de persistencia como las tablas de Azure. Pero parece que un objetivo principal de diseño del Service Fabric y las Colecciones confiables es evitar la necesidad de servicios externos, mejorando así la ubicación de los datos. La documentación actual anticipa la posibilidad de que uno quiera mover datos a algún almacén permanente para recuperación y análisis de desastres , pero no discute la posibilidad de mover datos entre actores de memoria en memoria respaldados por persistencia y formas de almacenamiento más permanentes. .
Una posible respuesta es que Service Fabric ya hace esto. Tal vez un diccionario confiable tenga algún mecanismo incorporado para cambiar entre el almacenamiento en memoria respaldado por persistencia y el almacenamiento permanente.
O, tal vez la respuesta es que uno debe manejarse uno mismo. Un enfoque podría ser que un Actor realice un seguimiento de cuán "caliente" es y cambie su almacenamiento de persistencia según sea necesario. Pero esto sacrifica uno de los beneficios del modelo Actor, la asignación automática y la desasignación de actores. De manera similar, podríamos eliminar periódicamente los elementos del Diccionario confiable y agregarlos a algún otro almacén de persistencia, y luego agregarlos nuevamente. Una vez más, sin embargo, esto requiere saber cuándo tiene sentido hacer la transición.
Un par de ejemplos pueden ayudar a cristalizar esto:
(1) Supongamos que estamos implementando un juego multijugador con muchas "salas" diferentes. No necesitamos todas las habitaciones en la memoria a la vez, pero necesitamos moverlas a la memoria y usar la persistencia local como respaldo una vez que los jugadores se unan a ellas.
(2) Supongamos que estamos implementando un árbol B de solo apéndice como parte de una base de datos. La tentación sería que cada nodo B-Tree sea un actor con estado. Nos gustaría que los b-trees calientes permanezcan en la memoria pero, por supuesto, el índice completo no puede estar en la memoria. Parece que este es un escenario central que ya está implementado para cosas como DocumentDB, pero no me queda claro en la documentación cómo se haría esto.
Una pregunta relacionada que encontré está here . Pero esa pregunta se centra en cuándo usar Azure Service Fabric en lugar de servicios externos. Mi pregunta es si es necesario hacer una transición entre ellos o si Azure Service Fabric ya tiene todas las capacidades necesarias aquí.
El proveedor del estado del almacén de Key-Value no requiere que todo se guarde en la memoria. Este proveedor realmente almacena el estado de todos los actores en el disco local y el estado también se replica en el disco local en otros nodos. Por lo tanto, la tienda KVS se considera una tienda persistente y confiable.
Además de eso, el estado de los actores activos también se almacena en la memoria. Cuando un actor no ha sido usado por un tiempo, se desactiva y se recolecta la basura. Cuando esto sucede, la copia en memoria se libera y solo queda la copia en el disco. Cuando el actor se activa de nuevo, el estado se recupera del disco y permanece en la memoria mientras el actor esté activo.
Además, KVS no es el único proveedor estatal incorporado. También tenemos el VolatileActorStateProvider ( http://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-actors-platform/#actor-state-provider-choices ). Este es el proveedor estatal que guarda todo en la memoria.