Comprensión Passivation, Recordando Entidades y Programadores

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

Este artículo explica los conceptos de passivation, recordando entidades, y cómo restart failed flujos.

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 esto state en una tienda de algunos 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 total restarts del clúster sin adicional configuración.

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

Más información sobre los diferentes remember entities almacenes (y cómo configurarlos)aquí.

Passivation y Automatic Passivation

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

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

Si la memoria de entidades está habilitada,automatic passivation no se puede habilitar tampoco

Revitalización de la Acción

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

Comportamiento predeterminado de IPF

El comportamiento predeterminado de IPF es:

  • Remember entities con eventsourced como la tienda

  • Automatic Passivation apagado (debe estar apagado si remember entities is on)

  • 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 automatic passivation

  • Utilizando el IPF persistente Quartz Scheduler para programar reintentos

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

ID Remember entities Auto-passivation 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 están restarted on 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 por falta events en el pasado

Si utiliza la combinación 2 (remember entities deshabilitado/automático passivation habilitado/Quartz) entonces el Quartz Scheduler La implementación gestionará los reintentos para cualquier tarea relacionada con los flujos. Esto es resistente porque también utiliza un Cluster Singleton para gestionar este trabajo y en el event del fallo 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 event que un trabajo es 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 remember entities habilitado, IPF leerá todas las entidades en vuelo al leer todas sus events para construir el actual state 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 de inicio.

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 terminal state se encuentran pasivados (descargados 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 el passivation para que si se reciben algunos comandos en un corto período de tiempo, cada uno no requiera passivation y la posterior rehidratación, este retraso es configurable a través de:

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