Salut, tout le monde.
Et bienvenue à nouveau.
Dans la vidéo d'aujourd'hui, nous allons parler du rôle des files d'attente de messages dans les transactions de base de données.
Alors allons-y et comprenons cela avec un cas d'utilisation.
Supposons donc que vous ayez une seule base de données hébergée sur RDF.
Or, en raison d'une promotion des ventes en cours, le nombre de transactions correctes qui ont eu lieu récemment
dans la base de données a atteint dix fois la charge normale.
Vous avez donc un grand nombre de transactions correctes qui se produisent actuellement, puisque vous avez une
seule base de données et que la charge est élevée, de nombreuses requêtes échouent régulièrement.
Et il y a une autre condition importante : les nouvelles promotions qui sont en cours et qui font
que la charge est 20 fois supérieure à la normale, ces promotions sont programmées tous les deux mois.
Il ne s'agit donc pas d'une activité continue 24 heures sur 24 et 7 jours sur 7 tout au long du mois.
Elle a lieu un mois sur deux.
Maintenant, sur la base de ce cas d'utilisation spécifique, voyons quelle est la solution que vous pouvez mettre
en œuvre.
Maintenant, l'une des solutions les plus simples que l'on pourrait supposer ici est d'augmenter directement
la taille de la base de données et d'augmenter également le nombre d'IOPS de provision afin qu'elle puisse gérer la charge 20 fois plus élevée
qui est actuellement en cours en raison de la promotion des ventes, bien que cela puisse fonctionner, mais il y a certaines
limites ici.
La première limitation est qu'il y aura un temps d'arrêt, donc si vous voulez faire évoluer verticalement cette
base de données, vous devrez arrêter resize puis relancer la base de données.
Il s'agit donc d'un défi spécifique.
Le deuxième défi est l'augmentation des coûts.
Par exemple, disons que vous avez maintenant mis à l'échelle la base de données qui avait auparavant deux Go de RAM, maintenant
votre base de données a 16 Go de RAM et les choses fonctionnent parfaitement bien.
Mais que se passe-t-il une fois la promotion de la vente terminée ?
Votre base de données de 16 Go fonctionnera en permanence, ce qui augmentera considérablement vos coûts.
Très bien.
C'est donc l'une des architectures que les organisations évitent généralement d'adopter, principalement en raison
de ces défis.
Pour surmonter ce problème, il existe une meilleure approche qui consiste à utiliser une file d'attente de messages.
Ainsi, dans ce type d'architecture, ce qui se passe, c'est qu'au lieu que les messages soient directement insérés dans
la base de données, ils sont maintenant insérés dans le cadre de la file d'attente ASCS et EC.
Deux instances vont extraire le message de la file d'attente et l'insérer dans la base de données en fonction
de la charge.
Disons que la base de données est déjà soumise à une charge très élevée.
Les messages peuvent alors rester dans la file d'attente US pendant une minute ou deux par exemple, et lorsque la charge de la base
de données augmente l'ensemble des EC, deux instances peuvent extraire le message et réinsérer les données dans la base de données.
Et ce type d'architecture, vous le verrez dans de nombreuses organisations.
Il convient de noter que dans ce type d'architecture, il y a un petit délai entre
le message envoyé par le client et le message inséré dans la base de données.
Il y aura donc un petit délai.
Mais pour la plupart des cas d'utilisation cette fois, le délai n'a pas vraiment d'importance.
Si vous avez changé votre nom de profil dans un forum spécifique et si ce nom de profil est mis à jour, disons après
2 à 3 minutes, cela n'a pas vraiment d'importance et ainsi de suite.
Il y a donc de nombreux cas d'utilisation où cela n'a pas d'importance.
Mais pour les cas d'utilisation où le délai n'est pas acceptable, ce type d'architecture est
à éviter.
Donc, encore une fois, dans les examens, selon le cas d'utilisation qu'ils donnent, vous pouvez aller de l'avant et sélectionner la réponse appropriée.
C'est ainsi que se termine la vidéo d'aujourd'hui.