Comprensión Passivation, Recordando Entidades y Programadores

Cuando IPF flows están en progreso (es decir, aún no en un estado terminal), el comportamiento predeterminado del IPF es retenerlos en memoria hasta que sean terminados. Los flujos se distribuyen más o menos de manera uniforme a través del clúster con Akka ClusterSharding.

Este artículo explica los conceptos de pasivación, entidades de recuerdo y cómo reiniciar flujos fallidos.

Recordando Entidades

Si un nodo falla o se detiene de manera controlada (o si todos los nodos se detienen y la aplicación se inicia en frío), entonces todos los flujos en vuelo (shards) se cargan de nuevo en la memoria en la próxima puesta en marcha. Esto se llama recordando entidades.

La manera Akka determina si un flujo está o no completado al almacenar también este estado en un almacén de algún descripción. Las opciones para esto son eventsourced(el predeterminado de IPF) o ddata. El eventsourced la opción es el IPF predeterminado porque es más eficiente y es resistente a reinicios totales del clúster sin necesidad de adicionales configuración.

Cualquier dato almacenado en ddata se guarda en el disco por defecto, por lo que no puede sobrevivir a un reinicio total del clúster en un entorno contenedorizado. entorno como Kubernetes. En tales entornos, usted deberá configurar un Volumen Persistente para almacenar este estado y cambiar la configuración de IPF para apuntar la aplicación al volumen persistente.

Más información sobre las diferentes entidades de almacenamiento de recuerdos (y cómo configurarlas)aquí.

Passivation y Automatic Passivation

Por defecto, un flujo se considera "detenido" cuando el flujo determina que ha alcanzado un estado terminal y se detiene. en sí mismo. Esto se llama pasivación.

Otras formas de detener un flujo-incluso si no está terminado-are:

Si se habilita el recuerdo de entidades, la desactivación automática no puede ser habilitada.

Revitalización de la Acción

Cuando un flujo se carga de nuevo en memoria con entidades recordadas después de que otro nodo abandona (o falla), el IPF flow se le notifica de esto y reacciona enviándose a sí mismo un ActionRecoveryCommand. Este comando especial intenta "pinchar" el flujo para realizar la siguiente acción que necesita llevar a cabo en función del último estado conocido. Más información sobre el tema es disponible aquí.

Comportamiento predeterminado de IPF

El comportamiento predeterminado de IPF es:

  • Recuerde entidades con eventsourced como la tienda

  • Automatic Passivation desactivado (debe estar desactivado si recordar entidades está activado)

  • Akka Scheduler

Este comportamiento predeterminado es adecuado para flujos que coinciden con el siguiente perfil:

  • De corta duración

  • Cualquier tipo de volumen (alto o bajo)

Sin embargo, este enfoque puede volverse problemático cuando hay muchos flujos de larga duración: si hay un paso que espera por horas o días, entonces podría haber un gran número de flujos que están aparcados y consumiendo memoria cuando no lo estarán necesario durante mucho tiempo.

Si este es el caso, entonces podría valer la pena cambiar cómo se comporta el clúster mediante:

  • Desactivar el recuerdo de entidades

  • Habilitando la pasivación automática

  • Utilizando el IPF persistente Quartz Programador para programar reintentos

Si se presentaran en una tabla, las opciones serían:

ID Recuerde entidades Auto-pasivación Implementación del programador Bueno para ¿Cómo se manejan las fallas de nodo?

1

Habilitado

Deshabilitado

Akka (no persistente)

Flujos de alto o bajo volumen que se completan rápidamente (por ejemplo, en un minuto)

Los flujos siempre se mantienen en memoria y ActionRevival proceso (ver arriba) es triggered cuando las entidades se reinician en otro nodo después de una falla o apagado

2

Deshabilitado

Habilitado

Cuarzo (persistente)

Flujos de larga duración

La reintentos de tareas se gestionan por separado del flujo mismo y también son resistentes a fallos.

Activación para eventos perdidos en el pasado

Si utiliza la combinación 2 (recuerde que las entidades están deshabilitadas/la auto-pasivación está habilitada/Quartz) luego el Quartz Programador la implementación gestionará los reintentos para cualquier tarea relacionada con los flujos. Esto es resiliente porque también utiliza un Cluster Singletonpara gestionar este trabajo y en caso de la falla del nodo que está sosteniendo el Cluster Singleton, el singleton se migra al siguiente nodo más antiguo y los trabajos se vuelven a encolar para reintentar.

Este proceso debería tardar solo unos pocos segundos y, por lo tanto, para procesos de larga duración, esto generalmente no es un gran problema. En el improbable caso de que un trabajo sea triggered mientras el Cluster Singleton se está migrando, actualmente se omite y se registra una advertencia para alertar al usuario que se perdió un disparador durante la migración. Esta funcionalidad puede ser activada o desactivada en el futuro si así se desea. deseado.

Preocupaciones sobre el uso de la base de datos

Al iniciar y con la opción de recordar entidades habilitada, IPF leerá todas las entidades en vuelo al leer todos sus eventos. para construir el estado actual de ese flujo particular. Esta es una operación que requiere mucha lectura, y para entornos donde la base de datos el uso se mide de tal manera (por ejemplo, Azure Cosmos DB) que podría ser una mejor idea utilizar la Combinación 2 para evitar esto alto costo inicial.

Configuración

Para configurar la Combinación 2 no predeterminada, establezca las siguientes claves de configuración en ipf-impl.conf or application.conf:

# Disable remembering entities
akka.cluster.sharding.remember-entities = off
# Set the passivation strategy to be the default i.e. a maximum of active entities at any one time
akka.cluster.sharding.passivation.strategy = default-strategy

# Change the below if you want to use a separate MongoDB instance for persisting scheduled tasks
ipf-scheduler {
  mongodb = {
    uri = ${ipf.mongodb.uri}
    database-name = "scheduled"
  }
}

Passivation Cuando esté en la terminal State Retraso

Cuando los ESB alcanzan un estado terminal, se desactivan (se descargan de la memoria). Sin embargo, en algunas circunstancias (como un comando retrasado o una consulta utilizando el getAggregate en el REST El controlador) un ESB será rehidratado. En estos casos, debemos asegurarnos de que el ESB esté pasivado para que no resida en la memoria. innecesariamente. Esto se hace por scheduling una solicitud para desactivar el ESB, queremos retrasar la desactivación para que si se reciben algunos comandos en un corto período de tiempo, cada uno no requiera desactivación y posterior rehidratación. Este retraso es configurable a través de:

application.conf

ipf.behaviour.config.final-state-passivate-delay=10s