No Apache Flink, um watermark sinaliza o avanço do tempo dos eventos; o buffer descrito pela Cisco faz outra coisa: guarda eventos de cada sessão e os ordena pelo horário em que ocorreram. A diferença é entre indicar até onde o processamento pode avançar e reorganizar explicitamente os registros de uma sequência.

Por que a ordem dos eventos importa

O pipeline da Cisco recebe eventos de conexão pelo Apache Kafka e analisa etapas como auth, assoc, dhcp e dns. Como os registros podem chegar fora da ordem em que os eventos aconteceram, a sequência de chegada nem sempre representa a sequência real da conexão. A Cisco relata que esse cenário podia levar a aplicação original a indicar falsamente que uma conexão havia sido concluída com sucesso. A descrição técnica da Cisco relaciona o caminho original de processamento ao acesso ao estado no RocksDB e ao registro de timers a cada evento.

Tempo do evento e watermarks no Flink

Tempo do evento é o momento em que algo ocorreu; tempo de processamento é o horário do sistema da máquina que processa o registro. Um watermark é um sinal de progresso no tempo do evento: indica que o processamento pode avançar até determinado ponto nessa linha do tempo. A documentação do Apache Flink sobre tempo e watermarks explica que lidar com eventos fora de ordem em tempo de evento envolve uma espera finita.

O watermark, portanto, orienta o avanço de operações que dependem do tempo. A solução descrita pela Cisco ordena registros armazenados por sessão. Os conceitos se relacionam, mas um não é apenas outro nome para o outro.

Como funciona o buffer por sessão da Cisco

Na implementação descrita pela Cisco, uma KeyedProcessFunction mantém os eventos de cada sessão em um HashMap. Antes de analisar a sequência, a aplicação os ordena por tempo do evento, em vez de confiar na ordem de chegada ou no tempo de processamento.

O buffer fica na memória heap da JVM, fora do estado gerenciado pelo Flink. Para limitar seu crescimento, a Cisco relata um timeout de inatividade de três minutos, redução de registros redundantes de timers, objetos POJO compactos e análise dos campos na entrada. Esses controles acompanham a ordenação: os eventos precisam permanecer disponíveis enquanto a aplicação monta a sequência da sessão.

O que os checkpoints recuperam

A Cisco diz que copia o conteúdo do buffer para ListState nos checkpoints e restaura esses dados após uma reinicialização. Assim, o buffer mantido em memória participa da recuperação do estado da aplicação.

Isso, por si só, não garante processamento exactly-once de ponta a ponta. Se a recuperação fizer a aplicação repetir saídas, o destino, ou sink, também precisa tratar essa repetição corretamente. A Cisco destaca essa condição para o resultado completo.

O alcance dos resultados relatados

A Cisco relata que manteve a nova implementação em paralelo com a original, usando dados de produção, durante cinco meses antes de mudar o padrão. Também atribui ao pipeline de conexões uma taxa de 200 mil mensagens por segundo. Esse número se refere ao caso de uso da própria Cisco.

A experiência descrita combina ordenação por sessão, recuperação por checkpoints e controles para limitar o buffer. Watermarks, por sua vez, comunicam avanço no tempo do evento; não descrevem, por si só, a ordenação explícita dos registros que a Cisco relata fazer dentro de cada sessão.