Cisco describe un búfer que ordena por tiempo de evento los registros de cada sesión antes de procesarlos. Los watermarks de Apache Flink hacen otra cosa: señalan cuánto ha avanzado el tiempo de evento. Ambos conceptos ayudan a procesar eventos que llegan desordenados, pero un watermark no equivale a la ordenación explícita que Cisco relata.

La hora del evento no es la hora de llegada

En una cadena de conexión, eventos como auth, assoc, dhcp y dns pueden llegar en un orden distinto de aquel en que ocurrieron. Cisco cuenta que ese desorden podía llevar a su aplicación original a informar falsamente de una conexión correcta. En esa versión, cada evento entrante también implicaba acceder al estado de RocksDB y registrar un temporizador.

Flink distingue entre tiempo de evento, cuando sucede el hecho, y tiempo de procesamiento, el reloj del equipo que lo procesa. Un watermark indica que el tiempo de evento ha avanzado hasta cierto punto y que se espera que ya no lleguen eventos con marcas de tiempo iguales o anteriores. Flink también señala que procesar eventos desordenados según su tiempo de evento requiere esperar durante un periodo finito. La documentación oficial de Apache Flink sobre el procesamiento temporal explica estos conceptos.

Qué hace el búfer por sesión de Cisco

Cisco describe una KeyedProcessFunction que mantiene los eventos de cada sesión en una HashMap y los ordena con un comparador basado en el tiempo de evento antes de analizar la secuencia. Así, el orden de llegada no determina directamente el orden en que se interpreta cada cadena de conexión.

Ese mecanismo ordena los registros almacenados para cada sesión. Un watermark, en cambio, comunica el avance del tiempo de evento a los operadores. La diferencia práctica es que indicar hasta dónde ha avanzado el tiempo no es lo mismo que ordenar explícitamente los eventos de una sesión.

Cómo recupera el búfer tras un reinicio

Cisco dice que copia el contenido del búfer a ListState en cada checkpoint y lo restaura después de un reinicio. Los checkpoints guardan el estado de la aplicación para recuperarlo; por sí solos no garantizan que las salidas se procesen exactamente una vez de extremo a extremo. Según Cisco, el sink, el componente que recibe los resultados, también debe gestionar correctamente las salidas que se repitan durante la recuperación.

El coste de mantener eventos en memoria

El búfer de Cisco está en la memoria del heap de la JVM, fuera del estado gestionado por Flink. La empresa describe varias medidas para limitar su uso: eliminar sesiones inactivas tras tres minutos, reducir registros redundantes de temporizadores mediante debouncing, emplear objetos Java compactos (POJO) y analizar los campos al ingresar los datos.

Cisco afirma que mantuvo la nueva variante en paralelo con la original sobre datos de producción durante cinco meses antes de cambiar la configuración predeterminada. También comunicó una tasa de 200.000 mensajes por segundo para ese pipeline de conexiones de red.