Redis Cluster ne garantit pas une forte cohérence. Dans certains scénarios particuliers, le client peut toujours perdre des données même s'il reçoit une confirmation d'écriture.
Scénario 1 : Réplication asynchrone
le client écrit sur le maître B
le maître B répond OK
le maître B se synchronise avec l'esclave B1 B2 B3
B répond au client sans attendre la confirmation de B1 B2 B3, Si le maître tombe en panne avant que la synchronisation des esclaves ne soit terminée, l'un des esclaves sera sélectionné comme maître et les données précédemment écrites par le client seront perdues. La commande
wait peut améliorer la sécurité des données dans ce scénario. wait 命令可以增强这种场景的数据安全性。
wait bloquera le client actuel jusqu'à ce que l'opération d'écriture précédente soit synchronisée avec succès par le nombre spécifié d'esclaves.
wait peut améliorer la sécurité des données, mais cela ne garantit pas une forte cohérence.
Car même si cette méthode de réplication synchrone est utilisée, il existe une situation particulière : un esclave qui n'a pas terminé la synchronisation est élu maître. Scénario 2 : Partition réseau 6 nœuds A, B, C, A1, B1, C1, 3 maîtres, 3 esclaves et un client, code Z1> .
Après la partition réseau, 2 zones ont été formées <. code>A , C, A1, B1, C1 et B Z1.
🎜🎜🎜🎜À ce moment, Z1 peut toujours demander à B W écrit, si dans un court laps de temps période de temps Si la partition est restaurée, alors il n'y a pas de problème. L'ensemble du cluster continuera à fonctionner normalement. Cependant, si le temps passe, B1 deviendra le maître de la partition où il se trouve et les données écrites par Z1 sur celle-ci. B sera perdu. 🎜🎜fenêtre maximale (fenêtre de temps maximale) peut réduire la perte de données et contrôler le nombre total d'écritures de Z1 vers B : 🎜
Après une certaine période de temps, la majorité de la partition sera élu, esclave Devenez maître. A ce moment, le maître du côté minoritaire de la partition refusera de recevoir des demandes d'écriture.
🎜Cette 🎜durée🎜 est très importante et s'appelle le 🎜délai d'expiration du nœud🎜. 🎜🎜Une fois qu'un maître atteint le délai d'expiration, il est considéré comme défectueux, entre dans l'état d'erreur, cesse de recevoir des demandes d'écriture et peut être remplacé par un esclave. 🎜🎜Résumé🎜🎜Redis Cluster ne garantit pas une forte cohérence, et il existe des scénarios dans lesquels des données sont perdues : 🎜🎜🎜Réplication asynchrone🎜🎜🎜Lorsque le maître est écrit avec succès, mais avant que la synchronisation de l'esclave ne soit terminée, le maître tombe en panne, l'esclave devient le maître et les données sont perdues. La commande 🎜🎜wait peut être utilisée pour la réplication synchrone, mais elle ne peut pas garantir complètement que les données ne seront pas perdues et cela affectera les performances. 🎜🎜🎜Partition réseau🎜🎜🎜Après le partitionnement, un maître continue de recevoir des demandes d'écriture. Après la récupération de la partition, le maître peut devenir un esclave et les données précédemment écrites seront perdues. 🎜🎜Vous pouvez définir le délai d'expiration du nœud pour réduire le nombre d'écritures reçues par le maître lors du partitionnement et réduire le coût de la perte de données. 🎜🎜🎜🎜Apprentissage recommandé : "🎜Tutoriel Redis🎜"🎜🎜🎜
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn