Gestion des enregistrements en double

Il y a deux raisons principales pour lesquelles les enregistrements peuvent être distribués plusieurs fois à votre Amazon Kinesis Data Streams : nouvelles tentatives de l'application producteur et nouvelles tentatives de l'application consommateur. Votre application doit anticiper et gérer adéquatement le traitement des enregistrements plusieurs fois.

Nouvelles tentatives de l'application producteur

Prenez l'exemple d'une application producteur qui connaît un délai d'attente lié au réseau après avoir effectué un appel vers PutRecord, mais avant de recevoir un accusé de réception de Amazon Kinesis Data Streams. L'application producteur ne peut pas être sûre que l'enregistrement a été distribué à Kinesis Data Streams. En supposant que chaque enregistrement est important pour l'application, l'application producteur aura été écrite de façon à renouveler l'appel avec les mêmes données. Si les deux appels vers PutRecord sur ces mêmes données ont été validés avec succès pour Kinesis Data Streams, il y aura deux enregistrements Kinesis Data Streams. Même si les deux enregistrements comportent des données identiques, ils ont aussi des numéros de séquence uniques. Les applications qui ont besoin de garanties strictes doivent intégrer une clé primaire dans l'enregistrement pour supprimer les doubles ultérieurement lors du traitement. Notez que le nombre de doubles dû aux tentatives de l'application producteur est généralement faible par rapport au nombre de doubles dû aux tentatives de l'application consommateur.

Note

Si vous utilisez le SDK AWS PutRecord, la configuration par défaut tente jusqu'à trois fois un appel PutRecord qui n'a pas abouti.

Tentatives de l'application consommateur

Les tentatives de l'application consommateur (l'application qui traite les données) ont lieu lorsque les processeurs d'enregistrements redémarrent. Les processeurs d'enregistrements d'une même partition redémarrent dans les cas suivants :

1. Une application de travail s'arrête de manière inattendue

2. Des instances de travail sont ajoutées ou supprimées

3. Des partitions sont fusionnées ou fractionnées

4. L'application est déployée

Dans tous ces cas, le mappage partitions à application de travail à processeur d'enregistrements est continuellement mis à jour pour équilibrer la charge du traitement. Les processeurs de partition qui ont été migrés vers d'autres instances recommencent à traiter les enregistrements depuis le dernier point de contrôle. Il en résulte un traitement double des enregistrements, comme l'illustre l'exemple ci-dessous. Pour plus d'informations sur l'équilibrage de charge, consultez Repartitionnement, mise à l'échelle et traitement parallèle.

Exemple : Tentatives de l'application consommateur générant des enregistrements redistribués

Dans cet exemple, vous avez une application qui lit continuellement les enregistrements à partir d'un flux, regroupe les enregistrements dans un fichier local et charge ce fichier dans Amazon S3. Pour simplifier, supposons qu'il y a une seule partition et une application de travail qui traite la partition. Prenons l'exemple de la séquence d'événements suivante, en supposant que le dernier point de contrôle était au numéro d'enregistrement 10 000 :

1. Une application de travail lit le prochain lot d'enregistrements à partir de la partition, soit les enregistrements 10 001 à 20 000.

2. L'application de travail passe le lot d'enregistrements au processeur d' enregistrements associé.

3. Le processeur d'enregistrements regroupe les données, crée un fichier Amazon S3 et charge ce fichier dans Amazon S3 avec succès.

4. L'application de travail s'arrête de façon inattendue avant l'arrivée d'un nouveau point de contrôle.

5. L'application, l'application de travail et le processeur d'enregistrements redémarrent.

6. L'application de travail commence maintenant à lire depuis le dernier point de contrôle, ici 10 001.

Donc les enregistrements 10 001 à 20 000 sont utilisés plusieurs fois.

Résistance aux tentatives de l'application consommateur

Même si les enregistrements peuvent être traités plusieurs fois, votre application peut vouloir présenter les effets secondaires en indiquant que les enregistrements ont été traités une seule fois (traitement idempotent). Les solutions à ce problème varient en complexité et précision. Si la destination des données finales peut gérer les doubles correctement, nous vous recommandons de vous appuyer sur la destination finale pour effectuer un traitement idempotent. Par exemple, avec Opensearch vous pouvez utiliser une combinaison de gestion des versions et d'ID uniques pour empêcher le traitement en double.

Dans l'exemple de la section précédente, l'application lit en permanence les enregistrements à partir d'un flux, regroupe les enregistrements dans un fichier local et charge ce fichier dans Amazon S3. Comme illustré, les enregistrements 10 001 à 20 000 sont utilisés plusieurs fois, ce qui donne plusieurs fichiers Amazon S3 contenant les mêmes données. Une façon d'atténuer les doubles constatés dans cet exemple est de faire en sorte que l'étape 3 utilise le schéma suivant :

1. Le processeur d'enregistrements utilise un nombre fixe d'enregistrements par fichier Amazon S3, par exemple 5 000.

2. Le nom de fichier utilise le schéma suivant : préfixe Amazon S3, id de partition et First-Sequence-Num. Dans ce cas, ce peut être quelque chose comme sample-shard000001-10001.

3. Une fois que vous avez chargé le fichier Amazon S3, effectuez un point de contrôle en spécifiant Last-Sequence-Num. Dans ce cas, vous effectuez le point de contrôle au numéro d'enregistrement 15 000.

Avec ce schéma, même si les enregistrements sont traités plusieurs fois, le fichier Amazon S3 résultant a le même nom et contient les mêmes données. Les tentatives se traduisent uniquement par l'écriture des mêmes données dans le même fichier plusieurs fois.

Dans le cas d'une opération de repartitionnement, le nombre d'enregistrements laissés dans la partition peut être inférieur au nombre fixe voulu. Dans ce cas, votre méthode shutdown() doit vider le fichier dans Amazon S3 et effectuer un point de contrôle sur le dernier numéro de séquence. Le schéma ci-dessus est aussi compatible avec les opérations de repartitionnement.