Lire l'incohérence des données immédiatement après l'écriture avec Mongo DB Replication pendant le développement réel du service

J'ai rencontré un problème lors de l'utilisation de MongoDB lors du développement d'un service réel. Le problème était que si les mêmes données étaient lues immédiatement après leur écriture, elles n'étaient pas confirmées. À l’époque, je ne connaissais pas grand chose sur le sujet, donc j’y passais beaucoup de temps et j’avais du mal. J'ai écrit sur les circonstances et les causes de ce problème.

Situation problématique

• À cette époque, l'entreprise utilisait principalement MongoDB dans de nombreux services.
• Problèmes découverts lors de la création d'un nouveau service et de la préparation du lancement pour un lancement mondial. Après les étapes de tests, un comportement anormal s'est produit lors de la mise en production du service
  • Les requêtes demandées au serveur échouent par intermittence (les requêtes du serveur appelées depuis le client écrivent en interne mongodb puis relisent les données)
  • En fonctionnement normal, les données écrites doivent être relues et l'opération suivante doit être effectuée, mais en cas d'échec, une erreur se produit dans le client.
  • Les requêtes sont effectuées selon le flux suivant :
    • Appel client
    • Demandez le service AWS depuis le serveur et attendez le résultat
    • Écrivez les résultats sur mongodb lorsque le service AWS est terminé
    • Après l'écriture, relisez les données de mongodb et effectuez les actions suivantes
  • Lorsque vous examinez la requête du service AWS sur le serveur, le service AWS fonctionnait normalement.
  • Lorsque je suis allé directement dans MongoDB pour vérifier la partie écriture du serveur, les données existaient réellement. En d’autres termes, il a été confirmé qu’il n’y avait aucun problème avec l’opération d’écriture.
  • La partie lecture de la requête du serveur a échoué, mais des données ont été écrites dans la base de données. Une situation où la correction était difficile car la cause exacte n’était pas connue.
• Aucune anomalie trouvée lors de la vérification dans l'environnement de test existant
  • L'environnement de test est en cours de préparation. Un phénomène qui ne se produisait pas du tout au moment des tests s'est produit dans le produit.

Résolution

• Au début, cela n'a pas été reconnu comme une différence d'environnement, mais cela a été pensé à un bug dans le code et la logique a été vérifiée. Même après plusieurs vérifications, je n'ai trouvé aucun problème majeur.
• J'ai continué à vérifier et je n'ai pas trouvé de solution, alors j'ai demandé à des collègues qui en savaient plus et j'ai vérifié ensemble.
  • C'est un problème que même mes collègues ne connaissent pas, il faut donc un certain temps pour le résoudre.
• A cette époque, j'ai appris un peu sur la base de données distribuée et j'ai pu en déduire le problème.
  • Comparez les différences entre l'étape et la production pour identifier les problèmes. En comparant les différences, les différences étaient les suivantes :
  • En phase, MongoDB fonctionne sur un seul nœud sans réplication.
  • En production, MongoDB dispose de deux nœuds secondaires en réplication.
• Dans l'environnement de production, un jeu de réplicas a été configuré pour la disponibilité.
  • Lors de la réplication, la production MongoDB écrit puis diffuse les données vers le nœud secondaire.
  • Puisqu'il n'y avait pas de paramètre séparé, si vous écrivez depuis db et lisez immédiatement, l'opération de lecture est effectuée avant que les données ne soient propagées vers le secondaire. secondaire transmet les données existantes comme valeur de réponse
    • Le temps de propagation a été confirmé comme étant d'environ 2 à 4 secondes.
  • Plus tard, lors de la vérification des données dans MongoDB Compass, le temps de propagation était écoulé et les données écrites lors de la lecture étaient correctement visibles.
• Les méthodes apparues à l'époque pour résoudre le problème ci-dessus sont les suivantes.
  • Attendez que l'état de la base de données change en interrogeant le client. Cela semblait être la méthode la plus simple.
  • Attendez que l'état de la base de données change en interrogeant le serveur. Du point de vue du client, les requêtes existantes peuvent être utilisées sans modification.
  • S'assurer que la propagation vers la requête mongodb est terminée et définie comme lisible, comme les requêtes ou les collections
• J'ai essayé la deuxième méthode parmi les méthodes ci-dessus. Plutôt que l'opération de lecture se produise immédiatement après l'écriture, un petit délai est ajouté entre l'écriture et la lecture
  • Vérifiez qu'il fonctionne normalement après avoir ajouté un délai
• Grâce à cela, j'ai appris un peu plus sur la théorie du CAP.
  • Dans le cas d'une structure distribuée, elle présente trois caractéristiques : cohérence, disponibilité et tolérance de partitionnement.
  • Pour satisfaire l'un de cohérence et de disponibilité, vous n'avez d'autre choix que d'abandonner l'autre.
    • Lorsque la cohérence est satisfaite : La valeur des données doit être la même quel que soit le nœud distribué auquel on accède. Si la cohérence est rompue, différentes données peuvent être transmises lors de la demande d'une requête.
    • Lorsque la disponibilité est satisfaite : offre la possibilité de traiter les demandes normalement même si un ou plusieurs nœuds distribués ne parviennent pas à se synchroniser.
  • Cas où la cohérence est rompue car la structure actuelle de la base de données satisfait à la disponibilité.

organiser

• Si la réplication est configurée dans la base de données, soyez prudent lorsque les temps d'écriture et de lecture sont différents
• Ce fut une bonne expérience de voir et de ressentir la théorie du CAP de mes propres yeux.
• Étudions le service que je développe chaque fois que j'en ai le temps. Vous ne pouvez pas tout savoir, mais plus vous en savez, plus cela est utile pour le dépannage.
• Veuillez noter que l'environnement entre la scène et la production peut être différent. En d’autres termes, des problèmes peuvent survenir s’il existe une différence entre l’environnement de test et l’environnement d’exploitation réel, et il serait préférable d’y réfléchir à l’avance.
  • Pour réduire le temps de débogage, ce serait une bonne idée de garder les environnements de production et de scène presque similaires ou identiques.
  • Le temps est aussi un coût. De nombreux éléments, comme les coûts de main d’œuvre et les retards d’ouverture des services, peuvent être retardés ou entraîner des coûts supplémentaires. Je pensais que ce serait bien d'avoir les mêmes paramètres de scène et de production tant que le coût n'était pas trop élevé par rapport au coût du serveur.