Quels sont les principes fondamentaux de l’architecture technique des sites Web à grande échelle MySQL ?

1. Évolution de l'architecture de sites Web à grande échelle

A. Caractéristiques des systèmes logiciels de sites Web à grande échelle

Concurrence élevée, haute disponibilité de données massives ; environnement ; changements rapides des exigences, versions fréquentes ; développement progressif

B. Processus d'évolution et de développement de l'architecture du site Web à grande échelle

1. Étape initiale : un serveur, LNMP

2. services : serveur d'applications (CPU) ; serveur de base de données (récupération rapide du disque et mise en cache des données) ; serveur de fichiers (grand disque dur) ;

3. Utiliser le cache pour améliorer les performances du site Web : cache local sur le serveur d'applications (vitesse d'accès rapide, limité par la mémoire du serveur d'applications, volume de données limité), cache distribué à distance (utilisez un cluster pour déployer un serveur à grande mémoire en tant que serveur de cache dédié)

4 ​​Cluster de serveur d'applications : planifié via l'équilibrage de charge

5. séparation d'écriture

6. Utiliser le proxy inverse et l'accélération CDN : CDN (déployé dans la salle informatique du réseau la plus proche), proxy inverse (déployé dans la salle informatique centrale)

7 Utiliser des systèmes de fichiers distribués et des systèmes de bases de données distribuées

8. Utilisez NoSQL et les moteurs de recherche

9. Répartition des activités

10. Services distribués

C Valeurs dans l'évolution de l'architecture de sites Web à grande échelle

1. pour répondre avec flexibilité aux besoins du site Web

2. La principale force à l'origine du développement de la technologie des sites Web à grande échelle est le développement commercial des sites Web

D. Malentendus dans la conception de l'architecture des sites Web

1. entreprises

2. La technologie pour le bien de la technologie

3. Tenter d'utiliser la technologie pour résoudre tous les problèmes : la technologie est utilisée pour résoudre les problèmes commerciaux, et les problèmes commerciaux peuvent également être résolus par des moyens commerciaux

2. Architecture de grands sites Web. modèles

Chaque modèle représente un problème récurrent et la solution principale au problème. De cette façon, vous pouvez utiliser la solution encore et encore sans avoir à dupliquer le travail. La clé d’un modèle est la répétabilité du modèle.

A. Modèle d'architecture de site Web

1. Superposition

• Superposition : c'est le modèle architectural le plus courant dans les systèmes d'applications d'entreprise, qui divise le système en plusieurs parties dans la dimension horizontale, et chaque partie est responsable de certaines. responsabilités relativement uniques, puis forment un système complet à travers les dépendances et les appels de la couche supérieure vers la couche inférieure.
  

• Divisez le système logiciel du site Web en couche d'application (couche de vue, couche de logique métier), couche de service (couche d'interface de données, couche de traitement logique), couche de données
  

• peut mieux intégrer un énorme logiciel Le système est divisé en différentes parties pour faciliter la division du travail, le développement coopératif et la maintenance ; il existe un certain degré d'indépendance entre chaque couche tant que l'interface d'appel reste inchangée, chaque couche peut approfondir indépendamment le développement en fonction de problèmes spécifiques sans avoir besoin d'autres. calques pour effectuer les ajustements correspondants.
  

2. Divisez

• Coupez verticalement. Séparez les différentes fonctions et services et regroupez-les dans des unités modulaires à haute cohésion et faible couplage. La granularité de la segmentation des grands sites Web peut être très faible.
  

3. Distribué

• signifie que différents modules sont déployés sur différents serveurs et fonctionnent ensemble via des appels à distance. Cela signifie que davantage d’ordinateurs peuvent être utilisés pour remplir la même fonction.
  

• Problèmes : Le réseau peut avoir un impact sérieux sur les performances ; la probabilité de temps d'arrêt de plusieurs serveurs est également très difficile à maintenir dans un environnement distribué, ce qui rend difficile le traitement et la maintenance du site Web ; s'appuie sur un développement complexe ;
  

• Solutions distribuées courantes : applications et services distribués ; données et stockage distribués (Hadoop et sa configuration distribuée ;
  

4. Cluster

• Plusieurs serveurs déploient la même application pour former un cluster et fournissent conjointement des services externes via un équipement d'équilibrage de charge.

  
  

5. Mise en cache

• La mise en cache consiste à stocker certaines données à l'emplacement le plus proche du calcul pour accélérer le traitement.

  
  

• CDN, proxy inverse, cache local, cache distribué.

  
  

• Deux conditions préalables à l'utilisation du cache : premièrement, les points d'accès aux données sont déséquilibrés ; deuxièmement, les données sont valides dans un certain laps de temps

  
  

6. , une opération commerciale est divisée en plusieurs étapes, et chaque étape est exécutée de manière asynchrone pour la collaboration par partage de données.

• Un seul serveur peut réaliser une exécution asynchrone via des files d'attente de mémoire partagée multithread ; dans un système distribué, plusieurs clusters de serveurs peuvent réaliser une exécution asynchrone via des files d'attente de messages distribuées.
  

• Dans le modèle producteur-consommateur typique, il n'y a pas de relation d'appel directe entre les producteurs et les consommateurs. Les caractéristiques de ce modèle sont qu'il peut améliorer la disponibilité du système, accélérer la vitesse de réponse du site Web et. éliminer la concurrence.
  

• L'utilisation de méthodes asynchrones pour traiter les affaires peut avoir un impact sur l'expérience utilisateur et les processus métier, et nécessite une assistance en matière de conception de produits.
  

7. Redondance

• Si vous voulez vous assurer que le site Web peut toujours continuer à fonctionner sans perdre de données lorsque le serveur est en panne, vous avez besoin d'un certain degré de redondance du serveur et d'une sauvegarde de redondance des données.
  

• Les petits sites Web ont également besoin d'au moins deux serveurs pour créer un cluster. En plus de la sauvegarde et du stockage réguliers pour réaliser une sauvegarde à froid, la base de données doit également effectuer un partage maître-esclave, une synchronisation en temps réel et une sauvegarde à chaud.
  

• Les grandes entreprises peuvent sauvegarder l'intégralité du centre de données et le synchroniser avec les centres locaux de reprise après sinistre.
  

8. L'automatisation

• se concentre principalement sur l'exploitation et la maintenance des versions.
  

• Automatisation du processus de release : gestion automatisée du code, tests automatisés, détection de sécurité automatisée, déploiement automatisé.
  

• Surveillance automatisée : alarmes automatisées, basculement automatisé, reprise après panne automatisée, dégradation automatisée, allocation automatisée des ressources.
  

9. Sécurité

B. Application du modèle architectural dans Sina Weibo

3. Éléments architecturaux de base des grands sites Web

Architecture : le plus haut niveau de planification, une décision difficile à changer .

Architecture logicielle : une description abstraite de la structure globale et des composants du logiciel, utilisée pour guider la conception de tous les aspects des systèmes logiciels à grande échelle.

A. Performance

• Côté navigateur : cache du navigateur, compression des pages, mise en page raisonnable, réduction de la transmission des cookies, CDN, etc.
  

• Côté serveur d'application : cache local du serveur, cache distribué, fonctionnement asynchrone Coopérer avec files d'attente de messages, clusters, etc.
  

• Code : multi-threading, gestion améliorée de la mémoire, etc.
  

• Base de données : indexation, mise en cache, optimisation SQL, technologie NoSQL
  

B. Disponibilité

• Le principal moyen des environnements d'exploitation tels que les serveurs, les bases de données et le stockage de fichiers est la redondance.
  

• Grâce à la vérification préalable à la publication, aux tests automatisés, à la publication automatisée, à la publication en niveaux de gris et à d'autres moyens pendant le développement du logiciel
  

C Évolutivité

• L'évolutivité fait référence à l'ajout continu de serveurs au cluster. Des moyens pour atténuer la pression croissante de l’accès des utilisateurs simultanés et la demande croissante de stockage de données. Si l'ajout d'un nouveau serveur peut fournir les mêmes services que le serveur d'origine.
  

• Serveur d'applications : des serveurs peuvent être ajoutés en continu au cluster via un équipement d'équilibrage de charge approprié.
  

• Serveur de cache : en ajouter de nouveaux peut rendre la route du cache invalide. Un algorithme de routage est requis.
  

• Base de données relationnelle : via le partitionnement de routage et d'autres moyens.
  

D. Évolutivité

• Critères de mesure : Lorsque le site Web ajoute des produits professionnels, s'il peut être transparent et n'avoir aucun impact sur les produits existants ;
  moyens : Architecture événementielle (file d'attente de messages), services distribués (partage des activités et des services disponibles, appels via un framework de services distribués)

• 
  

  E Sécurité

4. Réponse instantanée : Haute performance du site Web. Architecture des performances

A. Test de performances du site Web

1. Performances du site Web sous différentes perspectives

du point de vue de l'utilisateur : optimiser le style HTML des pages, tirer parti de la concurrence côté navigateur et des fonctionnalités asynchrones, ajuster les stratégies de mise en cache du navigateur, et utilisez les services CDN, les proxys réfléchissants, etc.

• 
  Performances du site Web du point de vue d'un développeur : utilisation du cache pour accélérer la lecture des données, utilisation de clusters pour améliorer le débit, utilisation de messages asynchrones pour accélérer les réponses aux requêtes et atteindre un écrêtage maximal, et utilisation de méthodes d'optimisation du code pour améliorer les performances du programme.

• 
  Performance du site Web du point de vue du personnel d'exploitation et de maintenance : construction et optimisation de réseaux fédérateurs, utilisation de serveurs personnalisés rentables, utilisation de la technologie de virtualisation pour optimiser l'utilisation des ressources, etc.

• 
  2. Indicateurs de test de performance

Temps de réponse : la méthode de test consiste à répéter la demande et la somme des temps de test totaux de 10 000 fois est divisée par 10 000.

• 
  Nombre d'utilisateurs simultanés : Le nombre de requêtes que le système peut traiter en même temps (nombre d'utilisateurs du système du site Web >> utilisateurs en ligne du site Web >> utilisateurs simultanés du site Web). en simulant des utilisateurs simultanés via le multi-threading les capacités de traitement simultanées du système.

• 
  Débit : Le nombre de requêtes traitées par le système par unité de temps (TPS, HPS, QPS, etc.)

• 
  Compteurs de performances : Certains joysticks de données qui décrivent les performances du serveur ou du système d'exploitation. Une version réécrite de cette phrase est la suivante : la charge du système, le nombre d'objets et de threads, l'utilisation de la mémoire, l'utilisation du processeur, les E/S disque et réseau sont impliqués ici.

• 
  3. Méthodes de tests de performances : tests de performances, tests de charge, tests de contrainte, tests de stabilité

  Des tests de performance sont effectués pour ajouter continuellement de la charge au système afin d'obtenir des indicateurs de performance du système, une capacité de charge maximale et une tolérance de pression maximale. Ce que l'on appelle l'augmentation de la pression d'accès signifie une augmentation continue du nombre de demandes simultanées pour le programme de test.

  5. Stratégie d'optimisation des performances

  • Analyse des performances : Vérifiez les journaux de chaque lien de traitement des demandes, analysez quel lien a un temps de réponse déraisonnable et dépasse les attentes, puis vérifiez les données de surveillance ;
    

  B. Optimisation des performances du front-end Web

  1. Optimisation de l'accès au navigateur : réduire les requêtes http (fusionner CSS/JS/images), utiliser le cache du navigateur (Cache-Control et Expires dans l'en-tête HTTP), activer. Compression (Gzip), CSS est placé en haut de la page, JS est placé en bas de page, réduisant la transmission des cookies

  2 Accélération CND

  3 Proxy inverse : Accélérez les requêtes web en configurant la fonction cache. (Il peut également protéger les serveurs réels et mettre en œuvre des fonctions d'équilibrage de charge)

  C. Optimisation des performances du serveur d'applications

  1 Cache distribué

  • La première loi de l'optimisation des performances des sites Web : donner la priorité à l'utilisation du cache pour optimiser les performances
    .

  • Principalement utilisé pour stocker des données qui ont un taux de lecture-écriture élevé et qui changent rarement. Lorsque le cache ne peut pas être atteint, la base de données est lue et les données sont à nouveau écrites dans le cache.
    

  2. Utilisation raisonnable du cache : ne pas modifier fréquemment les données, accès sans points chauds, incohérences de données et lectures sales, disponibilité du cache (sauvegarde à chaud du cache), préchauffage du cache (précharger certains caches au démarrage du programme), Cache pénétration

  3. Architecture de cache distribuée : caches distribués qui doivent être mis à jour de manière synchrone (JBoss Cache), caches distribués qui ne communiquent pas entre eux (Memcached)

  4. la stabilité et les performances du site Web), a un bon effet de réduction des pics et stocke les messages de transaction générés par une concurrence élevée sur une courte période de temps dans la file d'attente des messages.

  5. Utiliser des clusters

  6. Optimisation du code :

  • Multi-threading (blocage IO et multi-CPU, nombre de threads de démarrage = [temps d'exécution de la tâche/(temps d'exécution de la tâche-temps d'attente IO)]*nombre des cœurs de processeur, nécessité de prêter attention à la sécurité des threads : concevoir les objets comme des objets sans état, utiliser des objets locaux et utiliser des verrous lors de l'accès simultané aux ressources
    

  • Réutilisation des ressources (cas uniques et pools d'objets) ;
    Structure des données ;

  • Garbage collection
    

  • 
    D Optimisation des performances de stockage

  1. La base de données utilise principalement une arborescence d'index B+ à deux niveaux, et le niveau de l'arborescence peut aller jusqu'à trois niveaux. La mise à jour d'un enregistrement peut prendre 5 accès au disque.

  2. De nombreux produits NoSQL utilisent des arbres LSM, qui peuvent être considérés comme un arbre de fusion d'ordre N.

  3. RAID (Redundant Array of Inexpensive Disks), RAID0, RAID1, RAID10, RAID5, RAID6, sont largement utilisés dans les bases de données relationnelles et les systèmes de fichiers traditionnels.
  4.HDFS (Hadoop Distributed File System), coopère avec MapReduce pour le traitement du Big Data.

  5. Infaillible : Architecture hautement disponible du site Internet

  A. Mesure et évaluation de la disponibilité du site Internet

  1. Mesure de la disponibilité du site Internet
  Temps d'indisponibilité du site Internet (temps de panne) = instant de réparation du défaut - Point temporel de découverte des pannes (rapport)

  • Indicateur de disponibilité annuelle du site Web = (1 temps d'indisponibilité du site Web/durée annuelle totale)*100 %
    

  • 2 9s sont fondamentalement disponibles, 88 heures 3 9s C'est hautement ; disponible, 9 heures ; 4 9 s est une haute disponibilité avec capacité de récupération automatique, 53 minutes ; 5 9 s est une disponibilité extrêmement élevée, moins de 5 minutes ; QQ est de 99,99, 4 9 s et est indisponible pendant environ 53 minutes par an.
    

  • 2. Évaluation de la convivialité du site Web
    

  Score de défaillance : fait référence à la méthode de classification et de pondération des défaillances d'un site Web pour calculer la responsabilité de la défaillance

  • Score de défaillance = temps de défaillance (minutes) * poids de la défaillance
    

  • 
    B. Architecture de site Web hautement disponible

  Le principal moyen est la sauvegarde redondante et le basculement des données et des services. La couche application et la couche service utilisent l'équilibrage de charge du cluster pour atteindre une haute disponibilité, et la couche données utilise la réplication synchrone des données pour réaliser une sauvegarde redondante.

  C. Applications hautement disponibles

  1. Basculement des services sans état via l'équilibrage de charge : même si l'accès aux applications est très réduit, déployez au moins deux serveurs pour créer un petit cluster en utilisant l'équilibrage de charge.

  2. Gestion des sessions du cluster de serveurs d'applications

  Réplication de sessions : synchronisation des sessions entre serveurs, petits clusters

  • Liaison de session : utilisation du hachage d'adresse source pour distribuer les requêtes provenant de la même IP vers le même serveur, ce qui a un impact sur la haute disponibilité.
    

  • Utilisez des cookies pour enregistrer la session : limite de taille, chaque réponse à une demande doit être transmise, et si vous désactivez les cookies, vous ne pourrez pas accéder au
    

  • Serveur de session : Utiliser le cache distribué, la base de données, etc., haute disponibilité, haute évolutivité et hautes performances Bonne
    

  • 
    D Service haute disponibilité

  1. Les serveurs sont hiérarchiques dans l'exploitation et la maintenance. Les applications et services de base donnent la priorité à l'utilisation d'un meilleur matériel et. la vitesse de réponse d'exploitation et de maintenance est également extrêmement rapide.

  2. Paramètre de délai d'attente : définissez le délai d'expiration pour les appels de service dans l'application. Une fois le délai d'expiration expiré, le cadre de communication génère une exception en fonction de la politique de planification du service, l'application peut choisir de continuer à réessayer ou de transférer la demande vers d'autres serveurs. fournir le même service supérieur.

  L'application termine l'appel au service via des méthodes asynchrones telles que les files d'attente de messages pour éviter la situation où l'ensemble de la demande d'application échoue lorsqu'un service échoue.

  4. Dégradation du service : déni de service, rejet d'appels provenant d'applications de faible priorité ou rejet aléatoire de certaines demandes d'appel ; arrêt de fonctions, arrêt de certains services sans importance ou arrêt de certaines fonctions sans importance au sein du service.

  5. Conception idempotente : dans la couche service, il est garanti que les appels répétés au service produiront les mêmes résultats que ceux appelés une fois, c'est-à-dire que le service est idempotent.

  E. Données hautement disponibles

  1.Principe CAP

  • Données hautement disponibles : persistance des données (stockage permanent, les copies de sauvegarde ne seront pas perdues), accessibilité des données (basculement rapide entre différents appareils) ), cohérence des données (dans le cas de copies multiples, la cohérence des données de copie est garantie)
    

  • Principe CAP : Un système de stockage qui fournit des services de données ne peut pas satisfaire la cohérence des données (Cohérence), la disponibilité des données (Availability) et la tolérance de partition à en même temps (Partition Tolerance, le système est évolutif sur les partitions réseau).
    

  • Habituellement, les grands sites Web améliorent la disponibilité (A) et l'évolutivité (P) du système distribué, sacrifiant dans une certaine mesure la cohérence (C). D'une manière générale, l'incohérence des données se produit généralement lorsque le système a des opérations d'écriture simultanées élevées ou que l'état du cluster est instable. Le système d'application doit comprendre l'incohérence des données du système de traitement de données distribué et effectuer une compensation et une correction des erreurs dans une certaine mesure. données incorrectes du système d’application.
    

  • La cohérence des données peut être divisée en : une forte cohérence des données (toutes les opérations sont cohérentes), une cohérence des données de l'utilisateur (les copies peuvent être incohérentes, mais lorsque les utilisateurs y accèdent, une vérification de correction d'erreur est utilisée pour déterminer qu'une donnée correcte est renvoyée à utilisateur), les données sont finalement cohérentes (les copies et l'accès des utilisateurs peuvent être incohérents, mais le système atteint la cohérence après une période d'auto-récupération et de correction)
    

  2. Sauvegarde des données

  • Sauvegarde à chaud asynchrone : multiple. copies de données L'opération d'écriture est terminée de manière asynchrone. Lorsque l'application reçoit une réponse réussie du système de service de données pour l'opération d'écriture, une seule copie est écrite avec succès et le système de stockage écrira d'autres copies de manière asynchrone (ce qui peut échouer)
    

  • Synchronous Hot Standby : Multiple L'opération d'écriture des copies de données est terminée de manière synchrone, c'est-à-dire que lorsque l'application reçoit la réponse de réussite d'écriture du système de service de données, l'opération d'écriture de plusieurs copies de données a réussi.
    

  3. Transfert d'échec

  • Confirmation d'échec : détection de battement de cœur, échec d'accès à l'application
    

  • Transfert d'accès : après avoir confirmé qu'un serveur est en panne, redirigez l'accès en lecture et en écriture des données vers d'autres serveurs
    

  • Récupération de données : copiez les données d'un serveur sain et restaurez le nombre de copies de données à la valeur définie
    

  F Assurance qualité du logiciel pour les sites Web à haute disponibilité

  1. Automatisée. tests : l'outil Selenium

  effectue une vérification préliminaire sur le serveur de pré-version. Nous le publierons d'abord sur la machine de pré-version pour une utilisation par les ingénieurs de développement et les ingénieurs de test. Il nécessite la même configuration, le même environnement, le même centre de données, etc. que l'environnement de production

  4. Contrôle du code : svn, git ; développement de branche, développement de branche, version principale (mainstream) 

   ;

  6. Version en niveaux de gris : divisez le serveur du cluster en plusieurs parties, libérez seulement une partie du serveur chaque jour et observez que le fonctionnement est stable et sans défaut. Si des problèmes sont détectés au cours de la période, il vous suffit de restaurer une version en niveaux de gris. partie du serveur publié. Également couramment utilisé pour les tests utilisateurs (tests AB).

  G. Surveillance du fonctionnement du site Web

  1. Collecte de données de surveillance

  Collectez les journaux de comportement des utilisateurs, y compris la version du système d'exploitation et du navigateur, l'adresse IP, le chemin d'accès à la page, le temps d'attente de la page et d'autres informations. Y compris la collecte de journaux côté serveur et la collecte de journaux de navigateur côté client.

  • 
    Collecte des performances du serveur : telles que la charge du système, l'utilisation de la mémoire, les E/S du disque, les E/S du réseau, etc., les outils Ganglia, etc.

  • 
    Exécution de rapports de données : tels que le taux de réussite du tampon, le temps de réponse moyen , le nombre d'emails envoyés par minute, le nombre total de tâches à traiter, etc.

  • 
    2. Surveillance et gestion

  Alarme système : définissez des seuils pour divers indicateurs de surveillance et utilisez les e-mails, les outils de messagerie instantanée, les SMS, etc. Transfert d'échec

  • 
    Rétrogradation automatique et gracieuse : jugez la charge des applications en fonction des paramètres de surveillance, désinstallez de manière appropriée les serveurs d'applications à faible charge et réinstallez les applications à forte charge pour équilibrer la charge globale des applications.

  • 
    

    6. Sans fin : L'architecture évolutive du site Web

  • La soi-disant évolutivité du site Web signifie que le site Web peut être étendu ou réduit simplement en changeant le nombre de serveurs déployés sans changer le logiciel et la conception matérielle des capacités de traitement du service.
    

    A. Conception évolutive de l'architecture du site Web

    1. Séparation physique des différentes fonctions pour réaliser la mise à l'échelle : séparation verticale (séparation après superposition), traitement métier Différentes parties du processus sont déployés séparément pour atteindre l'évolutivité du système ; la séparation horizontale (séparation après segmentation commerciale) sépare et déploie différents modules métier pour atteindre l'évolutivité du système.

    2. Une seule fonction peut être mise à l'échelle grâce à l'échelle du cluster

    B. # 1. Le serveur d'applications doit être conçu pour être sans état et ne pas stocker d'informations contextuelles de demande.

    2. Équilibrage de charge :
    Équilibrage de charge de redirection HTTP : calculez une véritable adresse de serveur Web en fonction de la requête HTTP de l'utilisateur, et écrivez la adresse du serveur dans la réponse de redirection HTTP et renvoyez-la au navigateur de l'utilisateur. Cette solution a ses avantages, mais ses inconvénients sont qu'elle nécessite deux requêtes et que la puissance de traitement du serveur de redirection lui-même peut être limitée. De plus, 302 sauts peuvent également affecter le référencement.

    • 
      

      Équilibrage de charge de résolution de nom de domaine DNS : Configurez plusieurs enregistrements A sur le serveur DNS pour pointer vers différentes IP. L'avantage est que le travail d'équilibrage de charge est. transféré vers le DNS Less prend également en charge la géolocalisation pour renvoyer le serveur le plus proche. L'inconvénient est que l'enregistrement A peut être mis en cache et que le contrôle incombe au fournisseur de services de noms de domaine.

    • 
      

      Équilibrage de charge proxy réfléchissant : l'adresse demandée par le navigateur est le serveur proxy inverse. Une fois que le serveur proxy inverse a reçu la demande, elle sera traitée. selon l'algorithme d'équilibrage de charge, calculez l'adresse d'un serveur physique réel et transmettez la demande au serveur réel. Une fois le traitement terminé, la réponse est renvoyée au serveur proxy inverse et le serveur proxy inverse renvoie la réponse à l'utilisateur. . Également appelé équilibrage de charge de la couche application (couche HTTP). Son déploiement est simple, mais les performances du proxy inverse peuvent devenir un goulot d'étranglement.

    • 
      

      Équilibrage de charge IP : une fois que le paquet de données de la demande de l'utilisateur atteint le serveur d'équilibrage de charge, le serveur d'équilibrage de charge obtient le paquet de données réseau dans le noyau du système d'exploitation processus et basé sur l'équilibrage de charge. L'algorithme calcule un serveur Web réel, puis modifie l'adresse IP de destination des données en serveur réel sans avoir besoin de traitement du processus utilisateur. Une fois le traitement terminé par le serveur réel, le paquet de réponse est renvoyé au serveur d'équilibrage de charge, et le serveur d'équilibrage de charge modifie l'adresse source du paquet en sa propre adresse IP et l'envoie au navigateur de l'utilisateur.

    • 
      

      Équilibrage de charge de la couche liaison de données : mode de transmission triangulaire, l'adresse IP n'est pas modifiée lors du processus de distribution des données du serveur d'équilibrage de charge, uniquement la destination L'adresse mac est modifiée, via Les adresses IP virtuelles de tous les serveurs sont cohérentes avec les adresses IP des serveurs d'équilibrage de charge. Les adresses source et destination des paquets de données ne sont pas modifiées. Les IP étant cohérentes, les paquets de données de réponse peuvent être modifiés. renvoyé directement au navigateur de l'utilisateur. Également appelé routage direct (DR). Représente le produit LVS (Linux Virtual Server).

    • 
      

      3. Algorithme d'équilibrage de charge :
    Polling (Round Robin, RR) : Toutes les requêtes sont distribuées à chaque serveur d'applications

    • 
      

      Weighted Round Robin (WRR) : Selon les performances du matériel du serveur, dans le tour Réparti selon le poids configuré en fonction de la requête

    • 
      

      Aléatoire : La requête est distribuée aléatoirement à chaque serveur d'application
    #🎜🎜 #

    • 
      Moins de connexions : Enregistrez le nombre de connexions en cours de traitement par le serveur et distribuez les nouvelles requêtes au serveur avec le moins de connexions

    #🎜🎜 #
    • #🎜 🎜# Source Hashing : calcul de hachage basé sur l'adresse IP de la source de la requête

      
      

    • #🎜🎜 #C. 🎜#

      
      1. Modèle d'accès du cluster de cache distribué Memcached

    Module d'algorithme de routage d'entrée et algorithme de routage via KEY Calculez un serveur Memcached pour la lecture et l'écriture.

    2. Défis d'évolutivité du cluster de cache distribué MemcachedUn algorithme de routage simple consiste à utiliser la méthode de hachage du reste : divisez la valeur de hachage de la clé de données mise en cache par le nombre de serveurs , recherchez le numéro de serveur correspondant au reste. N'évolue pas bien.

    3.

    Algorithme de hachage cohérent

    Construisez d'abord un anneau entier d'une longueur de 2 élevée à la puissance 32 (anneau de hachage de cohérence ), le nœud du serveur de cache est placé sur cet anneau de hachage en fonction de la valeur de hachage du nom du nœud. Calculez ensuite la valeur de hachage en fonction de la valeur KEY des données qui doivent être mises en cache, puis recherchez dans le sens des aiguilles d'une montre sur l'anneau de hachage le nœud du serveur de cache le plus proche de la valeur de hachage de la KEY pour terminer la recherche de mappage de hachage de KEY vers le serveur.

    D. Conception d'évolutivité du cluster de serveurs de stockage de données

    1. réplication (maître-esclave), partitionnement de tables et de bases de données, partage de données (Cobar)

    2 Conception évolutive de la base de données NoSQL

    NoSQL abandonne l'algèbre relationnelle et le modèle de données normalisé basé sur Structured Query Language (SQL) ne garantit pas la cohérence des transactions (ACID). Haute disponibilité et évolutivité améliorées. (Apache HBase)

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!