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 Multi-AZ transactionnel avant d'être renvoyées aux clients. Cela entraîne une latence d'écriture d'une milliseconde et garantit qu'aucune opération d'écriture reconnue ne sera perdue en cas de panne.

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 durablement dans le journal Multi-AZ transactionnel, la latence des opérations d'écriture est équivalente à une ElastiCache absence de durabilité. Toutefois, les 10 dernières secondes d'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 tampon de durabilité. Le tampon de durabilité représente l'âge maximum de toute écriture qui a été 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 suit 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 confirmée 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 la microseconde pendant cette période. Une fois que les écritures en attente sont maintenues, 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 cluster down. Pour obtenir des conseils sur la configuration de vos clients afin de gérer cette erreur et d'autres erreurs transitoires, consultez Meilleures pratiques : clients Valkey/Redis OSS et 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 dans un plus large éventail de cas d'utilisation au-delà de 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 d'IA, l'état du flux de travail des agents d'IA, 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 jeux et les analyses en temps réel.