Confirmer d'abord le plan
Option 1 : diminuer l'inventaire après avoir passé une commande; l'utilisateur passe une commande, puis l'inventaire est verrouillé pour déterminer si l'inventaire est suffisant. L'utilisateur termine la commande, réduit l'inventaire et enfin libère le verrouillage de l'inventaire.
Option 2 : réduire l'inventaire uniquement après le paiement; l'utilisateur paie, puis verrouille l'inventaire pour déterminer si l'inventaire est suffisant, l'utilisateur termine le paiement, réduit l'inventaire et enfin libère le verrouillage de l'inventaire.
Bien sûr, il y a d'autres options, et ici seulement je développe ma pensée.
(Il y a un petit détail dans le processus de verrouillage de l'inventaire, veuillez consulter la pièce jointe 1 )
Deux comparer différents régimes
Schéma 1
1) Si 100 personnes passent une commande en même temps, une seule personne peut passer une commande avec succès.
2) À ce moment, la commande doit avoir un statut expiré. Si la commande expire, l'inventaire est verrouillé et le verrou est libéré après avoir réécrit l'inventaire.
Option 2
1) 100 personnes peuvent passer des commandes en même temps, mais lorsque 100 personnes paient en même temps, une seule personne paie avec succès.
Normalement, l'utilisateur qui ajoute le produit au panier >>> l'utilisateur qui a passé la commande> = l'utilisateur qui a payé. Du point de vue du verrouillage de l'inventaire, si le verrou est placé lors de la commande, l'expérience utilisateur de passer un accès concurrentiel élevé peut être médiocre, car une seule personne peut passer une commande en même temps et les performances du serveur peuvent être médiocres; Le nombre de demandes augmente, donc le nombre de demandes de verrous augmente également, et l'utilisateur qui paie peut être inférieur à l'utilisateur qui a passé la commande. Le nombre de demandes de verrous sera théoriquement beaucoup moins.
Ma suggestion est:
Pour les projets de commerce électronique ordinaires, je pense que le schéma 1 est suffisant, car le processus de passation d'une commande est simple et le paiement peut impliquer beaucoup de travail. Si l'inventaire est bloqué dans le paiement, il y aura beaucoup de choses à considérer.
Cependant, dans des scénarios de forte concurrence ou de pointe, il peut être nécessaire de verrouiller l'inventaire lors du paiement. D'un point de vue commercial, il doit y avoir une main dans la main et une main dans la main; d'un point de vue code, le paiement est fortement associé à la réduction des stocks, et les surventes et les incohérences des stocks sont considérablement réduites. S'il s'agit d'une commande pour verrouiller l'inventaire, au cas où l'utilisateur annule la commande Est-il nécessaire de rajouter l'inventaire? Dans ce cas, il est fort possible que l'inventaire ne corresponde pas à la consommation réelle en cas de concurrence élevée.
Implémentation et optimisation
L'inventaire des commandes de marchandises n'est pas seulement une fonction permettant aux utilisateurs de passer des commandes, mais fournit également une entrée permettant aux commerçants de modifier l'inventaire en arrière-plan de gestion. Ensuite, il y a deux endroits où l'inventaire doit être utilisé et la concurrence doit être prise en compte.
Architecture monolithique
L'architecture monolithique est la plus simple pour réaliser cette activité, mais les performances sont également les pires.
Dans l'architecture monolithique, qu'il s'agisse d'une opération utilisateur ou d'un inventaire d'opérations d'arrière-plan administrateur, il est placé, puis déployé sur la machine. Pour le moment, le verrou d'inventaire est un verrou global. Lorsque l'utilisateur passe une commande, l'administrateur doit obtenir le verrou du verrou d'inventaire global pour modifier l'inventaire, puis le libérer après avoir exécuté le code métier.
Il y a un problème avec cette architecture monolithique. Le degré de couplage est trop élevé. Une fois que l'arrière-plan de gestion modifie l'inventaire pour occuper le verrou d'inventaire, l'utilisateur ne peut pas passer de commande pour acheter les marchandises. S'il s'agit d'une entreprise avec peu d'achats, l'architecture monolithique peut répondre aux besoins de base. Ce type d'implémentation est peu coûteux et facile à entretenir, mais ne peut pas prendre en charge une concurrence élevée.
Comme la plupart des petites et moyennes entreprises, j'estime que la commande d'un jour est inférieure à 1000 et que l'architecture à une seule trame est complètement suffisante. Elle n'a pas besoin d'être transformée dans le schéma suivant, ce qui augmente la complexité du niveau de puissance.
Plan d'optimisation
Si le nombre de commandes de blocs de croissance commerciale augmente, l'architecture monolithique ci-dessus présente des limites. En particulier, la plupart des architectures actuelles des sociétés Internet sont distribuées par des microservices.
1) Tout d'abord, après chaque verrou, vous devez interroger l'inventaire à partir de la base de données pour déterminer l'inventaire, puis l'utilisateur doit utiliser la base de données pour modifier l'inventaire après avoir passé la commande. Le fonctionnement de la base de données nécessite du temps. Si un utilisateur passe une commande trop lentement sous un trafic élevé, les autres utilisateurs devront attendre qu'il termine le traitement. L'expérience utilisateur est trop mauvaise
2) Deuxièmement, la plupart des architectures actuelles sont distribuées et des micro-services. Les utilisateurs qui commandent la réduction des stocks et la gestion des stocks de modification en arrière-plan sont généralement divisés en deux services: le service de commande et le service d'inventaire.
La première étape d'optimisation. Pour résoudre le problème de passer une commande car il prend trop de temps pour faire fonctionner la base de données, nous pouvons mettre l'inventaire dans le cache (généralement redis), puis ajouter le verrou redis à l'inventaire dans redis, exécuter la commande et réduire l'inventaire dans redis . L'avantage de cela est d'augmenter le taux de commandes des utilisateurs et d'augmenter la quantité de simultanéité; deuxièmement, les commandes des utilisateurs sont découplées des activités de back-end de gestion et étendues pour les futurs services fractionnés. Comme indiqué ci-dessous:
Bien que les performances aient été améliorées, de nouveaux problèmes sont apparus, des problèmes de cohérence des données. Maintenant, l'entreprise est séparée séparément, les commandes utilisateur, les verrous redis et l'inventaire redis peuvent être exploités. De même, la gestion de l'inventaire de modification en arrière-plan, l'inventaire de la base de données d'opération de verrouillage peut être. Mais comment assurer la cohérence de l'inventaire dans ces deux lieux?
Utilisez la file d'attente de messages pour réduire l'inventaire de la base de données
Une fois que l'utilisateur a correctement passé une commande, envoyez un message à la file d'attente de messages, puis consommez le message dans l'entreprise d'arrière-plan de gestion pour réduire l'inventaire, comme illustré dans la figure:
Si la transmission fiable du message est garantie, alors l'inventaire de l'utilisateur après la commande et l'inventaire de la base de données peuvent être garantis pour atteindre la cohérence finale.
Inventaire simultané interrompu
Que faire si l'arrière-plan de gestion doit modifier l'inventaire et le synchroniser avec redis? La solution possible consiste à laisser le commerçant cesser de vendre des marchandises, puis à juger si l'inventaire de redis est cohérent avec l'inventaire de la base de données. S'ils sont cohérents, le commerçant peut modifier l'inventaire et mettre à jour l'inventaire de la base de données et l'inventaire redis après la modification. S'ils ne sont pas cohérents, vous devez savoir si l'arrière-plan de gestion n'a pas consommé la file d'attente de messages ou d'autres problèmes. Si vous ne les avez pas consommés, laissez le marchand attendre un certain temps. S'il y a d'autres problèmes, le programmeur doit les reprendre. Vérifiez le système pour savoir ce qui n'a pas fonctionné.
Distribution de microservices
En fait, il s'agit de diviser la structure unique, et la solution spécifique est inchangée. Cela dépend de l'entreprise. S'il n'y a pas beaucoup de commandes, il n'est pas nécessaire de les diviser en services de commandes et de services d'inventaire ou de les découpler. La structure monolithique initiale est suffisante. Quant à la solution optimisée, je pense qu'elle sera utilisée par les licornes ou les grandes entreprises. Peut-être que ma perspective technique ou commerciale n'a pas atteint ce niveau.
D'autres questions
Parce qu'avant l'entretien, j'ai souvent posé la question de l'inventaire des matières premières. Maintenant j'écris simplement ma propre pensée, il doit y avoir quelque chose qui ne va pas. Il y a encore beaucoup de problèmes que je ne veux pas considérer. Après tout, je n'ai pas fait cette affaire. Par exemple, dans la production, la commande est envoyée à plusieurs reprises parce que l'utilisateur clique trop vite ou le problème de réseau.
Hors sujet
C'est une suggestion: au début, trouver un emploi pour trouver une entreprise stable, puis travailler pendant quelques années pour accumuler la technologie. Lors de mon entretien, j'ai changé 3 entreprises dans mon CV pendant 3 ans et à chaque entretien, je me demandais pourquoi j'arrêtais fréquemment. De plus, le curriculum vitae des grandes entreprises peut difficilement être interrogé, les aspects techniques des petites et moyennes entreprises sont passés, mais le côté RH peut aussi vous pincer à cause de ce problème. Il y a aussi à considérer de l'entreprise, les entreprises peuvent stimuler l'amélioration de la technologie. (PS: Guangzhou est-elle vraiment une ville de premier rang? Le salaire est vraiment bas, ne venez pas à Guangzhou pour l'informatique, ne venez pas à Guangzhou, ne venez pas)
Pièce jointe 1:
Dans le scénario de simultanéité élevée ou de pic, qu'il s'agisse de l'option 1 ou de l'option 2, si l'inventaire est 0, s'il est toujours verrouillé à chaque fois pour passer par le processus, c'est-à-dire que l'inventaire est verrouillé, pour déterminer si l'inventaire est suffisant, les commandes utilisateur sont terminées et l'inventaire est réduit Et enfin, relâchez le verrou d'inventaire, la réponse est définitivement non.
Pensez au code qui implémente le modèle singleton en Java, en utilisant deux déclarations de jugement, alors nous pouvons également utiliser cette méthode dans ce scénario. Sortez et vérifiez l'inventaire une fois, puis déterminez s'il est 0. Si c'est 0, revenez directement. S'il n'est pas 0, alors l'inventaire est verrouillé, pour déterminer si l'inventaire est suffisant, l'utilisateur commande (ou paie) pour terminer, réduire l'inventaire et enfin débloquer le verrou d'inventaire. . Prenons l'exemple du stock de serrure unique suivant:
