Introduction à la conception d'architecture Java à haute concurrence (images et texte)

Le contenu de cet article est une introduction (images et textes) sur la conception d'architecture Java à haute concurrence. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Préface

Une concurrence élevée se produit souvent dans des scénarios commerciaux avec un grand nombre d'utilisateurs actifs et une forte concentration d'utilisateurs, tels que : les activités de vente flash, la réception d'enveloppes rouges à intervalles réguliers, etc.

Afin de permettre à l'entreprise de fonctionner correctement et d'offrir aux utilisateurs une bonne expérience interactive, nous devons concevoir une solution de traitement à haute concurrence adaptée à notre scénario commercial en fonction de facteurs tels que la concurrence estimée du scénario commercial. .

Recommandation de cours vidéo → : "Solution de concurrence de données de niveau dix millions (théorie + combat pratique)"

Dans Au cours des années de développement de produits liés au commerce électronique, j'ai eu la chance de rencontrer divers pièges. Il y a eu beaucoup de sang et de larmes en cours de route. Le résumé ici est utilisé comme mon propre document d'archives et je le partagerai avec. tout le monde. .

1. Architecture du serveur

L'entreprise a progressivement mûri depuis les premiers stades de développement, et l'architecture du serveur a également évolué de relativement unique à clusterisée puis distribuée. services.

Une bonne architecture de serveur capable de prendre en charge une concurrence élevée est indispensable. Elle nécessite une charge équilibrée, la base de données a besoin d'un cluster maître-esclave, le cache nosql a besoin d'un cluster maître-esclave et les fichiers statiques doivent être téléchargés vers cdn. Ce sont toutes des choses qui peuvent permettre aux programmes commerciaux de bénéficier d'un support puissant pour un fonctionnement fluide.

La partie serveur nécessite principalement du personnel d'exploitation et de maintenance pour coopérer avec la construction. Je n'entrerai pas dans plus de détails et m'arrêterai ici.

L'architecture de serveur à peu près requise est la suivante :

Serveur

Charge d'équilibrage (telle que : nginx, Alibaba Cloud SLB)

Surveillance des ressources

Distribuée

Base de données

Séparation maître-esclave, cluster

Optimisation des tables DBA, optimisation des index, etc.

Formule de distribution

nosql

séparation maître-esclave, cluster

séparation maître-esclave, cluster

séparation maître-esclave, cluster

redis

mongodb

memcache

cdn

html

css

js

image

Tests de concurrence

Les entreprises liées à une concurrence élevée nécessitent des tests de concurrence, et une grande quantité d'analyses de données est utilisée pour évaluer le degré de concurrence que l'ensemble de l'architecture peut soutenir.

Pour tester une simultanéité élevée, vous pouvez utiliser un serveur tiers ou votre propre serveur de test, utiliser des outils de test pour tester les requêtes simultanées et analyser les données de test pour obtenir une estimation du nombre de simultanéités pouvant être pris en charge. Cela peut être utilisé comme référence d'alerte précoce. Comme le dit le proverbe, connaissez-vous et connaissez votre ennemi. Menez une centaine de batailles sans danger.

Services tiers :

Test de performances du cloud Alibaba

Outil de test de concurrence :

Apache JMeter

Test de charge des performances de Visual Studio

Outil de stress des applications Web Microsoft

Solution pratique

Solution générale

Le trafic utilisateur quotidien est important, mais il est relativement dispersé, et il y aura occasionnellement être des rassemblements élevés d'utilisateurs

Scénarios : enregistrement des utilisateurs, centre utilisateur, commande des utilisateurs, etc.

Schéma de l'architecture du serveur :

Remarque :

Ces entreprises dans le scénario sont essentiellement celles que les utilisateurs exploiteront après être entrés dans l'APP, à l'exception des jours d'événement (618. , Double 11, etc.), ces entreprises Le nombre d'utilisateurs ne sera pas élevé. Dans le même temps, ces tables liées aux entreprises sont toutes des tables de Big Data, et l'activité consiste principalement en des opérations de requêtes, nous devons donc réduire les requêtes. que les utilisateurs accèdent directement à la base de données ; interrogent d'abord le cache, et si le cache n'existe pas, effectuent ensuite des requêtes sur la base de données, mettent en cache les résultats de la requête.

La mise à jour des caches liés aux utilisateurs nécessite un stockage distribué, comme l'utilisation d'ID utilisateur pour le regroupement de hachage et la distribution des utilisateurs dans différents caches. De cette manière, la quantité totale d'un ensemble de cache ne sera pas importante et n'affectera pas la requête. efficacité.

Schémas tels que :

Les utilisateurs se connectent pour obtenir des points

Calculez la clé de distribution de l'utilisateur et recherchez les informations de connexion de l'utilisateur aujourd'hui dans hachage redis

Si les informations d'enregistrement sont interrogées, les informations d'enregistrement seront renvoyées

Si elles ne sont pas interrogées, la base de données demandera si l'enregistrement a été effectué aujourd'hui Si tel est le cas, les informations d'enregistrement seront synchronisées avec le cache Redis.

Si l'enregistrement d'enregistrement d'aujourd'hui n'est pas interrogé dans la base de données, la logique d'enregistrement est effectuée et la base de données est utilisée pour ajouter l'enregistrement d'enregistrement d'aujourd'hui et les points d'enregistrement (toute cette opération de base de données est une transaction)

Cache check-in Envoyez les informations à redis et renvoyez les informations d'enregistrement

Remarque

Il y aura des problèmes logiques dans les situations de concurrence, telles que : s'enregistrer plusieurs fois par jour et délivrer plusieurs points aux utilisateurs.

Mon article de blog [La haute concurrence aux yeux des programmeurs] propose des solutions pertinentes.

Commandes des utilisateurs

Ici, nous mettons en cache uniquement les informations de commande sur la première page de l'utilisateur, avec 40 éléments de données sur une seule page. données sur la première page.

Si l'utilisateur accède à la liste des commandes, si c'est la première page à lire le cache, s'il ne lit pas la base de données

Calculez la clé distribuée par le utilisateur et recherchez les informations de commande de l'utilisateur dans le hachage Redis

Si vous interrogez les informations de commande de l'utilisateur et retournez les informations de commande

S'il n'existe pas, effectuez une requête DB pour les données de commande sur la première page, puis mettez en cache Redis et renvoyez les informations de commande

Centre utilisateur

Calculer la clé de distribution de l'utilisateur , Rechercher les informations de commande des utilisateurs dans redis hash

Si les informations utilisateur sont demandées, renvoyer les informations utilisateur

S'il n'existe pas, interroger l'utilisateur DB, puis mettre en cache redis et renvoyer l'utilisateur informations

Autres entreprises

L'exemple ci-dessus est une architecture à haute concurrence relativement simple, qui peut être bien prise en charge lorsque le degré de concurrence n'est pas très élevé. à mesure que l'entreprise se développe, le niveau de concurrence des utilisateurs augmente. Notre architecture continuera également à être optimisée et évoluée, comme par exemple pour le service de l'entreprise, chaque service possède sa propre architecture simultanée, son propre serveur équilibré, sa base de données distribuée et son maître-esclave NoSQL. cluster, tels que les services utilisateur et les services de commande ;

File d'attente de messages

Activités telles que les ventes flash et les captures flash, les utilisateurs affluent en un instant et génèrent des demandes simultanées élevées

Scénario : recevoir régulièrement des enveloppes rouges, etc.

Schéma de l'architecture du serveur :

Description :

Collecte programmée dans la scène Il s'agit d'une activité hautement concurrente. Par exemple, les utilisateurs des activités de vente flash afflueront à un certain moment. La base de données recevra un coup critique en un instant. ne peut pas le retenir, il baissera, ce qui affectera l'ensemble de l'entreprise ;

Comme Ce type d'entreprise n'est pas seulement une opération de requête, mais implique également une insertion ou une mise à jour de données hautement simultanées. La solution générale mentionnée ci-dessus ne peut pas prendre en charge. Pendant la simultanéité, il atteint directement la base de données ;

a conçu cette entreprise. La file d'attente des messages sera utilisée lorsque la file d'attente des messages est utilisée. Vous pouvez ajouter les informations de l'utilisateur participant à la file d'attente des messages, puis écrire un multi. -programme threadé pour consommer la file d'attente et émettre des enveloppes rouges aux utilisateurs dans la file d'attente

La solution est la suivante ：

Recevoir régulièrement des enveloppes rouges

Il est généralement utilisé pour utiliser la liste Redis

Lorsque l'utilisateur participe à l'activité, poussez les informations de participation de l'utilisateur dans la file d'attente

Ensuite, écrivez un programme multithread pour afficher les données et effectuer l'émission d'enveloppes rouges

Cela peut aider les utilisateurs à forte concurrence à participer normalement aux activités et éviter le risque d'indisponibilité du serveur de base de données

Cache de niveau 1

Le serveur de cache de connexions de requêtes simultanées élevé dépasse le nombre de connexions de requêtes que le serveur peut recevoir, et certains utilisateurs ont le problème d'établir une connexion qui expire et ne peut pas lire les données ;

Par conséquent, il doit y avoir une solution capable de réduire le nombre d'accès au serveur de cache lorsque la concurrence est élevée

À ce stade, la solution de cache de premier niveau apparaît. cache pour stocker les données. Notez que seule une partie du volume de la demande est stockée. Les données volumineuses doivent être contrôlées. La mémoire du serveur du site ne peut pas être utilisée de manière excessive et affecter le fonctionnement normal de l'application du site. Le cache de premier niveau doit définir un délai d'expiration en secondes. Le délai spécifique est défini en fonction du scénario commercial. Le but Lorsqu'il y a un nombre élevé de demandes simultanées, l'acquisition de données peut être transmise au cache de premier niveau sans avoir à s'y connecter. le serveur de données nosql mis en cache, réduisant la pression sur le serveur de données nosql

Par exemple, l'interface de données de produit du premier écran de l'APP, ces données sont Les données publiques ne seront pas personnalisées pour les utilisateurs, et ces données seront ne pas être mis à jour fréquemment. Si le volume de requêtes de cette interface est relativement important, il peut être ajouté au cache de premier niveau

Schéma de l'architecture du serveur :

Normaliser et utiliser raisonnablement la base de données de cache nosql, et diviser le cluster de base de données de cache en fonction de l'entreprise. Cela peut fondamentalement bien prendre en charge l'entreprise, et le cache de premier niveau après tout. , vous utilisez le cache du serveur du site, vous devez donc quand même en faire bon usage.

Données statiques

Lorsque les données de requêtes simultanées élevées ne changent pas, si vous n'avez pas besoin de demander à votre propre serveur pour obtenir des données, vous pouvez réduire la pression des ressources sur le serveur.

Si la fréquence de mise à jour n'est pas élevée et que les données autorisent un court délai, vous pouvez convertir statiquement les données en JSON, XML, HTML et autres fichiers de données et les télécharger sur CDN, donner la priorité à l'extraction des données. le CDN. Si les données ne sont pas obtenues, récupérez-les à partir du cache ou de la base de données. Lorsque l'administrateur utilise l'arrière-plan pour modifier les données, régénérez le fichier statique et téléchargez-le sur le CDN, afin que les données puissent être obtenues sur le CDN. Serveur CDN pendant les périodes de forte concurrence. Il existe un certain retard dans la synchronisation des nœuds CDN, il est donc également important de trouver un fournisseur de serveur CDN fiable.

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!