Plus de 6 000 mots | Points à noter lors de la conception du système Flash Kill

Cinq principes architecturaux

Les données doivent être aussi petites que possible

Tout d'abord, cela signifie que les données demandées par l'utilisateur doivent être aussi petites que possible. Les données demandées comprennent les données téléchargées sur le système et les données renvoyées par le système à l'utilisateur (généralement une page Web).

Le nombre de requêtes doit être aussi réduit que possible

Une fois la page demandée par l'utilisateur renvoyée, le navigateur inclura d'autres requêtes supplémentaires lors du rendu de la page, par exemple, le CSS/JavaScript, les images et Ajax. requêtes dont dépend cette page Définies comme des « requêtes supplémentaires », ces requêtes supplémentaires doivent être réduites au minimum.

Le chemin doit être le plus court possible

C'est le nombre de nœuds intermédiaires par lesquels l'utilisateur doit passer dans le processus depuis la demande jusqu'au retour des données.

Les dépendances doivent être aussi peu nombreuses que possible

fait référence au système ou au service sur lequel on doit s'appuyer pour répondre à une demande d'utilisateur. Les dépendances font ici référence à de fortes dépendances.

Haute disponibilité

Un point unique dans le système peut être considéré comme un tabou dans l'architecture système, car un seul point signifie aucune sauvegarde et des risques incontrôlables. Le principe le plus important dans la conception de systèmes distribués est « d'éliminer les points uniques ». , un autre nom est « haute disponibilité ».

L'architecture est un art de l'équilibre, et une fois que la meilleure architecture est séparée de la scène à laquelle elle s'adapte, tout ne sera plus qu'un discours vide de sens. Ce que nous devons retenir, c’est que les points mentionnés ici ne sont que des orientations. Nous devons faire de notre mieux pour travailler dans ces directions, mais nous devons également envisager d’équilibrer d’autres facteurs.

Comment faire une séparation dynamique et statique

Qu'est-ce que les données dynamiques et statiques

Alors, qu'est-ce que la séparation dynamique et statique exactement ? La soi-disant « séparation dynamique et statique » consiste en fait à diviser les données demandées par les utilisateurs (telles que les pages HTML) en « données dynamiques » et « données statiques ». En termes simples, la principale différence entre les « données dynamiques » et les « données statiques » est de voir si les données affichées dans la page sont liées à l'URL, au navigateur, à l'heure, à la région et si elles contiennent des données privées telles que des cookies.

1. Pour de nombreux sites Web médiatiques, le contenu d'un certain article est le même, que vous le visitiez ou que je le visite. Il s'agit donc de données statiques typiques, mais c'est une page dynamique.
2. Si nous visitons la page d'accueil de Taobao maintenant, tout le monde peut voir une page différente. La page d'accueil de Taobao contient de nombreuses informations recommandées en fonction des caractéristiques des visiteurs, et ces données personnalisées peuvent être comprises comme des données dynamiques.

Comment mettre en cache des données statiques ?

Tout d'abord, vous devez mettre en cache les données statiques les plus proches de l'utilisateur. Les données statiques sont des données relativement inchangées, nous pouvons donc les mettre en cache. Où est-il mis en cache ? Il en existe trois courants : dans le navigateur de l'utilisateur, sur le CDN ou dans le Cache du serveur. Vous devez les mettre en cache le plus près possible de l'utilisateur en fonction de la situation.

Deuxièmement, la transformation statique consiste à mettre directement en cache les connexions HTTP. Par rapport à la mise en cache de données ordinaire, vous devez avoir entendu parler de transformation statique du système. La transformation statique met directement en cache la connexion HTTP au lieu de simplement mettre les données en cache. Comme le montre la figure ci-dessous, le serveur proxy Web extrait directement l'en-tête de réponse HTTP et le corps de la réponse correspondants en fonction de l'URL de la demande et les renvoie directement par ce processus de réponse. est si simple qu'il n'utilise même pas le protocole HTTP réassemblé, même les en-têtes de requête HTTP n'ont pas besoin d'être analysés.

Troisièmement, qui met en cache les données statiques est également important. Les logiciels de cache écrits dans différentes langues ont des efficacités différentes dans le traitement des données mises en cache. Prenons Java comme exemple, car le système Java lui-même a aussi ses faiblesses (par exemple, il n'est pas efficace pour gérer un grand nombre de demandes de connexion, chaque connexion consomme plus de mémoire et le conteneur Servlet est lent à analyser le protocole HTTP) , vous ne pouvez donc pas effectuer de mise en cache au niveau de la couche Java, mais faites-le directement sur la couche du serveur Web, afin de pouvoir protéger certaines faiblesses au niveau du langage Java. En comparaison, les serveurs Web (tels que Nginx, Apache, Varnish) le sont ; également mieux à gérer les demandes de fichiers statiques simultanées volumineuses.

Comment rendre la transformation de la séparation dynamique et statique

1. URL unique
2. Facteurs séparés liés au navigateur
3. Facteurs temporels séparés
4. Facteurs régionaux asynchrones
5. Re déplacer le cookie C

Plusieurs solutions architecturales pour une séparation dynamique et statique

Selon la complexité de l'architecture, 3 options sont possibles :

Déploiement sur une seule machine :

Couche de cache unifiée :

plus CDN Layer :

La solution de déploiement CDN présente également les fonctionnalités suivantes :

1. Mettez en cache la page entière dans le navigateur de l'utilisateur ;
2. Si la page entière est forcée d'être actualisée, le CDN sera également demandé
3. La demande effective réelle est simplement le clic de l'utilisateur sur le "Trésor Actualiser" ; " bouton.

Comment gérer les données des hotspots dans le système de vente flash ?

Qu'est-ce qu'un "hotspot"

Les hotspots sont divisés en opérations de hotspot et en données de hotspot.

Les opérations dites "à chaud", comme un grand nombre de rafraîchissements de pages, un grand nombre d'ajouts de paniers, un grand nombre de commandes passées à 0h00 sur Double Eleven, etc., entrent toutes dans cette catégorie. . Pour le système, ces opérations peuvent être résumées en « requêtes de lecture » et « requêtes d'écriture ». Ces deux requêtes de hotspot sont traitées de manières très différentes. L'espace d'optimisation pour les requêtes de lecture est plus grand, tandis que le goulot d'étranglement pour les requêtes d'écriture est généralement dans le domaine. couche de stockage. L'idée de l'optimisation est d'équilibrer sur la base de la théorie CAP. Je présenterai ce contenu en détail dans l'article "Réduire les stocks".

Les « données de hotspot » sont plus faciles à comprendre, c'est-à-dire les données correspondant à la demande de hotspot de l'utilisateur. Les données de points d'accès sont divisées en « données de points d'accès statiques » et « données de points d'accès dynamiques ».

Les « données de points d'accès statiques » font référence à des données de points d'accès qui peuvent être prédites à l'avance. Par exemple, nous pouvons filtrer les vendeurs à l'avance grâce à l'enregistrement et marquer ces produits phares via le système d'enregistrement. En outre, nous pouvons également utiliser l'analyse du Big Data pour découvrir à l'avance les produits phares. Par exemple, nous analysons les enregistrements de transactions historiques et les enregistrements de panier d'achat des utilisateurs pour découvrir quels produits peuvent être les plus populaires et les mieux vendus. être analysés au préalable.

Les « données de points chauds dynamiques » font référence à des points chauds qui ne peuvent pas être prédits à l'avance et qui sont temporairement générés pendant le fonctionnement du système. Par exemple, un vendeur fait de la publicité sur Douyin, puis le produit devient immédiatement populaire, ce qui entraîne son achat en grande quantité sur une courte période de temps.

Étant donné que les opérations de hotspot sont des comportements d'utilisateurs, nous ne pouvons pas les modifier, mais nous pouvons mettre en place certaines restrictions et protections. Par conséquent, dans cet article, je présenterai principalement comment optimiser les données de hotspot.

Découvrez les données de points d'accès

1. Découvrez les données de points d'accès statiques
2. Découvrez les données de points d'accès dynamiques

Traitez les données de points d'accès

Optimisation

Le moyen le plus efficace d'optimiser les données des points d'accès est de mettre en cache données de point d'accès , si les données de point d'accès sont séparées des données statiques, les données statiques peuvent être mises en cache pendant une longue période. Cependant, la mise en cache des données de hotspot est davantage un cache « temporaire », c'est-à-dire qu'il s'agit de données statiques ou de données dynamiques, elles sont brièvement mises en cache dans une file d'attente pendant quelques secondes. La longueur de la file d'attente étant limitée, elle peut être remplacée par. l'algorithme d'élimination LRU.

Restrictions

La restriction est davantage un mécanisme de protection, et il existe de nombreuses façons de la restreindre. Par exemple, effectuez un hachage cohérent sur l'ID du produit accédé, puis regroupez-le en fonction du hachage. afin que les produits chauds puissent être limités à une file d'attente de requêtes pour éviter que certains produits chauds ne consomment trop de ressources du serveur et que d'autres demandes ne reçoivent jamais de ressources de traitement du serveur.

Isolement

Le premier principe de la conception d'un système de vente flash est d'isoler ce type de données chaudes. Ne laissez pas 1% des demandes affecter les 99% restants. Après l'isolement, il sera plus pratique de gérer les. 1% des demandes. Optimisation ciblée. L'isolation peut être divisée en : isolation de l'entreprise, isolation du système et isolation des données.

Comment réduire les pointes de circulation

Tout comme les routes de la ville, en raison des problèmes de pointe du matin et de pointe du soir, il existe une solution de déplacement des pointes et de restriction de circulation.

L'existence d'écrêtage de pointe peut, d'une part, rendre le traitement du serveur plus stable, et d'autre part, elle peut économiser le coût des ressources du serveur.

Pour le scénario de vente flash, le Peak Clipping consiste essentiellement à retarder davantage l'émission des demandes des utilisateurs afin de réduire et de filtrer certaines demandes invalides. Il suit le principe selon lequel « le nombre de demandes doit être aussi petit que possible ».

Idées de réduction des pics de trafic

File d'attente

Pour atteindre les pics de trafic, la solution la plus simple à laquelle penser est d'utiliser des files d'attente de messages pour tamponner le trafic instantané, convertir les appels directs synchrones en push indirects asynchrones et transmettre une file d'attente qui gère le trafic instantané. atteint un sommet à une extrémité et diffuse les messages en douceur à l'autre extrémité.

En plus des files d'attente de messages, il existe de nombreuses méthodes de mise en file d'attente similaires, telles que :

• L'utilisation du pool de threads pour verrouiller et attendre est également une méthode de mise en file d'attente courante
• Méthodes de mise en file d'attente mémoire couramment utilisées telles que first- ; in-first-out et first-in-last-out La méthode d'implémentation de l'algorithme ;
• sérialise la requête dans un fichier, puis lit séquentiellement le fichier (comme le mécanisme de synchronisation basé sur le binlog MySQL) pour restaurer la demande, etc.

On peut voir que ces méthodes ont une caractéristique commune, qui est de transformer « l'opération en une étape » en une « opération en deux étapes », dans laquelle l'opération en une étape ajoutée est utilisée pour agir comme un tampon.

"Inventaire" logique de base de réduction"

C'est très important, toutes les autres étapes sont auxiliaires. S'il y a 100 pièces en stock, vendez simplement 100 pièces et réduisez-les à 0 dans la base de données. Quel est le problème ? Oui, c'est le cas en théorie, mais dans des scénarios commerciaux spécifiques, « réduire les stocks » n'est pas si simple.

• Quels sont les moyens de réduire les stocks
Cliquez sur le bouton « Acheter maintenant » sur la page du produit, vérifiez les informations et cliquez sur « Soumettre la commande ». Cette étape est appelée passer une commande. Après avoir passé une commande, vous ne pouvez véritablement acheter qu'une fois l'opération de paiement terminée, comme le dit le dicton : « La sécurité dans la poche ».
• Les opérations de réduction de stocks ont généralement les modalités suivantes :

  Réduction des stocks après avoir passé une commande

  C'est-à-dire qu'une fois que l'acheteur a passé une commande, la quantité achetée par l'acheteur sera soustraite de l'inventaire total du produit. Passer une commande pour réduire les stocks est le moyen le plus simple de réduire les stocks, mais c'est aussi la méthode de contrôle la plus précise. Lors de la passation d'une commande, l'inventaire des marchandises est directement contrôlé par le mécanisme de transaction de la base de données, de sorte que les conditions de survente soient prises en compte. ne se produit pas. Mais il faut savoir que certaines personnes peuvent ne pas payer après avoir passé une commande.

  Réduction de l'inventaire après paiement

  C'est-à-dire qu'une fois que l'acheteur a passé la commande, l'inventaire n'est pas réduit immédiatement, mais l'inventaire est en fait réduit jusqu'à ce qu'un utilisateur paie, sinon l'inventaire sera réservé à d'autres acheteurs. Toutefois, étant donné que les stocks ne sont réduits qu'après le paiement, si la concurrence est relativement élevée, il peut arriver que l'acheteur ne puisse pas payer après avoir passé la commande, car les marchandises peuvent avoir été achetées par d'autres.

  Retenue d'inventaire

  Cette méthode est relativement compliquée. Une fois que l'acheteur a passé une commande, l'inventaire est réservé pendant une certaine période (par exemple 10 minutes). Passé ce délai, l'inventaire sera automatiquement remis à d'autres. acheteurs après la sortie. Vous pouvez continuer à acheter. Avant que l'acheteur ne paie, le système vérifiera si l'inventaire de la commande est toujours réservé : s'il n'y a pas de réservation, la retenue sera retentée si l'inventaire est insuffisant (c'est-à-dire que la retenue échoue), le paiement ne sera pas effectué ; être autorisé à continuer si la retenue réussit, Le paiement est alors effectué et l'inventaire est effectivement déduit.

  Par où devrions-nous commencer avec la construction à haute disponibilité

  En parlant de construction à haute disponibilité du système, il s'agit en fait d'un projet de système qui doit prendre en compte toutes les étapes de la construction du système, ce qui signifie qu'il passe par tout le cycle de vie de la construction du système, comme le montre l'image ci-dessous :

  

  .

  Phase d'architecture

  La phase d'architecture prend principalement en compte l'évolutivité et la tolérance aux pannes du système, et évite les problèmes ponctuels dans le système. Par exemple, dans le déploiement unitaire de plusieurs salles informatiques, même si une certaine salle informatique dans une certaine ville souffre d'une panne globale, cela n'affectera toujours pas le fonctionnement de l'ensemble du site Web.

  Phase de codage

  La chose la plus importante dans le codage est de garantir la robustesse du code. Par exemple, lorsqu'il s'agit de problèmes d'appels à distance, un mécanisme de sortie de délai d'attente raisonnable doit être mis en place pour éviter d'être entraîné par d'autres. systèmes, et l'ensemble de résultats renvoyé par l'appel doit également être garanti. Afin d'éviter que les résultats renvoyés ne dépassent la plage de traitement du programme, la méthode la plus courante consiste à capturer les exceptions d'erreur et à avoir des résultats de traitement par défaut pour les erreurs imprévues.

  Phase de test

  Les tests visent principalement à assurer la couverture des cas de test et à garantir que lorsque le pire des cas se produit, nous disposons également de procédures de traitement correspondantes.

  Phase de publication

  Il y a également certaines choses auxquelles il faut prêter attention lors de la publication, car des erreurs sont plus susceptibles de se produire pendant la publication, un mécanisme de restauration d'urgence doit donc être en place.

  Phase de fonctionnement

  Le temps de fonctionnement est l'état normal du système. Le système sera en état de fonctionnement la plupart du temps. La chose la plus importante dans l'état de fonctionnement est que la surveillance du système doit être précise et. en temps opportun. Si des problèmes sont détectés, l'alarme doit être précise et les données d'alarme doivent être précises et détaillées pour faciliter le dépannage.

  Un défaut se produit

  Lorsqu'un défaut se produit, la première et la plus importante chose est d'arrêter la perte de temps. Par exemple, si le prix du produit est erroné en raison d'un problème de programme, le produit doit être retiré des rayons. ou le lien d'achat doit être fermé à temps pour éviter des pertes d'actifs importantes. Ensuite, il est nécessaire de pouvoir restaurer les services en temps opportun, localiser la cause et résoudre le problème.

  Comment devrions-nous maximiser le fonctionnement normal de notre système lorsque nous sommes confrontés à un trafic intense ?

  Downgrade

  Le soi-disant « downgrade » signifie que lorsque la capacité du système atteint un certain niveau, certaines fonctions non essentielles du système sont restreintes ou arrêtées, réservant ainsi des ressources limitées à des activités plus essentielles. Il s’agit d’un processus d’exécution ciblé et planifié, donc pour un déclassement, nous avons généralement besoin d’un ensemble de plans pour coordonner l’exécution. Si nous le systématisons, nous pouvons parvenir à une dégradation grâce à un système de planification et un système de commutation.

  

  Limitation de courant

  La limitation de courant signifie que lorsque la capacité du système atteint le goulot d'étranglement, nous devons protéger le système en limitant une partie du trafic, et pouvons non seulement effectuer une commutation manuelle, mais également prendre en charge une protection automatisée mesures.

  Avantages et inconvénients de la limitation de courant côté client et de la limitation de courant côté serveur :

  La limitation de courant côté client a l'avantage de limiter l'émission de requêtes et de réduire la consommation du système en réduisant l'émission de requêtes inutiles. L'inconvénient est que lorsque les clients sont dispersés, il est impossible de définir un seuil de limitation de courant raisonnable : si le seuil est trop petit, le client sera restreint avant que le serveur n'atteigne le goulot d'étranglement ; s'il est trop grand, il ne le sera pas ; être capable de Le rôle des restrictions.

  L'avantage de la limitation de courant côté serveur est qu'un seuil raisonnable peut être défini en fonction des performances du serveur. L'inconvénient est que les requêtes restreintes sont des requêtes invalides et que le traitement lui-même de ces requêtes invalides consommera également des ressources du serveur.

  

  Algorithme de limitation de courant commun

  Algorithme de compteur (fenêtre fixe)

  L'algorithme de compteur utilise un compteur pour accumuler le nombre de visites dans un cycle Lorsque la valeur limite de courant définie est atteinte, le courant. une stratégie de limitation est déclenchée. Au début du cycle suivant, il est effacé et recompté.

  Cet algorithme est très simple à implémenter dans un environnement autonome ou distribué. Il peut être facilement implémenté en utilisant l'auto-incrémentation atomique incr et la sécurité des threads de redis.

  Algorithme de fenêtre coulissante

  L'algorithme de fenêtre glissante divise la période de temps en N petites périodes, enregistre le nombre de visites dans chaque petite période et supprime les petites périodes expirées en fonction du glissement temporel. Cet algorithme peut bien résoudre le problème critique de l’algorithme à fenêtre fixe.

  Algorithme de compartiment qui fuit

  L'algorithme de compartiment qui fuit consiste à placer directement la demande d'accès dans le compartiment qui fuit lorsqu'elle arrive. Si la capacité actuelle a atteint la limite supérieure (valeur limite actuelle), elle sera rejetée (déclenchant le courant). politique de limite). Le compartiment qui fuit libère les demandes d'accès (c'est-à-dire que les demandes sont acceptées) à un rythme fixe jusqu'à ce que le compartiment qui fuit soit vide.

  Algorithme de seau de jetons

  L'algorithme de seau de jetons est que le programme ajoute des jetons au seau de jetons à un taux de r (r = période de temps/valeur limite actuelle) jusqu'à ce que le seau de jetons soit plein, et ajoute des jetons au jeton. bucket lorsque la demande arrive Jeton de demande de bucket, si le jeton est obtenu, la demande sera transmise, sinon la politique de limitation actuelle sera déclenchée

  Déni de service

  Si la limitation actuelle ne peut pas résoudre le problème, le dernier recours est pour refuser directement le service. Lorsque la charge du système atteint un certain seuil, par exemple, l'utilisation du processeur atteint 90 % ou la valeur de charge du système atteint 2*cœurs de processeur, le système rejette directement toutes les requêtes. Cette méthode est la méthode de protection du système la plus violente mais aussi la plus efficace. . Par exemple, pour le système de vente flash, nous concevons une protection contre les surcharges dans les aspects suivants :

  Définissez une protection contre les surcharges sur le front-end Nginx Lorsque la charge de la machine atteint une certaine valeur, la requête HTTP sera directement rejetée et une erreur 503. le code sera renvoyé. La même chose peut être faite au niveau de la couche Java. Conçu avec une protection contre les surcharges.

  Le déni de service peut être considéré comme une solution de dernier recours pour éviter que le pire des cas ne se produise et empêcher le serveur d'être complètement incapable de fournir des services pendant une longue période en raison d'une surcharge du serveur. Bien qu'une telle protection contre les surcharges du système ne puisse pas fournir de services en cas de surcharge, le système peut toujours fonctionner et peut facilement récupérer lorsque la charge chute. Par conséquent, chaque système et chaque liaison doivent configurer ce plan de sauvegarde pour préparer le système au pire des cas. sous protection.

  Problèmes de cache

  Avalanche de cache

  Les données ne sont pas chargées dans le cache, ou le cache échoue dans une grande zone en même temps, ce qui oblige toutes les requêtes à rechercher la base de données, provoquant la base de données, le processeur et surcharge de mémoire, voire temps d'arrêt.

  Un processus d'avalanche simple :

  1) Échec à grande échelle du cluster Redis ;

  2) Échec de la mise en cache, mais il y a encore un grand nombre de demandes d'accès au service de cache Redis ;

  3) Après un grand nombre de demandes ; des échecs de requêtes Redis, les requêtes sont détournées vers la base de données ;

  4) Les requêtes de base de données augmentent fortement, provoquant la destruction de la base de données

  5) Étant donné que la plupart de vos services d'application dépendent de la base de données et des services Redis, ce sera bientôt le cas ; provoquer une avalanche du cluster de serveurs, et finalement tout le système s'effondrera complètement.

  Solution :

  Au préalable  : Cache hautement disponible

  Le cache hautement disponible permet d'éviter toute défaillance du cache. Même si des nœuds individuels, des machines ou même des salles informatiques sont arrêtés, le système peut toujours fournir des services, et Redis Sentinel et Redis Cluster peuvent atteindre une haute disponibilité.

  En cours : Rétrogradation du cache (support temporaire)

  Comment pouvons-nous nous assurer que le service est toujours disponible lorsqu'une forte augmentation des visites entraîne des problèmes avec le service. Hystrix, largement utilisé en Chine, utilise trois méthodes : la fusion, le déclassement et la limitation de courant pour réduire les pertes après avalanches. Tant que la base de données n'est pas morte, le système peut toujours répondre aux demandes. N'est-ce pas ainsi que nous venons ici à chaque Fête du Printemps 12306 ? Tant que vous pouvez encore répondre, vous avez au moins une chance d’obtenir un ticket.

  Après l'événement : sauvegarde Redis et préchauffage rapide

  1) Sauvegarde et restauration des données Redis

  2) Préchauffage rapide du cache

  Panne du cache

  La panne du cache signifie que le stockage des données du point d'accès expire, plusieurs threads demandent des données de point d'accès en même temps. Étant donné que le cache vient d'expirer, toutes les requêtes simultanées seront envoyées à la base de données pour interroger les données.

  Solution :

  En fait, dans la plupart des scénarios commerciaux réels, la panne du cache se produit en temps réel, mais cela ne causera pas trop de pression sur la base de données, car dans les affaires générales d'une entreprise, le niveau de concurrence ne sera pas aussi important. haut . Bien sûr, si vous avez le malheur que cela se produise, vous pouvez définir ces clés de point d'accès pour qu'elles n'expirent jamais. Une autre méthode consiste à utiliser un verrou mutex pour contrôler l'accès des threads à la base de données de requêtes, mais cela entraînera une diminution du débit du système et devra être utilisé dans des situations réelles.

  Pénétration du cache

  La pénétration du cache fait référence à l'interrogation de données qui n'existent certainement pas. Parce qu'il n'y a aucune information sur les données dans le cache, elles iront directement à la couche de base de données pour une interrogation au niveau du système. comme la pénétration. La couche de cache atteint directement la base de données, ce qui est appelé pénétration du cache, ce type de requête pour des données qui ne doivent pas exister peut constituer un danger pour le système si quelqu'un utilise ces données de manière malveillante. Il ne doit pas exister de requêtes fréquentes adressées au système, non, pour être précis, d'attaques sur le système, les requêtes atteindront la couche de base de données, provoquant une paralysie de la base de données et une panne du système.

  Solution :

  Les solutions dans le secteur de la pénétration du cache sont relativement matures. Les principales couramment utilisées sont les suivantes :

  • Filtre Bloom : un algorithme similaire à une table de hachage, utilisant toutes les conditions de requête possibles. un bitmap. Ce bitmap sera utilisé pour le filtrage avant la requête dans la base de données. S'il n'est pas inclus dans la requête, il sera filtré directement, réduisant ainsi la pression au niveau de la base de données.
  • Cache de valeurs nulles : une solution relativement simple consiste à mettre la clé et la valeur nulle correspondante (nulle ou uniquement la clé dans l'objet) dans le cache après avoir interrogé pour la première fois les données inexistantes. un délai d'expiration plus court, par exemple quelques minutes, afin que vous puissiez faire face à un grand nombre d'attaques sur cette clé dans un court laps de temps. La raison pour laquelle vous définissez un délai d'expiration plus court est que cette valeur peut n'avoir rien à voir avec. l'entreprise, et son existence a peu d'importance. La requête ne peut pas être initiée par un attaquant et il n'est pas nécessaire de la stocker pendant une longue période, elle peut donc être invalidée plus tôt.

  Résumé

  Étant donné que cet article est un article théorique, il n'y a pas une seule ligne de code dans tout l'article, mais ce qui est proposé dans l'article est essentiellement ce qui s'est passé dans le système de vente flash, et les problèmes qui peuvent survenir dans chaque système sont différents.

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!