Ressources vidéo recommandées pour les ventes flash de produits sur les sites de commerce électronique PHP

Comme nous le savons tous, pour une fonction de vente flash de produits avec un trafic important et des exigences de stabilité extrêmement élevées, la technologie PHP traditionnelle est difficile à répondre aux exigences, elle nécessite donc l'aide de la conception de l'architecture du site Web, de la configuration du serveur, de l'équilibrage de charge, du CDN. accélération, analyse cloud, redis Il peut être réalisé par divers moyens. Ce cours est un cours PHP avancé qui présente principalement les idées d'implémentation de fonctions et n'implique pas l'implémentation spécifique du code.

Adresse de lecture du cours : http://www.php.cn/course/279.html

Le style d'enseignement du professeur :

Les cours sont conviviaux et naturels, sans prétention, ni prétentieux ni délibérément exagérés, mais parlent avec éloquence et prudence, entre enseignants et étudiants Dans une atmosphère d'égalité, la collaboration et l'harmonie, des échanges émotionnels silencieux sont réalisés, et le désir et l'exploration des connaissances sont intégrés dans des situations d'enseignement simples et réelles. Les étudiants acquièrent des connaissances grâce à une réflexion calme et une approbation silencieuse

Le point le plus difficile. dans cette vidéo se trouve l'architecture du projet Flash Kill - la couche de traitement des données :

1 Analyse commerciale Flash Kill

Processus commercial électronique normal (1) Produits de requête ; (2) Créer des commandes ; (3) Déduire l'inventaire ; (4) Mettre à jour les commandes ; (5) Paiement (6) Expéditions par le vendeur

Caractéristiques de l'entreprise de vente flash (1) Prix bas ; promotion ; (3) Épuisement instantané ; (4) Habituellement programmé pour être mis en rayon ; (5) Court terme, concurrence instantanée élevée

2 Défi technique Flash Kill

Supposons que un événement de vente flash sur un site Web ne lance qu'un seul produit et devrait attirer 10 000 personnes à participer à l'événement. Cela signifie que le nombre maximum de demandes simultanées est de 10 000. Les défis techniques auxquels le système de vente flash doit faire face sont :

.

Pour l'impact actuel sur l'activité du site Web L'activité de vente flash n'est qu'une activité supplémentaire du marketing de site Web. Cette activité présente les caractéristiques d'une courte durée et d'un grand nombre de visites simultanées. Si elle est déployée avec l'application originale du site Web, elle le sera. avoir inévitablement un impact sur l'activité existante et provoquer un léger inconfort. La prudence peut provoquer le crash de l'ensemble du site. Solution : Déployez le système de vente flash de manière indépendante, voire utilisez un nom de domaine indépendant pour l'isoler complètement du site Internet.

Chargement de l'application et de la base de données sous une concurrence élevée. Avant le début de la vente flash, les utilisateurs doivent continuer à actualiser la page du navigateur pour s'assurer qu'ils ne manqueront pas la vente flash. Si ces demandes suivent l'architecture générale de l'application du site Web, accédez au site Web. serveur d'applications et connectez-vous à la base de données, ce qui entraînera une pression de charge sur le serveur d'applications et le serveur de base de données. Solution : repensez la page produit de la vente flash, n'utilisez pas la page de détail du produit d'origine du site Web, le contenu de la page est statique et les demandes des utilisateurs n'ont pas besoin de passer par le service d'application.

Augmentation soudaine de la bande passante du réseau et du serveur Supposons que la taille de la page du produit soit de 200 Ko (principalement la taille de l'image du produit), alors la bande passante du réseau et du serveur requise est de 2G (200 Ko × 10 000). la nouvelle augmentation des activités de vente flash, dépassant la bande passante normalement utilisée par le site. Solution : En raison de la nouvelle bande passante réseau ajoutée par la vente flash, vous devez la racheter ou la louer auprès de l'opérateur. Afin de réduire la pression sur le serveur du site Web, les pages de produits de vente flash doivent être mises en cache dans le CDN et la bande passante d'exportation nouvellement ajoutée doit également être temporairement louée auprès du fournisseur de services CDN.

Les règles du jeu pour passer des commandes directes pour les ventes flash sont que vous ne pouvez commencer à passer des commandes de produits qu'après la vente flash. Avant cette date, vous ne pouvez parcourir que les informations sur les produits et ne pouvez pas passer de commandes. La page de commande est également une URL normale. Si vous obtenez cette URL, vous pouvez passer une commande sans attendre le début de la vente flash. Solution : Afin d'empêcher les utilisateurs d'accéder directement à l'URL de la page de commande, l'URL doit être rendue dynamique. Même les développeurs du système de vente flash ne peuvent pas accéder à l'URL de la page de commande avant le début de la vente flash. La méthode consiste à ajouter un nombre aléatoire généré par le serveur en tant que paramètre dans l'URL de la page de commande, qui ne peut être obtenu qu'au démarrage de la vente flash.

Comment contrôler l'éclairage du bouton d'achat sur la page produit de la vente flash. Le bouton d'achat ne peut être allumé que lorsque la vente flash démarre. Avant cela, il est gris. Si la page est générée dynamiquement, vous pouvez bien sûr créer une sortie de page de réponse côté serveur pour contrôler si le bouton est gris ou allumé. Cependant, afin de réduire la pression de charge côté serveur et de mieux utiliser l'optimisation des performances. méthodes telles que CDN et proxy inverse, ces pages sont conçues comme des pages statiques et mises en cache sur les CDN, les serveurs proxy inverse et même sur les navigateurs des utilisateurs. Lorsque la vente flash démarre, l'utilisateur actualise la page et la requête n'atteint jamais le serveur d'application. Solution : utilisez le contrôle de script JavaScript pour ajouter une référence de fichier JavaScript à la page statique du produit de vente flash. Le fichier JavaScript contient l'indicateur de début de vente flash. Lorsque la vente flash démarre, un nouveau fichier JavaScript est généré (le nom du fichier reste le même). mais le contenu est différent), mettez à jour le drapeau de début de la vente flash sur oui, et ajoutez les paramètres d'URL et de nombre aléatoire de la page de commande (ce nombre aléatoire n'en générera qu'un, c'est-à-dire que l'URL vue par tout le monde est la même. Le Le côté serveur peut utiliser Redis (serveur de cache distribué pour enregistrer des nombres aléatoires) et chargé par le navigateur de l'utilisateur pour contrôler l'affichage des pages de produits de vente flash. Ce fichier JavaScript peut être chargé avec un numéro de version aléatoire (par exemple, xx.js?v=32353823) afin qu'il ne soit pas mis en cache par les navigateurs, les CDN et les serveurs proxy inverses. Ce fichier JavaScript est si petit que même l'accès au serveur de fichiers JavaScript à chaque actualisation du navigateur n'exerce pas beaucoup de pression sur le cluster de serveurs et la bande passante du réseau.

Comment autoriser uniquement l'envoi de la première commande soumise au sous-système de commande. Puisqu'il n'y a qu'un seul utilisateur qui peut réussir la vente flash du produit, il est nécessaire de vérifier si une commande a été soumise lorsque l'utilisateur. soumet la commande. Si une commande a été soumise avec succès, le fichier JavaScript doit être mis à jour, le drapeau de démarrage de la vente flash est mis à jour sur Non et le bouton d'achat devient gris. En fait, étant donné qu'un seul utilisateur peut finalement soumettre une commande avec succès, afin de réduire la pression de charge sur le serveur de la page de commande, l'entrée de la page de commande peut être contrôlée. Seuls quelques utilisateurs peuvent accéder à la page de commande, et. les autres utilisateurs accèdent directement à la page de fin de la vente flash. Solution : Supposons que le cluster de serveurs de commandes comporte 10 serveurs et que chaque serveur n'accepte qu'un maximum de 10 demandes de commande. Avant que quiconque ne soumette une commande avec succès, si un serveur a déjà dix commandes et que certaines commandes n'ont pas été traitées, le scénario d'expérience utilisateur possible est que l'utilisateur clique pour la première fois sur le bouton d'achat et accède à la page terminée si vous actualisez la page. là encore, il peut être traité par un serveur qui n'a traité aucune commande. Lorsque vous accédez à la page de traitement des commandes, vous pouvez envisager d'utiliser des cookies pour le traiter, ce qui est conforme au principe de cohérence. Bien entendu, l'algorithme d'équilibrage de charge le moins connecté peut être utilisé et la probabilité de la situation ci-dessus est considérablement réduite.

Comment effectuer une inspection de précommande

S'il y a plus de 10 articles, l'utilisateur sera directement renvoyé à la page complétée

S'il n'y en a pas plus ; 10 articles, l'utilisateur peut saisir et remplir la page de commande et de confirmation

Le nombre total de produits en vente flash a été dépassé, et la page terminée sera renvoyée à l'utilisateur ; Le nombre total de produits en vente flash n'a pas été dépassé, et il est soumis au système de sous-commande

Vérifiez que le nombre global de commandes soumises :

Le serveur de commande vérifie le nombre ; des demandes de commandes traitées par la machine :

Les ventes flash sont généralement programmées pour être mises en rayon. Il existe de nombreuses manières de mettre en œuvre cette fonction. Cependant, la meilleure solution à l'heure actuelle consiste à régler à l'avance la durée de conservation du produit. L'utilisateur peut voir le produit à la réception, mais ne peut pas cliquer sur le bouton « Acheter maintenant ». Mais ce qu'il faut considérer, c'est que quelqu'un peut contourner les restrictions du front-end et lancer un achat directement via l'URL. Cela nécessite une synchronisation de l'horloge sur la page du produit front-end, ainsi que sur la page de bugs et la base de données back-end. Plus le backend est contrôlé, plus la sécurité est élevée. Pour les ventes flash chronométrées, il est nécessaire d’éviter les effets inattendus provoqués par les vendeurs modifiant les produits avant la vente flash. Ce changement particulier nécessite plusieurs évaluations. La modification est généralement interdite. Si des modifications sont nécessaires, vous pouvez suivre le processus de correction des données.

Il existe deux options pour réduire les stocks, l'une consiste à prendre des photos pour réduire les stocks, et l'autre est de payer pour réduire les stocks ; avec la méthode actuellement adoptée de « photographier pour réduire les stocks », prendre des photos prend juste ; un instant. L’expérience utilisateur sera meilleure.

L'inventaire provoquera le problème de « survente » : la quantité vendue est supérieure à la quantité en stock. En raison du problème des mises à jour simultanées de l'inventaire, lorsque l'inventaire réel est déjà insuffisant, l'inventaire continue de diminuer. résultant en le produit du vendeur Le nombre d'unités vendues a dépassé les attentes de la vente flash.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!