Parlez de la technologie de performance du site Web 12306.cn

À l'approche de la Fête du Printemps, les billets pour le site Web 12306.cn s'accumulent par secondes et les gens de tout le pays grondent Discutons des performances et de la mise en œuvre du site Web 12306. . Nous discuterons uniquement des problèmes de performances, pas de l'interface utilisateur, de l'expérience utilisateur ou des éléments fonctionnels qui séparent le paiement et l'achat et la commande de billets)

Business

Toute technologie est indissociable des besoins de l'entreprise, donc pour expliquer la question de la performance, je veux d'abord pour en parler, des problèmes d'affaires.

• 1. Certaines personnes peuvent comparer cette chose avec QQ ou des jeux en ligne . Mais je pense que les deux sont différents. Les jeux en ligne et QQ en ligne ou lors de la connexion accèdent à davantage de données propres à l'utilisateur, tandis que le système de réservation de billets accède aux données sur le volume de billets du centre, ce qui est différent. Ne pensez pas que les jeux en ligne ou QQ sont identiques simplement parce qu’ils fonctionnent. Les charges back-end des jeux en ligne et de QQ sont encore plus simples que celles des systèmes de commerce électronique.

• 2. Certaines personnes disent que la réservation de trains pendant la Fête du Printemps est comme une vente flash sur un site Web . C'est en effet très similaire, mais si vous ne réfléchissez pas au-delà de la surface, vous constaterez que c'est aussi quelque peu différent. D'une part, la question des billets de train s'accompagnera d'un grand nombre d'opérations de requête. Ce qui est encore plus BT, c'est que lors de la passation d'une commande, de nombreuses opérations cohérentes sur la base de données sont nécessaires. est la cohérence de chaque billet de tronçon du point de départ au point d'arrivée. D'autre part, les acheteurs ont de nombreux choix d'itinéraires, de trains et d'horaires, et ils changeront constamment leurs méthodes de commande. Quant aux ventes flash, tuez-les directement. Il n'y a pas tellement de requêtes et de problèmes de cohérence. De plus, concernant les ventes flash, il est possible de n'accepter que les demandes des N premiers utilisateurs (sans exploiter aucune donnée sur le backend, il suffit d'enregistrer les commandes de l'utilisateur). Pour ce type de commerce, il suffit de mettre les données disponibles. dans la mémoire cache. Pour le nombre de ventes flash, les données peuvent également être distribuées. Pour 100 produits, 10 peuvent être placés sur chacun des 10 serveurs. Il n'est pas nécessaire d'exploiter une base de données à ce moment-là. Une fois que le nombre de commandes est suffisant, arrêtez la vente flash puis écrivez dans la base de données par lots. Et il n’y a pas beaucoup d’articles en vente flash. Les billets de train ne sont pas aussi simples que les ventes flash. Pendant la période de voyage de la Fête du Printemps, presque tous les billets sont des billets chauds, et presque des gens de tout le pays viennent. Il y a aussi des affaires de transfert et l'inventaire de plusieurs lignes doit être traité. . Voulez-vous penser à quel point c'est difficile. (Le Double Eleven de Taobao ne compte que 3 millions d’utilisateurs, alors que les billets de train peuvent atteindre instantanément des dizaines de millions, voire des centaines de millions).

• 3.

  Certains comparent ce système avec le système de billetterie olympique . Je pense que c'est encore différent. Bien que le système de billetterie olympique ait été aboli dès sa mise en ligne. Mais les Jeux olympiques utilisent une méthode de loterie, ce qui signifie qu'il n'y a pas de méthode du premier arrivé, premier servi. De plus, il s'agit d'une loterie après l'événement. Il suffit de recevoir les informations au préalable et il n'est pas nécessaire de garantir la cohérence des données au préalable. . Il n'y a pas de verrous et il est facile de s'étendre horizontalement.

• 4.

  Le système de réservation doit être très similaire au système de commande du commerce électronique, qui nécessitent tous deux une gestion des stocks : 1) occupation de l'inventaire, 2) paiement (Facultatif), 3) L'opération de déduction des stocks. Cela nécessite une vérification de cohérence, c'est-à-dire que les données doivent être verrouillées pendant la simultanéité. Les sociétés de commerce électronique B2C le feront essentiellement de manière asynchrone. C'est-à-dire que la commande que vous passez n'est pas traitée immédiatement, mais retardée. Ce n'est que si elle est traitée avec succès que le système vous enverra un e-mail de confirmation indiquant que la commande a réussi. . Je crois que de nombreux amis ont reçu des e-mails indiquant que l'enregistrement de la commande avait échoué. Cela signifie que la cohérence des données est un goulot d'étranglement en cas de concurrence .

• 5.

  Le secteur de la billetterie ferroviaire est très anormal Il utilise une libération soudaine de billets, et certains billets sont loin d'être suffisants pour que tout le monde puisse les partager, donc tout le monde se contente de le partager. Il y aura une pratique consistant à récupérer des billets, ce qui est une activité aux caractéristiques chinoises. Ainsi, lorsque les billets seront libérés, des millions, voire des dizaines de millions de personnes se précipiteront pour se renseigner et passer des commandes. En quelques dizaines de minutes, un site Web peut recevoir des dizaines de millions de visites. C'est une chose terrifiante. On dit que la visite maximale de 12306 est de 1 milliard de PV, concentrée de 8h00 à 10h00, et que le pic de visite par seconde atteint des dizaines de millions.

Dites encore quelques mots :

• L'inventaire est un cauchemar pour le B2C, et la gestion des stocks est assez compliquée. Si vous n’y croyez pas, vous pouvez demander à toutes les entreprises de vente au détail traditionnelles et en ligne de voir à quel point il leur est difficile de gérer leurs stocks. Sinon, il n’y aurait pas autant de gens qui poseraient des questions sur l’inventaire de Vanke. (Vous pouvez également lire "La biographie de Steve Jobs" et vous saurez pourquoi Tim a pris la direction d'Apple. La raison principale est qu'il a résolu le problème du cycle de stocks d'Apple)

• Pour un site Web, la charge élevée de navigation sur le Web est facile à gérer. La charge de requêtes est difficile à gérer, mais elle peut toujours être gérée en mettant en cache les résultats des requêtes. Le plus difficile est la charge de passation de commandes. . Parce que nous devons accéder à l’inventaire, la passation des commandes se fait essentiellement de manière asynchrone. Lors du Double 11 de l'année dernière, le nombre de commandes par heure de Taobao était d'environ 600 000, tandis que JD.com ne pouvait prendre en charge que 400 000 commandes par jour (encore pire que 12 306 Amazon pouvait prendre en charge 700 000 commandes par heure il y a cinq ans). On voit que l'opération de passation de commandes n'est pas aussi performante qu'on le pense.

• Taobao est beaucoup plus simple que les sites Web B2C, car il n'y a pas d'entrepôt, donc il n'y a pas de N entrepôts comme B2C pour mettre à jour et mettre à jour l'inventaire du même produit Opération de requête. Lors de la passation d'une commande, le site B2C doit trouver un entrepôt proche de l'utilisateur et disposant d'un stock, ce qui nécessite de nombreux calculs. Imaginez, vous avez acheté un livre à Pékin. Si l'entrepôt de Pékin est en rupture de stock, vous devez le transférer des entrepôts environnants. Ensuite, vous devez vérifier si l'entrepôt de Shenyang ou de Xi'an a la marchandise. , il faut regarder l'entrepôt du Jiangsu, etc. Sur Taobao, il n'y a pas tellement de choses, chaque commerçant a son propre inventaire, l'inventaire n'est qu'un numéro, et l'inventaire est distribué aux commerçants, ce qui favorise l'expansion des performances.

• La cohérence des données est le véritable goulot d'étranglement des performances. Certaines personnes disent que nginx peut gérer 100 000 requêtes statiques par seconde, je n'en doute pas. Mais ce n'est qu'une requête statique. En théorie, tant que la bande passante et les E/S sont suffisamment puissantes, que le serveur dispose de suffisamment de puissance de calcul et que le nombre de connexions simultanées prises en charge peut supporter l'établissement de 100 000 liaisons TCP, il y aura aucun problème. Mais face à la cohérence des données, ces 100 000 sont totalement devenus une valeur théorique inaccessible.

J'ai tellement dit, je veux juste vous dire d'un point de vue commercial, nous devons vraiment comprendre les perversions du secteur de la réservation de billets de chemin de fer pour la Fête du Printemps d'un point de vue commercial.

Technologie d'optimisation des performances frontales

Pour résoudre les problèmes de performances, je vais les énumérer ci-dessous. Je pense que le site Web 12306 utilise les éléments suivants. La technologie fera un saut qualitatif dans ses performances.

1. Équilibrage de charge frontal

Grâce à l'équilibreur de charge DNS (généralement redirigé sur le routeur en fonction de la charge de routage), l'accès des utilisateurs peut être réparti uniformément entre sur plusieurs serveurs Web. Cela réduit la charge des requêtes sur le serveur Web. Étant donné que les requêtes http sont des tâches courtes, cette fonction peut être complétée via un équilibreur de charge très simple. Il est préférable de disposer d'un réseau CDN permettant aux utilisateurs de se connecter au serveur le plus proche (le CDN est généralement accompagné d'un stockage distribué). (Pour des instructions plus détaillées sur l'équilibrage de charge, voir « Équilibrage de charge backend »)

2 Réduisez le nombre de liens front-end

J'ai jeté un œil à 12306. .cn et l'ai ouvert. La page d'accueil doit établir plus de 60 connexions HTTP et la page de réservation de billets contient plus de 70 requêtes HTTP. Les navigateurs d'aujourd'hui nécessitent tous des requêtes simultanées (bien sûr, le nombre de requêtes simultanées pour une page de navigateur est limité, mais vous ne pouvez pas arrêter les utilisateurs. Ouvrez plusieurs pages et la connexion TCP du serveur principal est déconnectée au niveau du front-end et ne sera pas libérée immédiatement ou de manière importante). Par conséquent, tant qu'il y a 1 million d'utilisateurs, il peut y avoir 60 millions de liens (après la première visite, avec le cache du navigateur, ce nombre diminuera, même s'il n'est que de 20 %, il s'agit toujours d'un nombre d'un million de liens). liens), et bien plus encore. Une page de requête de connexion conviendrait parfaitement. Tapez le js dans un fichier, tapez le css dans un fichier, tapez l'icône dans un fichier et utilisez css pour l'afficher en blocs. Gardez le nombre de liens au minimum.

3. Réduisez la taille des pages Web et augmentez la bande passante

Toutes les entreprises dans le monde n'osent pas fournir des services d'image, car les images consomment trop de bande passante. À l'ère actuelle du haut débit, il est difficile pour quiconque de comprendre la situation à l'ère de l'accès commuté, où l'on avait peur d'utiliser des images lors de la création d'une page d'images (c'est également le cas lors de la navigation sur des téléphones mobiles). J'ai vérifié la taille totale du fichier à télécharger sur la page d'accueil 12306, qui est d'environ 900 Ko. Si vous l'avez visité, le navigateur mettra beaucoup de cache en cache pour vous et vous n'aurez qu'à télécharger environ 10 000 fichiers. Mais nous pouvons imaginer un cas extrême : 1 million d’utilisateurs visitent en même temps, et ils visitent tous pour la première fois. Chaque personne doit télécharger 1 M. S’il doit être renvoyé dans les 120 secondes, il en faut 1 M*. 1M /120 * 8 = bande passante de 66 Gbit/s. C'est incroyable. Donc, j'estime que ce jour-là, la congestion de 12306 devrait essentiellement correspondre à la bande passante du réseau, donc ce que vous pourriez voir n'est pas une réponse. Plus tard, le cache du navigateur a aidé 12306 à réduire considérablement l'utilisation de la bande passante, de sorte que la charge a été immédiatement transférée au backend et le goulot d'étranglement du traitement des données du backend a été immédiatement éliminé. Vous verrez donc beaucoup d’erreurs http 500. Cela signifie que le serveur backend est en panne.

4. Staticisation des pages front-end

Statisisez certaines pages et données qui ne changent pas fréquemment, et gzippez-les. Une autre méthode perverse consiste à placer ces pages statiques sous /dev/shm. Ce répertoire est la mémoire. Lire les fichiers directement depuis la mémoire et les renvoyer. Cela peut réduire les E/S coûteuses sur le disque. L'utilisation de la fonction sendfile de nginx peut permettre à ces fichiers statiques d'être échangés directement dans le noyau, ce qui peut augmenter considérablement les performances.

5. Optimiser les requêtes

De nombreuses personnes effectuent la même requête, et vous pouvez utiliser un proxy inverse pour fusionner ces requêtes simultanées et identiques. Cette technologie est principalement mise en œuvre par la mise en cache des résultats des requêtes. La première requête va dans la base de données pour obtenir les données et place les données dans le cache. Toutes les requêtes suivantes accèdent directement au cache. Hachez chaque requête et utilisez la technologie NoSQL pour compléter cette optimisation. (Cette technologie peut également être utilisée pour les pages statiques)

Pour la requête de quantité de billet de train, je pense personnellement qu'au lieu d'afficher des chiffres, il suffit d'afficher "oui" ou "non", ce qui peut grandement simplifier le système. complexité et améliorer les performances. Déchargez la charge de requêtes sur la base de données afin que celle-ci puisse mieux servir les personnes qui passent des commandes.

6. Problèmes de mise en cache

Le cache peut être utilisé pour mettre en cache des pages dynamiques, et il peut également être utilisé pour mettre en cache les données de requête. La mise en cache présente généralement plusieurs problèmes :

1) Mise à jour du cache. Également appelée synchronisation du cache et de la base de données. Il existe plusieurs méthodes. L'une consiste à expirer le cache, à l'invalider et à vérifier à nouveau. L'autre consiste à notifier le backend des mises à jour. Une fois le backend modifié, notifiez le frontend des mises à jour. Le premier est relativement simple à mettre en œuvre, mais ses performances en temps réel ne sont pas élevées. Le second est plus complexe à mettre en œuvre, mais ses performances en temps réel sont élevées.

2) Pagination en cache. La mémoire peut ne pas être suffisante, donc certaines données inactives doivent être extraites de la mémoire. Ceci est très similaire à la pagination et à l'échange de mémoire du système d'exploitation. FIFO, LRU et LFU sont tous des algorithmes de pagination relativement classiques. Pour du contenu connexe, consultez l’algorithme de mise en cache de Wikipeida.

3) Reconstruction et persistance du cache. Le cache est en mémoire et le système doit toujours être maintenu. Par conséquent, si le cache disparaît, il doit être reconstruit. Si la quantité de données est importante, le processus de reconstruction du cache sera très long. lent, ce qui affectera l'environnement de production. Par conséquent, la persistance de la chimisation du cache doit également être prise en compte.

De nombreux systèmes NoSQL puissants prennent en charge les trois problèmes majeurs de mise en cache ci-dessus.

Technologie d'optimisation des performances back-end

Nous avons déjà discuté de la technologie d'optimisation des performances front-end, donc le front-end n'est peut-être pas un problème de goulot d'étranglement. Ensuite, le problème de performances concernera les données back-end. Voici quelques techniques courantes d’optimisation des performances back-end.

1. Redondance des données

Concernant la redondance des données, c'est-à-dire que nous devons traiter la redondance des données de notre base de données, ce qui signifie réduire la surcharge de fonctionnement des connexions des tables, mais cela sacrifiera la cohérence des données. Le risque est relativement élevé. De nombreuses personnes utilisent NoSQL pour les données. C'est plus rapide car les données sont redondantes, mais cela présente un risque important pour la cohérence des données. Ceci doit être analysé et traité selon les différents métiers. (Remarque : Il est facile de transplanter une base de données relationnelle vers NoSQL, mais il est difficile de passer de NoSQL à une base de données relationnelle à l'envers)

2. Mise en miroir des données

Presque toutes les bases de données grand public prennent en charge la mise en miroir, c'est-à-dire la réplication. L’avantage de la mise en miroir de bases de données est qu’elle peut être utilisée pour l’équilibrage de charge. Répartissez uniformément la charge d'une base de données sur plusieurs plateformes tout en garantissant la cohérence des données (SCN d'Oracle). Le plus important est que cela permet également d’assurer une haute disponibilité. Si une machine tombe en panne, l’autre sera toujours en service.

La cohérence des données de la mise en miroir des données peut être un problème complexe, nous devons donc partitionner les données sur une seule donnée, c'est-à-dire répartir uniformément l'inventaire d'un produit le plus vendu sur différents serveurs, tels que a Les produits les plus vendus disposent de 10 000 stocks. Nous pouvons mettre en place 10 serveurs de 1 000 stocks chacun, à la manière d'un entrepôt B2C.

3. Partitionnement des données

Un problème que la mise en miroir des données ne peut pas résoudre est qu'il y a trop d'enregistrements dans la table de données, ce qui rend le fonctionnement de la base de données trop lent. Alors, partitionnez les données. Il existe de nombreuses façons de partitionner les données. De manière générale, elles sont les suivantes :

1) Classer les données selon une certaine logique. Par exemple, le système de réservation de billets de train peut être divisé selon chaque bureau ferroviaire, selon différents modèles, selon la gare d'origine et selon la destination... Quoi qu'il en soit, il s'agit de diviser un tableau en plusieurs feuilles avec le même Les champs sont différents types de tables, ces tables peuvent donc exister sur différentes machines pour partager la charge.

2) Divisez les données par champs, c'est-à-dire divisez les tableaux verticalement. Par exemple, placez certaines données qui ne changent pas fréquemment dans une table et placez les données fréquemment modifiées dans plusieurs autres tables. Transformez une table en une relation 1 à 1. De cette façon, vous pouvez réduire le nombre de champs dans la table et également améliorer les performances dans une certaine mesure. De plus, le fait d'avoir de nombreux champs entraînera le stockage d'un enregistrement dans des tables de pages différentes, ce qui pose des problèmes de performances de lecture et d'écriture. Mais il y a ensuite de nombreux contrôles compliqués.

3) Tableau des scores moyens. Étant donné que la première méthode n’est pas nécessairement divisée de manière égale, il peut tout de même y avoir un grand nombre de données d’un certain type. Par conséquent, il existe également une méthode de distribution moyenne pour diviser les tables en fonction de la plage d'ID de clé primaire.

4) La même partition de données. Cela a été mentionné dans la mise en miroir des données ci-dessus. C'est-à-dire que la valeur d'inventaire d'un même produit est allouée à différents serveurs. Par exemple, s'il y a 10 000 inventaires, ils peuvent être alloués à 10 serveurs, et un serveur a 1 000 inventaires. Puis équilibrez la charge.

Les trois types de cloisons ont leurs avantages et leurs inconvénients. Le plus couramment utilisé est le premier. Une fois les données partitionnées, vous devez disposer d'un ou plusieurs planificateurs pour indiquer à votre programme frontal où trouver les données. Le cloisonnement des données des billets de train et leur placement dans diverses provinces et villes entraîneront une amélioration très significative et qualitative des performances du système 12306.

4. Équilibrage de la charge du système back-end

Comme mentionné précédemment, le partitionnement des données peut réduire la charge dans une certaine mesure, mais il ne peut pas réduire la charge des hot- vente de produits. Pour les billets de train, cela peut être considéré comme des billets sur certaines lignes principales des grandes villes. Cela nécessite l'utilisation de la mise en miroir des données pour réduire la charge. En utilisant la mise en miroir des données, vous devez utiliser l'équilibrage de charge. Sur le backend, il peut être difficile pour nous d'utiliser un équilibreur de charge comme un routeur, car il s'agit d'équilibrer le trafic, car le trafic ne représente pas l'activité du serveur. Par conséquent, nous avons besoin d’un système de répartition des tâches capable également de surveiller la charge de chaque serveur.

Le serveur de distribution des tâches rencontre quelques difficultés :

• La situation de charge est plus complexe. Qu'est-ce qui est occupé ? Le processeur est-il élevé ? Ou les E/S du disque sont-elles élevées ? Ou l'utilisation de la mémoire est-elle élevée ? Ou la concurrence est-elle élevée ? Ou le taux de pagination de la mémoire est-il élevé ? Vous devrez peut-être tous les considérer. Ces informations sont envoyées à l'allocateur de tâches, et celui-ci sélectionne le serveur ayant la charge la plus légère pour le traitement.

• Le serveur de distribution de tâches doit mettre la tâche en file d'attente et ne peut pas la perdre, elle doit donc également être conservée. Et les tâches peuvent être assignées aux serveurs informatiques par lots.

• Que dois-je faire si le serveur de distribution de tâches tombe en panne ? Certaines technologies à haute disponibilité telles que Live-Standby ou Failover sont ici requises. Nous devons également faire attention à la manière dont les files d'attente de tâches persistantes sont transférées vers d'autres serveurs.

J'ai vu que de nombreux systèmes utilisent une méthode statique pour allouer, certains utilisent le hachage et d'autres analysent simplement à tour de rôle. Celles-ci ne sont pas suffisantes. La première est qu'elle ne peut pas équilibrer parfaitement la charge. L'autre défaut fatal de la méthode statique est que si un serveur informatique tombe en panne ou si nous devons ajouter un nouveau serveur, notre allocateur doit l'avoir. De plus, le hachage doit être recalculé (un hachage cohérent peut résoudre en partie ce problème).

Une autre méthode consiste à utiliser une méthode préemptive pour l'équilibrage de charge, où le serveur informatique en aval se rend au serveur de tâches pour obtenir des tâches. Laissez ces serveurs informatiques décider s’ils veulent des tâches. L'avantage est que cela peut simplifier la complexité du système, et cela peut également réduire ou augmenter les serveurs informatiques en temps réel. Mais le seul inconvénient est que cela peut introduire une certaine complexité si certaines tâches ne peuvent être traitées que sur un certain serveur. Mais dans l’ensemble, cette méthode peut constituer un meilleur équilibrage de charge.

5. Traitement asynchrone, accéléré et par lots

Le traitement asynchrone, accéléré et par lots nécessite tous un traitement en file d'attente du nombre de requêtes simultanées.

• Asynchrone en entreprise signifie généralement collecter les demandes puis retarder leur traitement. Techniquement, chaque programme de traitement peut être rendu parallèle et étendu horizontalement. Cependant, les problèmes techniques de l'asynchrone sont probablement les suivants : a) Le résultat renvoyé par l'appelé impliquera des problèmes de communication entre les threads du processus. b) Si le programme doit être restauré, la restauration sera un peu compliquée. c) L'asynchrone s'accompagne généralement de multi-threading et de multi-processus, et le contrôle de la concurrence est relativement gênant. d) De nombreux systèmes asynchrones utilisent des mécanismes de messages, et la perte et le désordre des messages peuvent également constituer des problèmes complexes.

• La technologie Throttle n'améliore pas réellement les performances. Cette technologie empêche principalement le système d'être submergé par un trafic qui dépasse sa capacité à gérer. . De manière générale, l'utilisation de la technologie Throttle est destinée aux systèmes que vous ne pouvez pas contrôler, comme le système bancaire connecté à votre site Web.

• La technologie de traitement par lots consiste à traiter par lots un ensemble de demandes essentiellement identiques. Par exemple, si tout le monde achète le même produit en même temps, vous n'avez pas besoin d'en acheter un et j'écrirai dans la base de données une fois. Un certain nombre de demandes peuvent être collectées et traitées en une seule fois. Cette technique peut être utilisée de plusieurs manières. Par exemple, pour économiser la bande passante du réseau, nous savons tous que la MTU (unité de transmission maximale) sur le réseau est de 1 500 octets pour Ethernet et de plus de 4 000 octets pour la fibre optique. Si l'un de vos paquets réseau ne remplit pas cette MTU, c'est le cas. Il s'agit d'un gaspillage de bande passante réseau, car le pilote de la carte réseau ne peut lire efficacement que bloc par bloc. Par conséquent, lors de l'envoi de paquets sur le réseau, nous devons collecter suffisamment d'informations avant d'effectuer des E/S réseau. Il s'agit également d'une méthode de traitement par lots. L'ennemi du traitement par lots est le faible trafic. Par conséquent, les systèmes de traitement par lots fixent généralement deux seuils, l'un est le volume de travail et l'autre est le délai d'attente. Tant qu'une condition est remplie, le traitement de la soumission commence.

Donc, tant qu'il est asynchrone, il y aura généralement un mécanisme d'accélérateur, et il y aura généralement une file d'attente pour faire la queue. S'il y a une file d'attente, il y aura de la persistance, et le. le système utilisera généralement le traitement par lots.

Le « système de file d'attente » conçu par Yunfeng est cette technologie. Ceci est très similaire au système de commande du commerce électronique. C'est-à-dire que mon système a reçu votre demande de commande de ticket, mais je ne l'ai pas encore traitée. Mon système limitera ces grands nombres en fonction de mes propres capacités de traitement. Les demandes sont faites et traitées petit à petit. Une fois le traitement terminé, je peux envoyer un e-mail ou un SMS pour informer l'utilisateur que vous pouvez réellement acheter des billets.

Ici, je voudrais discuter du système de file d'attente de Yunfeng du point de vue des besoins de l'entreprise et des utilisateurs, car il semble résoudre ce problème techniquement, mais il peut encore y avoir des problèmes en termes de besoins de l'entreprise et des utilisateurs. des choses qui méritent une réflexion approfondie :

1) Attaque DoS en file d'attente. Tout d’abord, réfléchissons-y : cette équipe est-elle simplement une file d’attente ? Ce n'est pas suffisant, car nous ne pouvons pas éliminer les scalpers, et le simple ticket_id est sujet aux attaques DoS. Par exemple, si je lance N ticket_id et que j'entre dans le processus d'achat de billet, si je ne l'achète pas, cela vous coûtera la moitié. Il est facile pour moi de rendre impossible aux personnes qui souhaitent acheter des billets d'acheter des billets pendant plusieurs jours. Certains disent que les utilisateurs devraient utiliser leur carte d'identité pour faire la queue, de sorte qu'ils doivent utiliser cette carte d'identité pour effectuer des achats, mais cela ne peut toujours pas éliminer les files d'attente de steaks ou les revendeurs de comptes. Parce qu’ils peuvent enregistrer N comptes pour faire la queue, mais ils n’achètent tout simplement pas. Les scalpers n'ont qu'une seule chose à faire pour le moment, c'est-à-dire rendre le site Web inaccessible aux personnes normales, afin que les utilisateurs ne puissent acheter que par leur intermédiaire.

2) Cohérence des colonnes ? Les opérations sur cette file d’attente nécessitent-elles des verrous ? Tant qu'il y aura un verrou, les performances ne s'amélioreront pas. Imaginez, 1 million de personnes vous demandent d'attribuer des numéros d'emplacement en même temps. Cette file d'attente deviendra un goulot d'étranglement en termes de performances. Vous ne devez pas avoir de bonnes performances de base de données, donc cela peut être pire qu'aujourd'hui. Voler la base de données et récupérer la file d'attente sont essentiellement les mêmes.

3) Temps d'attente dans la file d'attente. Une demi-heure suffit-elle pour acheter un billet ? Est-ce trop ? Que se passe-t-il si l'utilisateur ne peut pas accéder à Internet à ce moment-là ? Si le temps est court, les utilisateurs se plaindront s’ils n’ont pas assez de temps pour opérer. Si le temps est long, les personnes qui font la queue se plaindront également. Cette méthode peut poser de nombreux problèmes en pratique. De plus, une demi-heure, c'est trop long, ce qui est totalement irréaliste. Prenons 15 minutes comme exemple : il y a 10 millions d'utilisateurs, et seulement 10 000 peuvent être mis en place à tout moment. Ces 10 000 utilisateurs ont besoin de 15 minutes pour réaliser toutes les opérations. Ensuite, pour traiter tous ces 10 millions d'utilisateurs, il faudra 1000*15m = 250 heures, 10 jours et demi, et le train est parti tôt. (Je ne dis pas que des bêtises. Selon l'explication des experts du ministère des Chemins de fer : Au cours des derniers jours, en moyenne 1 million de commandes ont été passées par jour, il faut donc dix jours pour traiter 10 millions d'utilisateurs. Ceci le calcul est peut-être un peu simple. Je veux juste dire : Dans un système à charge aussi faible, la file d'attente peut ne pas être en mesure de résoudre les problèmes commerciaux)

4) Distribution de files d'attente. Ce système de file d'attente n'est-il qu'une seule file d'attente ? Pas assez bien. Parce que si les personnes que vous insérez et qui peuvent acheter des billets achètent le même type de billets pour le même train (comme une couchette dans un train), elles récupèrent toujours les billets, ce qui signifie que la charge du système peut encore être concentrés parmi eux sur un certain serveur. Par conséquent, le meilleur moyen consiste à mettre les utilisateurs en file d’attente en fonction de leurs besoins, en indiquant l’origine et la destination. De cette façon, il peut y avoir plusieurs files d'attente. Tant qu'il y a plusieurs files d'attente, elles peuvent être étendues horizontalement. Cela peut résoudre le problème de performances, mais cela ne résout pas le problème des utilisateurs faisant la queue pendant une longue période.

Je pense que nous pouvons certainement apprendre des achats en ligne. Lorsque vous faites la queue (passez une commande), collectez les informations de l'utilisateur et les billets qu'il souhaite acheter, et permettez à l'utilisateur de définir la priorité d'achat des billets. Par exemple, si vous ne pouvez pas acheter de couchette dans le train A, achetez-en une. couchette dans le train B. Si vous ne pouvez toujours pas l'acheter, vous pouvez acheter une couchette dans le train B. Achetez simplement un siège rigide, etc., puis l'utilisateur recharge d'abord l'argent requis, puis le système traite le commandez de manière entièrement automatique et asynchrone. L'utilisateur sera informé par SMS ou par e-mail du succès ou de l'échec de l'opération. De cette façon, le système peut non seulement économiser une demi-heure de temps d'interaction avec l'utilisateur et accélérer automatiquement le traitement, mais peut également fusionner des personnes ayant la même demande d'achat de billets pour un traitement par lots (réduire le nombre d'opérations de base de données). La meilleure chose à propos de cette méthode est qu'elle peut connaître les besoins de ces utilisateurs en file d'attente. Non seulement elle peut optimiser la file d'attente de l'utilisateur et répartir les utilisateurs dans différentes files d'attente, mais elle peut également permettre au ministère des Chemins de fer d'établir des horaires de train comme la liste de souhaits d'Amazon via certains. calculs. Coordonner les arrangements et les ajustements (enfin, le système de file d'attente (système de commande) doit toujours être stocké dans la base de données ou conservé, pas seulement dans la mémoire, sinon vous serez grondé lorsque la machine tombe en panne).

Résumé

J'ai tellement écrit, permettez-moi de le résumer :

0) Peu importe la façon dont vous le concevez, votre système doit être facile à étendre horizontalement . En d’autres termes, tous les liens de l’ensemble de votre flux de données doivent pouvoir s’étendre horizontalement. De cette façon, lorsque votre système rencontre des problèmes de performances, "ajouter 30 fois plus de serveurs" ne sera pas ridicule.

1) La technologie mentionnée ci-dessus ne peut pas être réalisée du jour au lendemain sans accumulation à long terme, elle est fondamentalement désespérée. Nous pouvons voir que quel que soit celui que vous utilisez, il introduira une certaine complexité et la conception est toujours un compromis.

2) Les ventes centralisées de billets sont difficiles à gérer. L'utilisation de la technologie ci-dessus peut améliorer les performances du système de réservation de billets des centaines de fois. Construire des sous-stations dans diverses provinces et villes et vendre les billets séparément est le meilleur moyen d'améliorer qualitativement les performances du système existant.

3) Le modèle économique consistant à récupérer des billets à la veille des voyages de la Fête du Printemps et l'offre de billets est bien inférieure à la demande, ce qui est tout à fait anormal. Il permet à des dizaines de millions, voire des centaines de millions de personnes de se connecter. arriver en même temps à 8 heures du matin pour récupérer les billets en même temps. Ce modèle économique est une perversion des perversions. L'anomalie de leur forme commerciale détermine que quoi qu'ils fassent, ils seront certainement réprimandés.

4) C'est dommage de construire un système aussi vaste en seulement une ou deux semaines et de passer le reste du temps à ne rien faire. C'est quelque chose que seuls les chemins de fer peuvent faire.