Comment une entreprise comme Amazon évite-t-elle les goulots d'étranglement pour accéder à la couche de base de données?
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 signifie-t-il pas que, à tout le moins, 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.
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 parfaite à 100%, car les deux cas d'erreur ont une solution métier qui n'est pas très chère:
- Si vous informez un utilisateur par erreur 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.
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 vu le problème "Dernier article en stock" résolu de la manière suivante:
Mettez à jour tous les niveaux de stock quotidiennement 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 accédez uniquement à la base de données 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.
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à-dedans), 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 savoir NoSQL)