Quels sont les points de connaissance du projet redis ?

Points forts du projet :

1. Grâce à Seesion distribuée, plusieurs serveurs peuvent répondre en même temps.

2. Utilisez Redis comme cache pour améliorer la vitesse d'accès et la concurrence, réduire la pression sur la base de données et utiliser des balises mémoire pour réduire l'accès à Redis.

3. Utilisez des pages statiques pour accélérer l'accès des utilisateurs, améliorer le QPS, mettre les pages en cache dans le navigateur et séparer le front-end et le back-end pour réduire la pression du serveur.

4. Utilisez la file d'attente des messages pour effectuer une commande asynchrone, améliorer l'expérience utilisateur, réduire les pics et réduire le trafic.

5. Optimisation de la sécurité : double vérification du mot de passe md5, masquage de l'adresse de l'interface Flash Kill, limitation du courant de l'interface et anti-brossage, code de vérification de la formule mathématique.

Principaux points de connaissance :

Seesion distribuée

L'application réelle de notre service de vente flash peut non seulement être déployée sur un serveur, mais distribuée sur plusieurs serveurs à ce moment-là, si l'utilisateur se connecte sur le premier serveur, Le. la première requête va au premier serveur, mais la deuxième requête va au deuxième serveur, donc les informations de session de l'utilisateur sont perdues.

Solution : synchronisation de session, quel que soit le serveur auquel vous accédez, la session peut être obtenue en utilisant la méthode du cache Redis et en utilisant un serveur Redis spécifiquement pour stocker les informations de session de l'utilisateur. De cette façon, la session utilisateur ne sera pas perdue. (Chaque fois que vous avez besoin d'une session, récupérez-la simplement à partir du cache)

redis soulage la pression de la base de données

Ce projet utilise largement la technologie de mise en cache, y compris la mise en cache des informations utilisateur (session distribuée), la mise en cache des informations sur les produits, la mise en cache de l'inventaire des produits et La mise en cache des commandes, la mise en cache des pages et la mise en cache des objets réduisent l'accès au serveur de base de données.

Encapsulation universelle de clé de cache

Un problème est de savoir comment distinguer les caches dans différents modules, car la même valeur de clé peut exister

Solution : utilisez une classe abstraite pour définir BaseKey (préfixe), et définissez le préfixe de la clé de cache et le cache qu'il contient. Le délai d'expiration permet d'encapsuler la clé mise en cache. Laissez différents modules en hériter, de sorte qu'à chaque fois qu'il est stocké dans le cache d'un module, un préfixe spécifique au cache soit ajouté et différents délais d'expiration puissent être définis de manière uniforme.

Statistique de page (séparation du front-end et du backend)

L'objectif principal de la statique de page est d'accélérer le chargement de la page. Les pages de détails du produit et de détails de la commande sont transformées en HTML statique (HTML pur). les données doivent uniquement être effectuées via ajax pour demander au serveur et créer une page HTML statique qui peut être mise en cache dans le navigateur du client.

File d'attente de messages pour terminer la commande asynchrone

Utilisez la file d'attente de messages pour terminer la commande asynchrone, améliorer l'expérience utilisateur, réduire les pics et réduire le trafic

Idées :

1. Initialisation du système, charger le stock de quantité de produits dans Redis.

2. Le backend reçoit la demande de vente flash et Redis pré-réduit l'inventaire si l'inventaire a atteint la valeur critique, il n'est pas nécessaire de poursuivre la demande et un échec sera renvoyé directement, c'est-à-dire un grand nombre. des demandes ultérieures ne nécessitent pas de pression sur le système.

3. Déterminez si la commande de vente flash a été formée, déterminez si la vente flash est arrivée, évitez plusieurs produits d'un même compte et déterminez si la vente flash est répétée.

4. Si l'inventaire est suffisant et qu'il n'y a pas de ventes flash en double, la demande de vente flash sera encapsulée et le message sera mis en file d'attente, et un code (0) sera renvoyé au front-end, ce qui signifie qu'il est renvoyé. à la file d'attente. (Ce qui est renvoyé n'est pas un échec ou un succès, et cela ne peut pas être jugé pour le moment)

5. Une fois que le frontal a reçu les données, il affiche la file d'attente et interroge le serveur de requêtes en fonction de l'ID du produit (envisagez d'interroger une fois par mois). 200 ms).

6. Le back-end RabbitMQ surveille le canal nommé MIAOSHA_QUEUE pour la vente flash, il obtiendra les informations entrantes. Avant d'exécuter la vraie vente flash, il doit juger de l'inventaire de la base de données, déterminer si. pour répéter la vente flash, puis exécuter la transaction de vente flash (la transaction de vente flash est une opération atomique : décrémenter le stock de 1, passer une commande et rédiger la commande de vente flash).

7. À ce stade, le front-end interroge l'interface de requête MiaoshaResult en fonction de l'ID du produit pour vérifier si une commande de produit a été générée. Si la requête renvoie -1, cela signifie que la vente flash a échoué, et si elle renvoie 0. , cela signifie qu'il est dans la file d'attente. S'il renvoie >0, cela signifie que l'ID du produit signifie que la vente flash est réussie.

Optimisation de la sécurité

Double vérification du mot de passe md5, masquage de l'adresse de l'interface Flash Kill, limitation du courant de l'interface et anti-swiping, code de vérification de la formule mathématique.

Écriture de code élégante

Le résultat de sortie de l'interface est encapsulé sous forme de résultat

Le mauvais code est encapsulé sous forme de CodeMsg

Le cache d'accès est encapsulé sous forme de clé

Difficultés du projet et résolution de problèmes :

1 . Lors de l'utilisation de JMeter pour les tests de résistance, 5 000 threads sont activés, mais le système ne peut pas s'exécuter et une exception se produit

Cause : modifiez l'élément de configuration redis poolMaxTotal dans le fichier de configuration et définissez-le sur 1 000.

Élément de configuration #redis

redis.poolMaxTotal=1000

redis.poolMaxldle=500

redis.poolMaxWait=500

2 Si une grande quantité de cache est utilisée, il y aura une panne de cache, une avalanche de cache, un cache. cohérence, etc. question ?

La pénétration du cache consiste à faire une demande pour certaines données qui ne doivent pas exister. La demande pénétrera dans le cache et atteindra la base de données.

Solution : mettez en cache les données vides pour ces données inexistantes et filtrez ces demandes.

L'avalanche de cache fait référence au fait que les données ne sont pas chargées dans le cache, ou que les données mises en cache échouent (expirent) dans une grande zone en même temps, ou que le serveur de cache est en panne, ce qui entraîne un grand nombre de requêtes atteignant la base de données.

Solution :

Afin d'éviter simultanément les avalanches de cache causées par l'expiration du cache dans de grandes zones, cela peut être réalisé en observant le comportement des utilisateurs et en définissant le délai d'expiration du cache de manière raisonnable

Afin d'éviter ; avalanches de cache causées par les temps d'arrêt du serveur de cache, vous pouvez utiliser le cache distribué. Chaque nœud du cache distribué ne met en cache qu'une partie des données lorsqu'un nœud tombe en panne, il peut garantir que le cache des autres nœuds est toujours disponible.

Vous pouvez également effectuer un préchauffage du cache pour éviter une avalanche de cache due à une grande quantité de données qui ne sont pas mises en cache peu de temps après le démarrage du système.

Par exemple : définissez d'abord des délais d'expiration différents pour différents caches, tels que le cache de session, dans le préfixe userKey, le paramètre doit expirer dans 30 minutes et le temps de cache est mis à jour à chaque fois que l'utilisateur répond. . Chaque acquisition de session sera prolongée de 30 minutes, la probabilité d'expiration du cache est donc relativement faible

La cohérence du cache nécessite que les données mises en cache puissent être mises à jour en temps réel pendant que les données sont mises à jour.

Solution :

Mettez à jour le cache immédiatement lorsque les données sont mises à jour, essayez d'abord de lire à partir du cache et revenez directement après avoir lu les données si elles ne peuvent pas être lues ; lisez la base de données et les données seront écrites dans le cache et renvoyées.

Avant de lire le cache, déterminez d'abord si le cache est le plus récent. Si ce n'est pas le dernier, mettez-le à jour d'abord. Lorsque vous devez mettre à jour les données, mettez d'abord à jour la base de données, puis invalidez (. delete) les données correspondantes dans le cache.

3. L'utilisation intensive du cache met beaucoup de pression sur le serveur de cache. Vous réfléchissez à la façon de réduire l'accès à Redis ?

Lorsque Redis pré-réduit l'inventaire, un isOvermap est conservé dans la mémoire en tant que marque de mémoire. Lorsqu'il n'y a pas d'inventaire, il est défini sur true. Avant que chaque entreprise de vente flash n'accède à Redis, vérifiez la marque de la carte. Si c'est vrai, cela signifie qu'il n'y a pas d'inventaire et cela renverra directement un échec sans demander au serveur Redis.

4. Dans un scénario commercial avec de nombreuses demandes simultanées, lorsqu'un grand nombre de demandes arrivent trop tard pour être traitées, ou même que les demandes s'accumulent ?

File d'attente de messages, utilisée pour traiter les requêtes de manière asynchrone. Chaque fois qu'une demande arrive, au lieu de la traiter, elle est placée dans la file d'attente des messages, puis un écouteur est disposé en arrière-plan pour écouter les files d'attente de messages des différentes entreprises. Lorsqu'un message arrive, la logique métier est exécutée. . Cela évite l'exception d'un trop grand nombre de connexions à la base de données lorsque plusieurs requêtes sont traitées en même temps.

5. Comment s'assurer qu'un utilisateur ne puisse pas passer de commandes répétées ?

Solution : Créez un index unique dans la table des commandes de vente flash (la référence est l'ID utilisateur et l'ID du produit), afin que le premier enregistrement puisse être inséré, mais que le second fasse une erreur, et puis revenez en arrière dans la transaction pour empêcher le traitement de plusieurs demandes émises par un utilisateur en même temps et la vente instantanée de plusieurs produits.

Un index unique signifie unique. Après avoir ajouté un index unique à un champ dans la structure de la table de la base de données et effectué une opération de stockage sur la base de données, la base de données déterminera si les données existent déjà dans la base de données. les données n'existent pas, pour effectuer l'opération d'insertion.

Bien qu'il s'agisse d'une petite compétence, il s'agit en fait d'une compétence très pratique en matière de développement commercial. Par exemple, dans les activités à forte concurrence, comment la base de données peut-elle empêcher les données d'insérer simultanément deux numéros de commande identiques ? L'ajout d'un index unique est bien sûr l'une des méthodes les plus rapides. Bien sûr, l'ajout d'un index ou sa résolution via le code commercial dépend de l'activité de l'entreprise

6.

Scénario de survente : Lorsque différents utilisateurs lisent la demande, ils constatent que l'inventaire du produit est suffisant, puis lancent en même temps des demandes pour effectuer une opération de vente flash et réduire l'inventaire, provoquant une baisse du stock. être réduit à un nombre négatif.

La méthode la plus simple consiste à mettre à jour la base de données lors de la réduction des stocks et à implémenter des restrictions d'inventaire. Dans la méthode réduireStock (GoodsVo goodvo), ajoutez un stock_count > que le super Le problème de la vente est de lire stock_count uniquement lorsque stock_count est supérieur à 0, puis de soustraire 1.

@Update("update miaosha_goods set stock_count=stock_count-1 Where Goods_id=#{goodsId} et stock_count>0 ")

public void réduireStock(MiaoshaGoods marchandises);

7. Quel est le processus de statique de page et qu'est-ce que le cache du navigateur ?

Cache la page statique HTML dans le navigateur client. Seules les données sont obtenues via l'interface d'appel asynchrone ajax. Seule une partie des données interagit, ce qui réduit la bande passante et accélère l'accès des utilisateurs.

Le cache du navigateur consiste à stocker une copie d'une ressource Web demandée (telle qu'une page html, une image, un js, des données, etc.) dans le navigateur. Le cache conserve une copie du contenu de sortie en fonction des requêtes entrantes. Lors de la requête suivante, s'il s'agit de la même URL, le cache décidera selon le mécanisme de mise en cache s'il faut utiliser directement la copie pour répondre à la demande d'accès, ou renvoyer la requête au serveur source. Ce qui est plus courant, c'est que le navigateur mettra en cache les pages Web qui ont été visitées sur le site Web. Lorsque l'adresse URL est à nouveau visitée, si la page Web n'a pas été mise à jour, la page Web ne sera pas téléchargée à nouveau, mais localement. la page Web mise en cache sera utilisée directement. Ce n'est que lorsque le site Web identifie clairement que la ressource a été mise à jour que le navigateur télécharge à nouveau la page Web.

8. Concept de design d'architecture de vente flash ?

Limitation du trafic : étant donné que seul un petit nombre d'utilisateurs peut réussir à tuer instantanément, la majeure partie du trafic doit être restreinte et seule une petite partie du trafic est autorisée à entrer dans le backend du service.

Lors de la réalisation d'un événement de vente flash, il y aura un afflux instantané d'utilisateurs au début de la vente urgente, ce qui entraînera une période de pointe. Des mesures de réduction des pointes doivent donc être prises. Un trafic de pointe élevé est une raison importante pour surcharger le système, donc comment transformer un trafic élevé instantané en trafic stable pendant un certain temps est également une idée très importante dans la conception d'un système de vente flash. Les méthodes couramment utilisées pour atteindre l’écrêtage des pics incluent l’utilisation de technologies telles que la mise en cache et le middleware de messages.

Traitement asynchrone : le système de vente flash est un système à haute concurrence. L'utilisation du mode de traitement asynchrone peut considérablement augmenter la quantité de concurrence du système. En fait, le traitement asynchrone est un moyen de mettre en œuvre le découpage des pics.

Cache mémoire : le plus gros goulot d'étranglement du système de vente flash est généralement la lecture et l'écriture de la base de données. Étant donné que la lecture et l'écriture de la base de données appartiennent aux E/S du disque, les performances sont très faibles si certaines données ou logiques métier peuvent être transférées vers le cache mémoire. l'efficacité sera grandement améliorée.

Évolutif : bien sûr, si nous voulons prendre en charge plus d'utilisateurs et une plus grande concurrence, il est préférable de concevoir le système pour qu'il soit élastique et évolutif. Si le trafic arrive, il suffit d'étendre la machine. Lors des événements Double Eleven comme Taobao et JD.com, un grand nombre de machines seront ajoutées pour faire face aux pics de transactions.

9. Des idées de conception d'architecture de système de vente flash ?

Intercepter les requêtes en amont du système pour réduire la pression en aval : le système flash kill se caractérise par une grande quantité de concurrence, mais le nombre réel de requêtes flash kill réussies est très faible, donc s'il n'est pas intercepté à l'avant à la fin, cela provoquera probablement un conflit de verrouillage en lecture-écriture dans la base de données et la requête finale expirera.

Utiliser le cache : l'utilisation du cache peut améliorer considérablement la vitesse de lecture et d'écriture du système.

File d'attente des messages : la file d'attente des messages peut réduire le pic et intercepter un grand nombre de demandes simultanées. Il s'agit également d'un processus de traitement asynchrone. L'entreprise en arrière-plan extrait activement les messages de demande de la file d'attente des messages pour les traiter en fonction de ses propres capacités de traitement.

10. Si l'inventaire est réduit et que l'utilisateur ne paie pas, comment peut-il restaurer l'inventaire et continuer à participer à la vente urgente

Définir un délai de paiement maximum, par exemple 30 minutes, et il y a une tâche planifiée ? en arrière-plan (utiliser un timer). Si la rotation dépasse 30 minutes. La commande à payer (le statut de la commande est déterminé dans la base de données), alors la commande est clôturée et l'inventaire est reconstitué.

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!