Tratar registros duplicados

Há dois principais motivos pelos quais os registros podem ser entregues mais de uma vez à aplicação do Amazon Kinesis Data Streams: novas tentativas de produtor e novas tentativas de consumidor. Seu aplicativo precisa prever e tratar devidamente o processamento de registros individuais várias vezes.

Retentativas de produtor

Considere um produtor que tem um tempo limite esgotado de rede depois de fazer uma chamada a PutRecord, mas antes de poder receber uma confirmação do Amazon Kinesis Data Streams. O produtor não tem certeza de que o registro foi entregue ao Kinesis Data Streams. Supondo que cada registro é importante para o aplicativo, o produtor teria sido concebido de modo a tentar novamente a chamada com os mesmos dados. Se as duas chamadas a PutRecord para os mesmos dados foram confirmadas com sucesso no Kinesis Data Streams, haverá dois registros do Kinesis Data Streams. Embora os dois registros tenham dados idênticos, eles também têm números sequenciais exclusivos. Os aplicativos que precisam de rigorosas garantias devem incorporar uma chave primária ao registro para remover duplicatas mais tarde ao processar. Observe que o número de duplicatas resultante das retentativas de produtor costuma ser baixo em comparação com o número de duplicatas resultante das retentativas de consumidor.

nota

Se você usar a PutRecord do AWS SDK, a configuração padrão fará até três novas tentativas de chamar a PutRecord em caso de falha.

Retentativas de consumidor

As retentativas de consumidor (aplicativo de processamento de dados) acontecem quando os processadores de registros são reiniciados. Os processadores de registros do mesmo estilhaço reiniciam nos seguintes casos:

1. Um operador é encerrado inesperadamente

2. Instâncias de operador são adicionadas ou removidas

3. Os estilhaços são mesclados ou divididos

4. O aplicativo é implantado

Em todos esses casos, o mapeamento de estilhaços para operador para processador de registros é atualizado continuamente para balancear a carga do processamento. Processadores de estilhaços que foram migrados para outras instâncias reiniciam o processamento de registros a partir do último ponto de verificação. Isso acarreta processamento de registros duplicado, conforme mostrado no exemplo abaixo. Para obter mais informações sobre balanceamento de carga, consulte Reestilhaçamento, escalabilidade e processamento paralelo.

Exemplo: Retentativas de consumidor gerando reentrega de registros

Neste exemplo, você tem uma aplicação que lê continuamente registros de um fluxo, agrega registros em um arquivo local e faz upload do arquivo para o Amazon S3. Para simplificar, suponha que haja apenas 1 estilhaço e 1 operador processando o estilhaço. Considere a sequência de eventos de exemplo a seguir, supondo que o último ponto de verificação ocorreu no registro de número 10.000:

1. Um operador lê o próximo lote de registros a partir do estilhaço, registros de 10.001 a 20.000.

2. O operador passa o lote de registros para o processador de registros associado.

3. O processador de registros agrega os dados, cria um arquivo do Amazon S3 e faz upload do arquivo para o Amazon S3 com êxito.

4. O operador é encerrado inesperadamente antes que ocorra um novo ponto de verificação.

5. O aplicativo, o operador e o processador de registros são reiniciados.

6. O operador agora começa a ler a partir do último ponto de verificação bem-sucedido, que neste caso é 10.001.

Desse modo, os registros de 10.001 a 20.000 são consumidos mais de uma vez.

Ser resiliente a retentativas de consumidor

Mesmo que os registros possam ser processados mais de uma vez, seu aplicativo pode apresentar efeitos colaterais como se os registros tivessem sido processados apenas uma vez (processamento idempotente). As soluções para esse problema variam em termos de complexidade e precisão. Se o destino dos dados finais puder tratar bem das duplicatas, recomendamos confiar no destino final para obter o processamento idempotente. Por exemplo, com o Opensearch, você pode usar uma combinação de versionamento e IDs exclusivos para evitar o processamento duplicado.

A aplicação de exemplo da seção anterior lê continuamente os registros de um fluxo, agrega os registros em um arquivo local e faz upload do arquivo para o Amazon S3. Conforme ilustrado, os registros de 10.001 a 20.000 são consumidos mais de uma vez, resultando em vários arquivos do Amazon S3 com os mesmos dados. Uma forma de reduzir as duplicatas desse exemplo é garantir que a etapa 3 use o seguinte esquema:

1. O processador de registros usa um número fixo de registros por arquivo do Amazon S3, como 5.000.

2. O nome do arquivo usa este esquema: prefixo do Amazon S3, shard-id e First-Sequence-Num. Neste caso, pode ser algo como sample-shard000001-10001.

3. Depois de fazer upload do arquivo do Amazon S3, defina o ponto de verificação especificando Last-Sequence-Num. Neste caso, o ponto de verificação seria definido no registro de número 15.000.

Com esse esquema, mesmo que os registros sejam processados mais de uma vez, o arquivo do Amazon S3 resultante terá o mesmo nome e os mesmos dados. As retentativas geram apenas a gravação dos mesmos dados no mesmo arquivo mais de uma vez.

No caso de uma operação de reestilhaçamento, o número de registros deixados no estilhaço pode ser menor que o número fixo necessário. Nesse caso, o método shutdown() precisa descarregar o arquivo no Amazon S3 e definir o ponto de verificação no último número de sequência. O esquema acima também é compatível com as operações de reestilhaçamento.