Comment une entreprise comme Amazon évite-t-elle les goulots d'étranglement pour accéder à la couche de base de données?


29

Si vous imaginez une entreprise comme Amazon (ou toute autre grande application Web de commerce électronique) qui exploite une boutique en ligne à grande échelle et ne dispose que d'une quantité limitée d'articles physiques dans ses entrepôts, comment peuvent-ils optimiser cela de sorte qu'il n'y ait pas goulot d'étranglement unique? Bien sûr, ils doivent avoir un certain nombre de bases de données avec réplication et de nombreux serveurs qui gèrent la charge indépendamment. Cependant, si plusieurs utilisateurs sont servis par des serveurs distincts et essaient tous les deux d'ajouter le même article à leur panier, pour lequel il n'en reste qu'un, il doit y avoir une "source de vérité" pour la quantité restante pour cet article. Cela ne signifierait-il pas qu'au minimum, tous les utilisateurs accédant aux informations sur le produit pour un seul article doivent interroger la même base de données en série?

Je voudrais comprendre comment vous pouvez exploiter un magasin aussi grand en utilisant l'informatique distribuée et ne pas créer un énorme goulot d'étranglement sur une seule base de données contenant des informations d'inventaire.


Architecture d'Amazon au milieu des années 2000 (toujours pertinente pour votre question): highscalability.com/amazon-architecture
Joeri Sebrechts

Cela se produit également avec des sièges dans les avions (ou, par exemple, pour des vacances à forfait où un article dans le panier représente un vol là-bas, une voiture de location, un séjour à l'hôtel et un vol de retour), de nombreuses agences différentes vendant les mêmes sièges sur leurs sites respectifs . Les solutions sont innombrables mais elles se résument toutes à avoir une base de données de vérité finale avec le statut réel de chaque partie quelque part.
RemcoGerlich

1
@RemcoGerlich: la façon dont vous dites "une dernière base de données de vérité" me fait penser à une seule machine avec une grande base de données sacrée . En réalité, ce qui se passe pour les données critiques est plutôt que toutes les transactions atteignent plusieurs serveurs à la fois, garantissant que toutes ces bases de données sont synchronisées à tout moment.
Arseni Mourzenko

Réponses:


27

Cependant, si plusieurs utilisateurs sont servis par des serveurs distincts et essaient tous les deux d'ajouter le même article à leur panier, pour lequel il n'en reste qu'un, il doit y avoir une "source de vérité" pour la quantité restante pour cet article.

Pas vraiment. Ce n'est pas un problème qui nécessite une solution technique 100% parfaite, car les deux cas d'erreur ont une solution métier qui n'est pas très chère:

  • Si vous informez à tort un utilisateur qu'un article est épuisé, vous perdez une vente. Si vous vendez des millions d'articles chaque jour et que cela se produit peut-être une ou deux fois par jour, cela se perd dans le bruit.
  • Si vous acceptez une commande et que vous la traitez, vous constatez que l'article est épuisé, il vous suffit d'en informer le client et de lui laisser le choix d'attendre jusqu'à ce que vous puissiez réapprovisionner ou d'annuler la commande. Vous avez un client légèrement ennuyé. Encore une fois, ce n'est pas un gros problème lorsque 99,99% des commandes fonctionnent correctement.

En fait, j'ai moi-même récemment expérimenté le deuxième cas, ce n'est donc pas hypothétique: c'est ce qui se passe et comment Amazon le gère.

C'est un concept qui s'applique souvent lorsque vous avez un problème théoriquement très difficile à résoudre (que ce soit en termes de performances, d'optimisation ou autre): vous pouvez souvent vivre avec une solution qui fonctionne très bien dans la plupart des cas et l'accepter parfois échoue, tant que vous pouvez détecter et gérer les échecs lorsqu'ils se produisent.


2
Les mémoires, les suppositions et les excuses de Pat Helland également abordées dans Building on Quicksand et les transactions compensatoires sont des idées pertinentes ici.
Derek Elkins

1
Vous avez dit "pas vraiment" mais j'ai l'impression que vous êtes d'accord avec ce que j'ai suggéré. Cela ressemble à ce que vous dites, c'est que lorsque l'utilisateur est en train de naviguer, nous donnons une approximation en cache de l'inventaire restant, mais ce n'est que lorsqu'il essaie réellement de finaliser l'achat que nous faisons l'écriture pour décrémenter l'inventaire restant. La base de données contenant cette valeur exécutera chaque transaction de manière atomique, et si deux utilisateurs essaient en même temps, nous affichons un message d'erreur pour le second, car il est peu probable que cela se produise. Donc, il y a finalement un entier sur une seule machine qui contient "la vérité".
mattgmg1990

2
@ mattgmg1990: correct, finalement vous devez bien sûr connaître "la vérité" quelque part, mais la différence importante est que le traitement des commandes peut être effectué dans une file d'attente afin que vous n'ayez pas du tout besoin d'un accès en écriture atomique simultané. Dans mon cas, le "message d'erreur" est venu des heures après avoir terminé la commande sur le site Amazon - j'ai reçu un e-mail me disant qu'ils avaient des problèmes avec la fourniture de cet article et je pouvais choisir d'annuler la commande ou de ne rien faire et d'attendre pour eux de l'accomplir. J'ai fait ce dernier car je n'avais pas besoin de l'article immédiatement, et ils l'ont effectivement livré plusieurs semaines plus tard.
Michael Borgwardt

@DerekElkins c'est un excellent article, en particulier le point sur les données numériques étant une représentation de la réalité qui est inévitablement imparfaite car la réalité peut toujours avoir des changements que votre système ne peut pas automatiquement connaître.
Michael Borgwardt

6

Une combinaison de

  • hachage
  • sharding
  • réplication
  • Distribution
  • basculement élevé
  • magasins de valeurs-clés

Il n'y a pas de magie, juste des situations de plus en plus complexes. Tout comme le DNS, il est conçu pour évoluer.

La «version unique de la vérité» fait partie de tels systèmes. La génération d'une nouvelle clé devient une opération plus complexe que la simple génération du numéro suivant dans la séquence. Par exemple, d'autres séquences existent. C'est le genre de complexité que les systèmes de bases de données distribuées peuvent gérer et ils le font en effectuant plusieurs opérations vers et depuis les composants lors de la création de nouveaux objets, en les mettant à la disposition des autres, en veillant à ce que les séquences soient uniques lorsqu'elles doivent l'être, des clés composites, etc. .


J'ai lu sur chacun de ces concepts, mais la partie sur laquelle je reste coincé est le scénario spécifique de l'inventaire restant. S'il ne reste que 5 livres et que les utilisateurs font des demandes sur plusieurs serveurs, se résolvent-ils toujours dans une seule table de base de données quand vient le temps d'interroger l'inventaire restant pour s'assurer que deux utilisateurs ne peuvent pas obtenir le dernier livre en même temps? Quelle utilisation spécifique de ce qui précède permet de ne pas ralentir l'ensemble du système et la réplication peut toujours être utile avec plusieurs instances de base de données?
mattgmg1990

Ajouté un peu plus. je ne peux pas vraiment expliquer toute la complexité de ce format, désolé.
Michael Durrant

1
Seules certaines personnes sont intéressées par un livre donné, cela signifie que le livre peut être manipulé par un fragment avec une charge relativement faible.
Basilevs

6
Je pense que dans le scénario que vous décrivez, le système n'a qu'à présenter des excuses à l'utilisateur que quelqu'un d'autre a acheté la dernière copie. J'imagine que cela se produit de temps en temps.
Matthew James Briggs

1
Je parie qu'il ne reste que 5 livres, l' indicateur est moins informatique et plus marketing.
mouviciel

5

J'ai vu le problème «Dernier article en stock» résolu de la manière suivante:

Mettez à jour quotidiennement tous les niveaux de stock et signalez les produits comme étant haut, bas, sur commande ou en rupture de stock en fonction des niveaux de seuil.

Évidemment, ce sont les articles «à faible stock» qui sont problématiques

  • Articles avec des niveaux de stock élevés

Ne vous embêtez pas à vérifier le niveau des stocks. Passez simplement la commande

  • Articles avec de faibles niveaux de stock

Avertir l'utilisateur lors de la navigation sur «Les derniers restants!». quand ils vont payer, vérifier et décrémenter le stock. En cas de rupture de stock, mettez à jour le statut de l'article.

De cette façon, vous ne accédez à la base de données que pour les articles «à faible stock» et vous ne le faites que lorsque le client est assez loin dans le processus d'achat. Le coût est que certains clients ne pourront pas finaliser leur achat.

Cependant, dans la plupart des cas, `` en rupture de stock '' signifie simplement que vous attendez une autre livraison, vous souhaitez donc accepter la commande de toute façon et peut-être simplement afficher un avertissement ou restreindre les options de livraison. Ces clients ne sont donc pas perdus.

Pendant les périodes de chargement élevées telles que les ventes, vous pouvez même désactiver la vérification des stocks et envoyer un e-mail aux clients plus tard, `` désolé, nous n'avons plus de X, souhaitez-vous que Y ''

Essentiellement, le but de toute plate-forme de commerce électronique n'est jamais lu dans la base de données. Toujours servir les pages mises en cache et faire tout côté client.


2

Dans cette vidéo, Martin Fowler discute des bases de données NoSQL:

https://www.youtube.com/watch?v=qI_g07C_Q5I

L'un des points (quelque part là-bas), c'est que des endroits comme Amazon préfèrent garder 99% des gens heureux en acceptant leur commande sans pouvoir vérifier "avec certitude" si elle est réellement disponible, et peut-être irriter un très faible pourcentage en ayant pour dire "désolé, on dirait que quelqu'un vous a battu."

Autrement dit, il n'y a pas de véritable manipulation pour le scénario que vous décrivez, juste qu'Amazon profite du doute basé sur la dernière lecture d'inventaire réussie, et si une transaction simultanée s'est glissée entre les deux - oupsie.

(btw, c'est une excellente vidéo si vous êtes curieux de NoSQL)

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.