Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Options de durabilité
ElastiCache for Valkey propose deux options de durabilité : les écritures synchrones et asynchrones.
Avec les écritures synchrones, les opérations d'écriture réussies sont stockées de manière durable dans le journal des Multi-AZ transactions avant d'être renvoyées aux clients. Cela entraîne une latence d'écriture d'un chiffre en millisecondes et garantit qu'aucune opération d'écriture reconnue ne sera perdue en cas d'échec.
Avec les écritures asynchrones, les opérations d'écriture réussies sont renvoyées aux clients avant d'être stockées de manière durable dans le Multi-AZ journal des transactions. Comme les opérations d'écriture n'attendent pas d'être stockées de manière durable dans le journal des Multi-AZ transactions, la latence des opérations d'écriture est équivalente à une ElastiCache absence de durabilité. Cependant, les 10 dernières secondes des opérations d'écriture réussies peuvent être perdues en cas d'échec.
Pour comprendre les pertes de données potentielles liées aux écritures asynchrones, considérez le concept de mémoire tampon de durabilité. La mémoire tampon de durabilité représente l'âge maximal de toute écriture acceptée par le nœud principal mais qui n'a pas encore été conservée dans le journal des Multi-AZ transactions. Le nœud principal indique l'âge de la plus ancienne écriture non reconnue. Tant que cet âge reste inférieur à 10 secondes, le nœud continue d'accepter les nouvelles écritures normalement. Si l'âge de la plus ancienne écriture non reconnue dépasse 10 secondes, le nœud principal rejettera toutes les commandes d'écriture entrantes jusqu'à ce qu'il rattrape son retard. Les opérations de lecture continuent d'être effectuées avec une latence de l'ordre de la microseconde pendant cette période. Une fois que les écritures en attente sont persistantes, le nœud recommence à accepter les écritures automatiquement. Cela garantit que la perte de données potentielle est limitée à 10 secondes d'écriture en cas de panne.
Lorsque vous configurez votre client pour envoyer du trafic vers un cluster durable asynchrone, assurez-vous que le client réessaie automatiquement avec un retard exponentiel toutes les commandes d'écriture rejetées avec le message d'erreur d'arrêt du cluster. Pour obtenir des conseils sur la configuration de vos clients afin de gérer cette erreur et d'autres erreurs transitoires, consultez [Best practices : Valkey/Redis OSS clients and Amazon ElastiCache](https://aws.amazon.com/blogs/database/best-practices-valkey-redis-oss-clients-and-amazon-elasticache/).
## Choisir une option de durabilité
Utilisez les écritures synchrones lorsque votre application ne peut tolérer aucune perte de données en cas de panne. Les écritures synchrones peuvent être utilisées ElastiCache pour un ensemble plus large de cas d'utilisation autres que la mise en cache lorsque la perte de données n'est pas acceptable, tels que les bases de connaissances pour les applications RAG, la mémoire des agents AI, l'état du flux de travail des agents AI, la tokenisation des paiements, les métadonnées de streaming, l'état des joueurs et la gestion des stocks en temps réel.
Utilisez les écritures asynchrones lorsque votre application donne la priorité aux performances d'écriture et peut tolérer la perte potentielle de 10 secondes de données non validées en cas de panne. Cette option est idéale pour les charges de travail telles que la mise en cache des données d'applications, les magasins de sessions, les classements de jeu et les analyses en temps réel.