Partagez les 28 dernières questions d'entretien PHP en 2023 (avec réponses)

Cet article compile et partage 28 questions d'entretien PHP (avec réponses à partager) pour vous aider à trier les connaissances de base. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Recommandations associées : Collection de questions d'entretien PHP en 2023 (collection)

Après la nouvelle année, je prévois de rechercher de nouvelles opportunités d'emploi. J'ai constaté que ma compréhension et mon étude de nombreux entretiens de base étaient satisfaisantes. pas assez profond auparavant. Afin de m'encourager à continuer d'avancer, j'ai récemment commencé à apprendre et à résumer les connaissances pertinentes sur les forums et les moteurs de recherche. Certaines des questions sont des questions ou des réponses partagées par les seniors sur le forum, et d'autres sont des questions. J'ai rencontré lors d'entretiens récents, sur la base des miens, j'ai archivé une partie de ma compréhension et du partage des seniors, je le partage donc dans l'espoir que cela sera utile à d'autres amis, j'espère également recevoir des conseils des grands sur ce sujet. les malentendus. Je continuerai à mettre à jour dans un avenir proche

1. Principe d'implémentation sous-jacent du tableau PHP

1 L'implémentation sous-jacente se fait via une table de hachage (table de hachage) + une liste doublement chaînée (résolution des conflits de hachage)

.

• hashtable : mappage de différents mots-clés (clés) La fonction calcule la valeur de hachage (Bucket->h) et indexe directement le Bucket

• hash table enregistre le pointeur de la boucle actuelle, donc foreach est plus rapide que for

• Bucket : enregistre la clé et la somme des valeurs des éléments du tableau, ainsi que la valeur de hachage h

2. Comment assurer l'ordre

• 1. Ajoutez une table de mappage de la même taille que le tableau d'éléments de stockage entre la fonction de hachage et le tableau d'éléments (Bucket).

• 2. Utilisé pour stocker les indices des éléments dans la matrice de stockage réelle

• 3. Les éléments sont insérés dans la matrice de stockage réelle dans l'ordre de la table de mappage

• 4. La table de mappage est juste une idée de principe. En fait, il n'y a pas de table de mappage réelle. Au lieu de cela, lorsque la mémoire du bucket est allouée lors de l'initialisation, la même quantité d'espace de taille uint32_t est également allouée, puis arData est décalé vers l'emplacement où se trouve le tableau d'éléments. stockés.

3. Résolution de la duplication de hachage (méthode de liste chaînée utilisée par PHP) :

• 1. Méthode de liste chaînée : lorsque différents mots-clés pointent vers la même unité, utilisez une liste chaînée pour enregistrer le mot-clé (parcourez le liste chaînée pour correspondre à la clé)

• 2. Méthode d'adressage ouverte : Lorsque le mot-clé pointe vers une unité où des données existent déjà, continuez à rechercher d'autres unités jusqu'à ce qu'une unité disponible soit trouvée (occupant d'autres emplacements d'unités, il est plus susceptible d'avoir des conflits de hachage et de dégrader les performances)

4. Connaissances de base

• liste chaînée : file d'attente, pile, liste doublement chaînée,

• liste chaînée : élément + pointeur pointant vers l'élément suivant

• Liste doublement chaînée : pointeur pointant vers l'élément précédent + élément + pointant vers le bas Pointeur à un élément

Référence :

Un article parlant de la complexité temporelle et spatiale de l'algorithme

2. La complexité temporelle et spatiale du tri à bulles

1, implémentation du code

         $arr = [2, 4, 1, 5, 3, 6];
         for ($i = 0; $i < (count($arr)); $i++) {
             for ($j = $i + 1; $j < (count($arr)); $j++) {
                 if ($arr[$i] <= $arr[$j]) {
                     $temp = $arr[$i];
                     $arr[$i] = $arr[$j];
                     $arr[$j] = $temp;
                 }
             }
         }
     result : [6,5,4,3,2,1]

2. Principe de calcul

• Premier tour : Comparez le premier élément du tableau avec tous les autres éléments Which. L'élément est plus grand, changez l'ordre, puis faites remonter le premier élément. Un (le plus grand) élément

• Premier tour : comparez le deuxième élément du tableau avec tous les autres éléments (le premier élément le plus grand a été filtré et aucun il faut continuer à comparer), quel que soit l'élément le plus grand, changez l'ordre, faisant ainsi ressortir le deuxième plus grand élément

• ... et ainsi de suite, faisant bouillonner le tableau trié du grand au petit

Complexité temporelle moyenne : < code>O(n^2) ；O(n^2) ；

最优时间复杂度：O(n) ，需要加判断，第一次循环如果一次都没有交换就直接跳出循环

空间复杂度：O(1)，交换元素的时候的临时变量占用的空间

最优空间复杂度：O(1)

Complexité temporelle optimale : O(n) , besoin de porter un jugement S'il n'y a pas d'échange dans la première boucle, sortez de. la boucle directement

Complexité spatiale : O( 1), l'espace occupé par les variables temporaires lors de l'échange d'éléments

Complexité spatiale optimale : O(1), triée, non besoin d'échanger les positions

3. Complexité temporelle et complexité spatiale

Complexité temporelle : l'ensemble du processus est une complexité temporelle asymptotique, estimant l'efficacité du processeur (la description de la tendance d'efficacité de l'algorithme ne fait pas référence au temps spécifique utilisé par l'algorithme, car les performances des différentes machines sont incohérentes, juste une méthode générale de calcul de l'efficacité)

• Méthode de représentation : Notation Big O
  Niveau de complexité : 🎜🎜🎜🎜Ordre constant O(1)🎜

• Ordre linéaire O(n)

• ordre carré O(n²)

• ordre cubique O(n³)

• Kème ordre O(n^k)

• ordre exponentiel ( 2^ n)

• Ordre logarithmique O(logN)

• Ordre logarithmique linéaire O(nlogN)

Type de réplication temporelle :

• Meilleure complexité temporelle

• Pire complexité temporelle

• Moyenne complexité temporelle

• Complexité temporelle amortie

Complexité spatiale : complexité spatiale asymptotique complète, estimant l'utilisation de la mémoire de l'ordinateur (décrivant la tendance de l'espace de stockage occupé par l'algorithme, pas l'espace réellement occupé, comme ci-dessus)

Référence :

Un article parlant de la complexité temporelle et spatiale de l'algorithme

3. Protocole réseau à sept couches et TCP et TCP

Couche application, couche présentation, couche session, transport couche, couche réseau, couche liaison (données), couche physique

Routine mémoire :

Premier mot : la table sera transmise (réseau de chaîne d'objets)

Premier mot : couche application (nombre d'occurrences (plus, facile à retenir)

Les quatre premières directions aller : doivent être exprimées - seront transmises

Les trois dernières directions inverses : l'homophonie de l'Internet des objets est plus facile à retenir que l'Internet des objets

4. Caractéristiques et différences entre TCP et UDP

1. Ce sont tous des protocoles de couche de transport

2. TCP

• est orienté connexion, il ne peut donc être orienté que un à un

• pour la transmission de flux d'octets

  .

• les données sont fiables et ne seront pas perdues

• Communication full-duplex

3 UDP (inverse selon les caractéristiques TCP)

• Pas de connexion, prend en charge un à un, un. -à-many, plusieurs-à-many

• Orienté vers la transmission de conservation de la chaleur

• La surcharge d'en-tête est faible, les données ne sont pas nécessairement fiables mais la vitesse est plus rapide

5. Les trois- de TCP poignée de main à quatre voies et vague à quatre

1. Poignée de main à trois :

• 1) Première fois : le client envoie SYN = 1, seq = client_isn

  Fonction :

  Client : Aucun

  Serveur : Confirmez sa propre fonction de réception et la fonction d'envoi du client

• 2) Deuxième fois : Le serveur envoie SYN = 1. SEQ = Server_ISN, ACK = Client_isn +1

   :

Client : confirmant qu'il est normal pour vous-même pour envoyer et recevoir, confirmez que la réception et l'envoi du serveur sont normaux, Normal (à ce moment, le serveur ne peut pas confirmer si la réception du client est normale)

• 3) La troisième fois : le client envoie SYN = 0, ACK = server_isn+1,seq =client_isn+1

Fonction : Les deux parties se confirment La réception et la transmission sont normales, la connexion est établie

2. La première fois : le client envoie FIN

• Fonction : Indique au serveur que je n'ai aucune donnée à envoyer (mais je peux quand même recevoir des données)
  2) Deuxième fois : Le serveur envoie ACK
• Fonction : Indique au client que la demande a été reçue. Le serveur peut encore avoir des données à envoyer, donc le client entre dans l'état FIN_WAIT après l'avoir reçu et attend le serveur. Une fois la transmission des données terminée, envoyez FIN
  3) La troisième fois : le le serveur envoie FIN
• Fonction : Le serveur informe le client que j'ai fini d'envoyer et que la connexion peut être fermée.
  4) La quatrième fois : Le client envoie un ACK
• Fonction : Après avoir reçu le FIN, le client craint que le serveur ne sache pas fermer, il envoie donc un ACK, entre TIME_WAIT et attend 2MSL si aucune réponse n'est reçue. Cela prouve que le serveur a été fermé et le client ferme également la connexion à ce moment-là.
  Remarque :

Lors de la réception du message FIN de l'autre partie, cela signifie seulement que l'autre partie n'envoie plus de données mais peut toujours recevoir des données

• La raison pour laquelle vous devez attendre 2MSL dans le La fin est due au fait que le réseau n'est pas fiable. Si le serveur ne reçoit pas le dernier ACK, le serveur rejouera le paquet FIN et attendra que le client envoie à nouveau un paquet ACK avant de fermer (le client ne peut donc pas fermer la connexion immédiatement après l'envoi). le dernier ACK)
6. Code d'état HTTP

1. Classification du code d'état

- 1xx : Information, le serveur a reçu la demande et le demandeur doit continuer l'opération

• - 2xx : Succès

• - 3xx : Redirection

• - 4xx : Erreur client

• - 5xx : Erreur serveur
2, code d'état commun

200 : Demande réussie

• 301 : Redirection permanente

• 30 2 : Mobile temporaire

• 400 mauvaise requête : Erreur de syntaxe de la demande client

• 401 non autorisé : Le client n'a aucune autorisation

• 403 interdit : Le serveur rejette la demande du client

• 404 non trouvé : La ressource demandée par le client n'existe pas

• 500 Serveur interne Eerro : Erreur interne du serveur

• 502 mauvaise passerelle : lorsqu'un serveur fonctionnant comme passerelle ou proxy tente d'effectuer une requête, une réponse invalide est reçue du serveur en amont

• 503 Service indisponible, surcharge ou maintenance du système

• 504 Délai d'expiration de la passerelle : Délai d'expiration de la passerelle

Raisons et solutions pour 3 502

Cause : nginx a soumis la demande à la passerelle (php-fpm) pour gérer l'exception, ce qui entraîne

1) le paramètre de tampon fastcgi est trop petit

fastcgi_buffers 8 16k;</ code><code>fastcgi_buffers 8 16k;

fastcgi_buffer_size 32k;

2）php-cgi的进程数设置过少

查看FastCgi进程数：netstat -anpo | grep "php-cgi"| wc -l

调整参数最大子进程数：max_children

一般按照单个进程20M计算需要需要设置的子进程数

3）max_requests（内存溢出或频繁重启）

参数指明每个children最多能处理的请求数量，到达最大值之后会重启children。

设置过小可能导致频繁重启children：

php将请求轮询给每个children，在大流量的场景下，每一个children 到达最大值的时间差不多，如果设置过小可能多个children 在同一时间关闭，nginx无法将请求转发给php-fpm，cpu降低，负载变高。

设置过大可能导致内存泄露

4）php执行时间超过nginx等待时间

fastcgi_connect_timeout

fastcgi_send_timeout

fastcgi_read_timeout

5）fastcgi执行时间

max_execution_time

fastcgi_buffer_size 32k;

2) Le nombre de processus php-cgi est trop bas

Vérifiez le nombre de processus FastCgi : netstat -anpo | grep "php-cgi"| wc - l

Ajustez le nombre maximum de processus enfants : max_children

Généralement, le nombre de processus enfants qui doit être défini est calculé sur la base d'un seul processus de 20M

3) max_requests (débordement de mémoire ou redémarrages fréquents)

Le paramètre indique le nombre maximum de requêtes que chaque enfant peut gérer. Les enfants seront redémarrés après avoir atteint la valeur maximale. .

        Un réglage trop petit peut entraîner un redémarrage fréquent des enfants :   PHP interrogera la requête auprès de chaque enfant dans un scénario de trafic important, chaque enfant atteindra la valeur maximale à peu près au même moment. , plusieurs enfants peuvent être en même temps. L'heure est désactivée, nginx ne peut pas transmettre la requête à php-fpm, le processeur diminue et la charge devient élevée. 🎙                                                                                                                to read_timeout G5) Temps d'exécution Fastcgi

max_execution_time

Référence :

Compréhension approfondie de la façon d'optimiser PHP+PHP-FOM+NGINX paramètres de configuration

• Je le fais ? Partage de solutions

7. La différence entre http et HTTPS

• 1. Port : http 80 ; https : 443
  2. http est sans état, https est un protocole construit avec http + ssl qui peut effectuer une transmission cryptée
• 3. Transmission en texte brut HTTP, transmission cryptée https
  4. http est plus rapide, poignée de main à trois voies avec trois packages, https nécessite 12 packages (3 packages TCP + 9 packages de prise de contact SSL)

  8. Verrous distribués Redis et problèmes

1. Mise en œuvre :

Verrouillage : setnx

Déverrouillage : del

Délai d'expiration du verrouillage : expire

2. Problèmes possibles

1) définir nx et expirer sont non atomiques. problèmes (raccroché une fois que les paramètres sont disponibles après le verrouillage) Solution :

Redis 2.6.12 ou supérieur ajoute des paramètres facultatifs pour l'instruction SET), cela peut remplacer la commande setnx

2) D'autres verrous de processus sont. accidentellement supprimé après un délai d'attente. (L'exécution du processus A expire, provoquant la libération du verrou. À ce moment, le processus B acquiert le verrou et commence à traiter la demande. À ce moment, le processus A termine le traitement et le verrou du processus B sera supprimé par erreur) Solution : Vous ne pouvez supprimer le verrou de votre propre processus (script lua Empêcher le processus B de supprimer accidentellement le verrou du processus A après avoir acquis le verrou expiré)

3) Scénario de concurrence, le délai d'exécution du processus A provoque la libération du verrou et le processus B acquiert le verrou à ce moment-là.

Solution : démarrez le processus démon et retardez le verrouillage jusqu'à l'expiration du processus en cours.安全4) Problème de sécurité d'instance à point unique

Après l'inconvénient d'une seule machine, tous les clients ne peuvent pas obtenir de verrous :

🎜À quoi devez-vous faire attention lors de l'implémentation de verrous distribués dans Redis ? [Résumé des notes] 🎜🎜🎜🎜 vous donnera une compréhension approfondie des verrous distribués dans Redis🎜🎜🎜🎜🎜9 Pourquoi Redis est-il monothread ? Pourquoi vite ? 🎜🎜🎜🎜Lecture recommandée : https://www.php.cn/redis/475918.html🎜🎜🎜🎜10 Types de données et scénarios d'application de redis🎜🎜🎜🎜1. stockage🎜🎜🎜2, hachage :🎜🎜

Hashmap : collection d'équipe clé-valeur, stockage des informations sur l'objet

3. Liste :

Liste doublement chaînée : file d'attente de messages

4. : Calculer l'intersection, l'union, l'ensemble des différences, la valeur de déduplication

5, zset :

Ensemble ordonné sans duplication : hashMap (suppression des duplications) + table de saut de liste de sauts (ordre garanti) : Classement

Référence :

5 types de données et scénarios d'application de Redis

11. La méthode, le principe et les caractéristiques de Redis pour atteindre la persistance

1. Persistance RDB (instantané) : dans l'intervalle de temps spécifié Écrire l'instantané de la mémoire données définies sur le disque

1) Forkez un sous-processus et écrivez le contenu de l'instantané dans un fichier RDB temporaire (dump.rdb) Lorsque le sous-processus écrit le contenu de l'instantané, le nouveau fichier remplace l'ancien fichier

2. ) L'intégralité de la base de données Redis ne contient qu'un seul fichier de sauvegarde

3) Pour maximiser les performances, seul le processus enfant fork est nécessaire pour terminer le travail de persistance, réduisant ainsi les E/S du disque

4) Les temps d'arrêt avant la persistance peuvent entraîner une perte de données

2 . Persistance AOF : enregistrez toutes les opérations d'écriture et de suppression du serveur sous forme de journaux

1) Chaque fois qu'une commande d'écriture est reçue, utilisez la fonction d'écriture pour ajouter au fichier appendonly.aof

2) Le fichier persistant. deviendra de plus en plus grand, il y a beaucoup de journaux redondants (0 augmente de 100 fois à 100, 100 enregistrements de journal seront générés)

3) Différentes stratégies fsync peuvent être définies

appendfsync toutes les secondes : une fois toutes les 1 s. , jusqu'à 1 seconde de données seront perdues (par défaut)

• appendfsync toujours : Exécuté une fois pour chaque modification

• appendfsync non : Non traité

• 4) Le fichier AOF sera réécrit s'il est trop volumineux : compresse la taille du fichier AOF

fork Process, écrit le dernier état de l'objet de données local Redis dans le fichier temporaire AOF (similaire à l'instantané RDB)

• Les modifications reçues par le processus principal seront d'abord écrites dans la mémoire, puis synchronisé avec l'ancien fichier AOF (même après l'échec de la réécriture) Peut garantir l'intégrité des données)

• Une fois que le processus enfant aura terminé la réécriture, il ajoutera de manière synchrone les nouvelles modifications dans la mémoire au fichier AOF temporaire

• Le processus parent remplacera le fichier AOF temporaire par un nouveau fichier AOF et le renommera. Les nouvelles commandes reçues plus tard sont écrites dans de nouveaux fichiers
Référence :

Explication détaillée du principe de persistance de l'apprentissage en profondeur Redis

Une brève analyse de la persistance RDB et AOF, quels sont les avantages et inconvénients ? Comment choisir ?

12. Processus de conception de vente flash et difficultés

1. Cache statique

2. Équilibrage de charge nginx

Trois méthodes : sondage DNS, équilibrage de la dette IP, CDN

3, actuel. mécanisme de limitation

Méthode : limitation du courant IP, limitation du courant du jeton d'interface, limitation du courant utilisateur, jeton dynamique d'en-tête (cryptage frontal, déchiffrement back-end)

4. Verrouillage distribué

Méthode :

setnx + expire (non atomique, set garantit l'atomicité après redis2.6)

• délai d'expiration du verrouillage de libération (activer le renouvellement automatique du démon)

• verrou expiré supprimé accidentellement d'autres threads (vérification de requestId ou garantie de script lua Atomicité de la recherche + supprimer)
5. Données du cache

méthode :

Panne du cache : échauffement des données du cache + filtre Bloom/cache vide

• Avalanche du cache : paramètres du cache Délai d'expiration aléatoire pour éviter l'expiration à en même temps
6. Inventaire et commandes

déduire l'inventaire

• redis auto-diminue l'inventaire, ce qui peut conduire à des nombres négatifs dans des scénarios simultanés et affecter le retour de l'inventaire : utilisez le script Lua pour garantir l'atomicité.

  • Après que Redis retient l'inventaire, puis utilise des messages asynchrones pour créer des commandes et mettre à jour les modifications d'inventaire

  • La base de données met à jour l'inventaire à l'aide du verrouillage optimiste : où stock_num - sell_num > 0

  • Ajoutez une table d'enregistrement d'envoi de message et Mécanisme de nouvelle tentative pour éviter la perte de messages asynchrones
  Créer une commande

  • Le frontal établit une connexion Websocket ou des sondages pour surveiller l'état de la commande

    • État de l'enregistrement de vérification de la consommation pour éviter une consommation répétée

    Retour à l'entrepôt

  • Envoyer un message différé après la création d'une commande pour vérifier l'état de paiement de la commande et si l'inventaire doit être retourné à l'entrepôt

  13. Injection anti-SQL

  1. Filtrer les caractères spéciaux

  2. Filtrer le mot clé de la base de données

  3. Vérifiez le type et le format des données

  4. Utilisez le mode précompilé et liez les variables

  14. Niveau d'isolation des transactions

  1. Principe d'implémentation du niveau d'isolation SQL standard

  • Lecture non validée : d'autres transactions peuvent lire directement celles non validées. data : lecture sale

    • La transaction ne verrouille pas les données actuellement lues

    • Ajoutez des verrous partagés au niveau de la ligne au moment de la mise à jour jusqu'à ce que la transaction se termine et soit libérée

  • Commit Read : les données lues entre le début et la fin de la transaction peut être incohérent. D'autres transactions dans la transaction ont modifié les données : non-répétabilité

    • La transaction a un verrouillage partagé au niveau de la ligne sur les données en cours de lecture (quand elles sont lues), lire Libération complète

    • Ajouter un verrou exclusif au niveau de la ligne au moment de la mise à jour et libérer jusqu'à la fin de la transaction

  • Lecture répétable : les données lues avant le début et la fin de la transaction sont cohérentes, et les autres transactions de la transaction ne peuvent pas modifier les données : peuvent Lecture répétée

    • La transaction ajoute un verrou partagé au niveau de la ligne aux données actuellement lues depuis le début de la transaction

    • Ajoute un verrou exclusif au niveau de la ligne à au moment de la mise à jour et le libère à la fin de la transaction

    • D'autres transactions procèdent ensuite à la transaction. Les nouvelles données peuvent provoquer une lecture fantôme

  • Sérialisation

    • Ajouter des verrous partagés au niveau de la table lors des transactions lire les données

    • Ajouter des verrous exclusifs au niveau de la table lorsque les transactions mettent à jour les données

  2. Le niveau d'isolement des transactions et le principe de mise en œuvre d'innodb (!! Différent de ce qui précède, l'un est le niveau d'isolement et l'autre est la transaction !! améliorer la capacité de traitement simultané de la base de données

  
  Seules les opérations d'écriture seront verrouillées

  • Une donnée a plusieurs versions, chaque fois qu'une transaction met à jour les données, une nouvelle version des données sera générée. dans le journal d'annulation

    • Lorsqu'une transaction est démarrée, seuls tous les résultats de la transaction soumise peuvent être vus

    Lecture actuelle : la dernière version est lue
    Lecture instantanée : la version historique est lue
    Gap lock : Gap lock verrouillera l'index dans une plage

  • mettre à jour l'identifiant entre 10 et 20

  • La plage entière sera verrouillée, que des données existent ou non dans la plage : insérer l'identifiant = 15, sera empêché

  • Seul le niveau d'isolement de lecture répétable a un verrouillage d'espacement

    verrouillage de la touche suivante :
    Verrouillage d'enregistrement + verrouillage d'espacement sur l'enregistrement d'index (verrouillage d'espacement entre la valeur d'index et la valeur d'index précédente)
    Open et clôture

  • prevent Phantom Reading

    2) Niveau d'isolement de transaction
    • oncommitted la transaction ne verrouille pas les données actuellement lues, c'est la lecture actuelle

    Un verrou partagé au niveau de la ligne est ajouté au moment de la mise à jour et libéré à la fin de la transaction

  
  

  Commit read

  • La transaction ne verrouille pas les données en cours de lecture, il s'agit d'une lecture instantanée
    Un verrou exclusif au niveau de la ligne est ajouté au moment de la mise à jour jusqu'à ce que la transaction soit publiée

  Répétable La transaction de lecture

  • ne verrouille pas les données actuellement lues. Il s'agit d'une lecture instantanée
    • .

    transaction. Au moment où certaines données sont mises à jour, un verrou exclusif au niveau de la ligne (Record record lock, GAP gap lock, next-key) doit être ajouté, libéré à la fin de la transaction

    • .

    Le verrouillage des espaces résout le problème de lecture fantôme

  • Dans le cas de la réplication maître-esclave, s'il n'y a pas de verrouillage des espaces, les processus A et B de la bibliothèque maître

    • Un processus supprime l'identifiant < 6 ; Ensuite, il n'y a pas de commit

    • B process insert id = 3, commit

    • Un processus soumet commit

      • Dans ce scénario, il y aura un enregistrement avec id =3 dans la bibliothèque principale, mais le binlog contient La suppression d'abord, puis son ajout n'entraîneront aucune donnée dans la base de données esclave, ce qui entraînera des données incohérentes entre le maître et l'esclave

      L'instantané de MVCC résout le problème de lecture non répétable

      • sérialisation

      • lecture transactionnelle Ajouter un niveau de table lors de la récupération de données, ajouter un verrou exclusif au niveau de la table lors de la lecture en cours

      la transaction met à jour les données

  Référence :

  • Le principe de mise en œuvre du niveau d'isolation des transactions dans MySQL

    • Cet article explique en détail dans MySQL Principes des transactions et MVCC

    • Comment fonctionne l'instantané dans MVCC ?
  Qu'est-ce que MVCC et pourquoi le verrouillage d'espacement est-il conçu ?

  15. Principe de l'index

  L'index est une structure de stockage qui aide la base de données à trouver efficacement les données. Il est stocké sur le disque et nécessite des E/S de disque

  myisam prend en charge les verrous de table et. sépare les index et les données. Le stockage est adapté à la migration entre serveurs

  • innodb prend en charge les verrous de ligne, les index et le stockage de données dans un seul fichier
  2. pour des requêtes précises et une grande efficacité

  Impossible de trier, ne convient pas aux requêtes de plage

  • En cas de conflit de hachage, la liste chaînée doit être parcourue (le principe d'implémentation du tableau php et le principe d'implémentation de redis zset sont similaires)

    b-tree, b+tree
    La différence entre b-tree et b+tree
    b+tree les données sont toutes stockées dans les nœuds feuilles, et les nœuds internes stockent uniquement clés. Un disque IO peut obtenir plus de nœuds

  • b-tree Les nœuds internes et les nœuds feuilles stockent les clés et les données. Vous n'avez pas besoin de trouver des nœuds feuilles pour trouver des données. Les nœuds internes peuvent renvoyer directement des données

    • b. +tree ajoute des pointeurs des nœuds feuilles vers les nœuds adjacents pour faciliter le parcours des requêtes de retour

      • Index clusterisé et index non clusterisé

      • Concept

    Index clusterisé : l'index et les données sont stockés dans un seul nœud

  • Index non clusterisé : L'index et les données sont stockés séparément, via l'index Trouver l'adresse où les données sont réellement stockées

    • • Explication détaillée :

      • innodb utilise un index clusterisé, et l'index de clé primaire par défaut est un index clusterisé (quand il n'y a pas d'index de clé primaire, sélectionnez un index non vide, et s'il n'y a pas d'index de clé primaire implicite), l'index auxiliaire pointe vers l'emplacement de l'index clusterisé, puis trouve l'adresse de stockage réelle
    myisam utilise un index non clusterisé, tous les index ne doivent être interrogés qu'une seule fois pour trouver les données

  • Les avantages et le potentiel de l'index clusterisé

    1. L'index et les données sont ensemble, et les données de la même page seront mises en cache dans la mémoire (tampon), donc lors de la visualisation des données de la même page, il vous suffit de les retirer de la mémoire,

    • 2. Une fois les données mises à jour, il vous suffit Il est nécessaire de conserver l'index de clé primaire et l'index auxiliaire ne sera pas affecté. 3. L'index auxiliaire stocke la valeur de l'index de clé primaire et occupe plus d'espace physique. Cela sera donc affecté

                4. En utilisant un UUID aléatoire, la distribution des données est inégale, ce qui oblige l'index cluster à analyser la table entière et réduit l'efficacité, alors essayez d'utiliser l'identifiant de clé primaire à incrémentation automatique

    • 16. Partitionnement des tables (Stratégies pour les sous-bases de données

      1. Processus

      Évaluer la capacité et le nombre de sous-tables-> Sélectionner la clé de sous-table en fonction de l'entreprise-> Règles de sous-table de table (hachage, reste , plage)->Exécution-> ; Tenir compte des problèmes d'expansion

    2. Division horizontale

  Diviser horizontalement en plusieurs tables en fonction des champs

  La structure de chaque table est la même

  Le la collection de tous les sous-tableaux est la quantité complète

  • 3. Répartition verticale

  • Répartition verticale selon les champs

  • La structure du tableau est différente La même ligne associée du sous-tableau est une. données complètes

  Table étendue, champs chauds et non-fractionnement des champs chauds (fractionnement des listes et des détails)

  Lors de l'obtention de données, essayez d'éviter d'utiliser la jointure, mais combinez les résultats de deux requêtes
  • 4. Problème

  • Problème de jointure entre bases de données

  • Table globale : Scénarios où certaines tables système doivent être associées

  Méthode de redondance : Les champs communs sont redondants

  Méthode d'assemblage : Les résultats de plusieurs requêtes sont assemblées

  • • Pagination entre nœuds, tri, problèmes de fonction

    • Cohérence des transactions

    • Identifiant de clé primaire globale

  L'utilisation de uuid ->
  Utilisez l'identifiant d'incrémentation automatique distribué

  • Problème d'extension

    • Mettez à niveau la base de données esclave

    • La base de données esclave est mise à niveau vers la base de données principale Les données sont cohérentes et il vous suffit de supprimer les données redondantes.

  Double expansion : vous devez doubler la base de données esclave

  • • Migration en double écriture :

      • Les nouvelles données sont écrites en double et écrites simultanément dans la nouvelle et l'ancienne base de données

      • Les anciennes données sont copiées dans la nouvelle base de données

    L'ancienne base de données prévaudra. Vérifiez la cohérence des données et supprimez les données redondantes

    • Dix-sept, sélectionnez et mettez à jour le processus d'exécution

      • . 1. Composition MySQL

      • • Couche serveur : Connecteur->Cache->Analyzer (Préprocesseur)->Optimiseur->Exécuteur

        • Couche moteur : Interroger et stocker des données

        2, sélectionnez le processus d'exécution

        • Le client envoie une requête et établit une connexion

        • La couche serveur recherche dans le cache et renvoie directement en cas de réponse, sinon continuez

        • Analyse sept analyses des instructions SQL et prétraitement (vérifier la légalité et le type du champ, etc.)

        • L'optimiseur génère un plan d'exécution

        • L'exécuteur appelle l'API du moteur pour interroger les résultats

        • Renvoyer les résultats de la requête

        3.

        • Le pool de tampons (pool de cache) est en mémoire. La prochaine fois que vous lirez les données de la même page, vous pourrez les renvoyer directement depuis le pool de tampons (index clusterisé d'innodb)
          • Lors de la mise à jour des données, mettez à jour le tampon. pool d'abord, puis Mettre à jour le disque

          • Pages sales : Le pool de tampons dans la mémoire est mis à jour, mais le disque n'est pas mis à jour

          • Dirty brushing : Il existe un processus spécial dans inndb pour écrire les données du tampon pool sur le disque. De temps en temps, plus de données seront écrites sur le disque. Chaque modification est écrite sur le disque en même temps

          • redo log et binlog

          • redo log (redo log), unique à innodb. log, journal physique, enregistrements des modifications
            • redo log est écrit à plusieurs reprises, l'espace est fixe et il sera utilisé et l'ancien journal sera écrasé

            • binlog est un journal partagé par la couche serveur, une logique log, et la logique originale de l'instruction d'enregistrement

            • binlog est ajoutée à une certaine taille et passe à la suivante, et n'écrasera pas le journal précédent

            • redo log est principalement utilisé pour récupérer les crashs, bin. log est utilisé pour enregistrer les journaux binaires archivés

            • redo log ne peut récupérer des données que pendant une courte période de temps, binlog peut récupérer des données plus volumineuses via les paramètres

            • WAL (write-ahead-logging) écrit d'abord le schéma de journal
          • la journalisation est une IO séquentielle
            • L'écriture directe sur le disque (brossage du disque) est une IO aléatoire, car les données sont aléatoires et peuvent être distribuées dans différents secteurs

            • L'IO séquentielle est plus efficace pour écrire le journal des modifications. d'abord, ce qui peut retarder l'opportunité de vidage et améliorer le débit

            • mécanisme de vidage du journal redo, point de contrôle
          • taille du journal redo écriture fixe et cyclique
            • le journal redo est comme un cercle, avec un point de contrôle dans devant (commence à écraser l'ancien journal à ce stade), point d'écriture (position actuellement écrite) à l'arrière, point d'écriture et lorsque les points de contrôle se chevauchent, cela prouve que le journal redo est plein, et il est nécessaire de commencer à synchroniser le refaire le log sur le disque

            • Étapes d'exécution (commit en deux phases - transaction distribuée, assurant la cohérence des deux logs)

            Analyser les conditions de mise à jour et trouver les données qui doivent être mises à jour ( le cache sera utilisé)
        • le serveur appelle l'API de la couche moteur, Innodb met à jour les données dans la mémoire, puis écrit le journal redo, puis entre dans préparer
          • Notification du moteur La couche serveur commence à soumettre des données

          • La couche serveur écrit le journal binlog et appelle l'interface innodb pour émettre une demande de validation

          • La couche moteur soumet la validation après avoir reçu la demande

          • Règles de récupération en cas de crash des données après un temps d'arrêt

          • Si le statut du redo log est commit, soumettez-le directement
        • Si le statut du redo log est préparé, jugez si la transaction dans le binlog est validée, et si oui, validez-la, sinon annulez-la

          • Si vous n'utilisez pas deux cas d'erreur soumis (mettre à jour la valeur définie par table_x = 10 où valeur = 9)

          • Premier journal de rétablissement, puis écriture dans binlog
          1. Après l'écriture du journal de rétablissement, le journal de rétablissement n'était pas terminé et la machine est tombée en panne à ce moment-là. Concernant 2. Après le redémarrage, le journal redo est terminé, donc la valeur des données = 10
        • 3. Il n'y a aucun enregistrement dans le journal du journal Bin. Si vous devez restaurer les données, valeur = 9
          .
          • Écrivez d'abord le binlog avant d'écrire le Redo Log
            1 . L'écriture du binlog est terminée, mais le redo log n'est pas terminé
            2. Il n'y a pas de redo log après le redémarrage, donc la valeur est toujours 9
            3. Quand les données doivent être restaurées, le binlog est complet et la valeur est mise à jour à 10

          • undo log
            Enregistrement avant que la mise à jour ne soit écrite dans le pool de mémoire tampon

          Si une erreur se produit pendant le processus de mise à jour, revenez directement à l'état d'annulation du journal

        • • 18 Le rôle du binlog et les trois formats

          ：

          • 1. Récupération de données
          2. Réplication maître-esclave

        format. (fichier binaire) :

        1) instruction

        1 Enregistrez le texte original de chaque instruction SQL

        .

      • 2. Pour supprimer une table, il vous suffit d'enregistrer une instruction SQL, et il n'est pas nécessaire d'enregistrer les modifications dans chaque ligne, ce qui permet d'économiser les E/S, d'améliorer les performances et de réduire la quantité de journaux

      • 3. -une incohérence d'esclave peut survenir (procédures stockées, fonctions, etc.)

      • 4. Niveau d'isolement RC (commission de lecture), car l'ordre d'enregistrement du journal binaire est enregistré dans l'ordre de validation de la transaction, cela peut entraîner une incohérence dans le maître-esclave. réplication. Ce problème peut être résolu en introduisant des verrous d'espacement au niveau de lecture répétable.

      2) ligne

      • 1. Enregistrez la modification de chaque enregistrement, sans enregistrer l'enregistrement contextuel de l'instruction SQL

      • 2. Il en résulte une grande quantité de journaux binlog

      • 3. un tableau : Enregistrez la situation de chaque enregistrement en cours de suppression

      3) mixte

      • 1. Une version mixte des deux premiers formats

      • 2. Choisissez automatiquement celui à utiliser en fonction de la déclaration :

        .

        • Général Pour modifier l'instruction SQL, utilisez l'instruction

        • pour modifier la structure de la table, la fonction, la procédure stockée et d'autres opérations. Sélectionnez la ligne

        • Toutes les modifications enregistrées seront toujours enregistrées

        .

      19. Synchronisation maître-esclave (Les principes et problèmes de la réplication maître-esclave) et séparation lecture-écriture

      1 Problèmes résolus

      • Distribution des données

      • Équilibrage de charge

      • .

        Sauvegarde des données, haute disponibilité, évitez les points de défaillance uniques

      • Réalisez la séparation lecture-écriture et soulagez la pression de la base de données

      • Test de mise à niveau (utilisez une version supérieure de MySQL comme bibliothèque esclave)

      2. Types de réplication pris en charge (trois formats de binlog)

      • Basé sur SQL Réplication des instructions

      • Réplication basée sur les lignes

      • Réplication hybride

      3. Principe

      1) Concepts de base

      • Générer deux threads à partir de la bibliothèque

        • Thème d'E/S

        • Thème SQL

      • Thème de génération de la bibliothèque principale

        • fil de démonstration du journal

      2) Processus ( le nœud maître doit activer la fonction bin log,)

      • 1 .from Une fois que le nœud a lancé la commande start slave, créez un processus IO pour vous connecter au nœud maître

      • 2. Le nœud maître crée un thread de vidage de journal (le nœud maître créera un thread de vidage de journal pour chaque nœud esclave)

      • 3. Lorsque le journal binlog change, le thread de journal de vidage du nœud maître lira le contenu du journal bin et l'enverra à. le nœud esclave

      • 4. Lorsque le thread de journalisation de vidage du nœud maître lit le contenu du journal bin, il l'enverra au nœud maître. Le journal bin est verrouillé et le verrou est libéré avant l'envoi au nœud esclave après. la lecture est terminée

      • 5. Le thread IO du nœud esclave reçoit le contenu du binlog envoyé par le nœud maître et l'écrit dans le fichier journal du relais local

      • 6. position de synchronisation via le fichier binlog + décalage de position. Le nœud esclave enregistrera le décalage de position reçu. Si le nœud esclave tombe en panne et redémarre, il lancera automatiquement la synchronisation à partir de la position de position

      • 7. le journal de relais local à partir du thread SQL du nœud, analysez-le en opérations spécifiques et exécutez-les pour assurer la cohérence des données maître-esclave

      4. Mode de réplication maître-esclave

      1) Mode asynchrone (mode par défaut)

      • 1. Peut entraîner une incohérence maître-esclave (délai maître-esclave)

      • 2. Une fois que le nœud maître a reçu la transaction soumise par le client, il soumet directement la transaction et la renvoie au client

      .

      • 3. Si après la soumission de la transaction du nœud maître, le vidage du journal plante avant qu'il n'ait le temps d'être écrit, cela entraînera une incohérence des données maître-esclave

      • 4. concernant l'opération de synchronisation maître-esclave, les performances sont les meilleures

      2) Mode de synchronisation complète

      • 1. Cela affectera le temps de réponse de la bibliothèque principale

      • 2. Le nœud reçoit la transaction soumise par le client, il doit attendre que le binlog soit envoyé à la bibliothèque esclave et que toutes les bibliothèques esclaves aient été exécutées. La transaction n'est renvoyée au client qu'après

      3) Mode semi-synchrone.

      • 1. Augmentez une partie de la fiabilité et augmentez une partie du temps de réponse de la base de données principale

      • 2 Une fois que le nœud maître a reçu la transaction soumise par le client, attendez que le binlog soit envoyé au moins. une bibliothèque esclave et enregistrée avec succès dans le journal du relais local. À ce moment, la bibliothèque principale soumet la transaction et la renvoie au client

      4) Configuration de l'identifiant du serveur et du serveur-uuid

      • 1. id est utilisé pour identifier l'instance de base de données afin d'éviter les boucles infinies d'instructions SQL dans les topologies maître-esclave et multi-maître-esclave chaînées

      • 2. La valeur par défaut de l'identifiant du serveur est 0 et les journaux binaires seront toujours enregistrés. pour l'hôte, mais toutes les connexions esclaves seront rejetées.

      • 2. server-id = 0 refusera de se connecter à d'autres instances car l'esclave

      • 3 est une variable globale, et le service doit être redémarré après modification

      • 4. library Quand il est identique à l'identifiant du serveur de la bibliothèque esclave

        • L'id par défaut de réplication-same-server-id = 0, la bibliothèque esclave ignorera toutes les données de synchronisation maître-esclave, ce qui entraînera une incohérence des données maître-esclave

        • replicate-same-server-id = 1, ce qui peut entraînera l'exécution d'une boucle sans fil sql

      • La duplication des identifiants de serveur dans deux bibliothèques esclaves (B, C) entraînera une connexion maître-esclave anormale et la connexion sera interrompue par intermittence

        • avant le la bibliothèque principale (A) trouve le même identifiant de serveur et sera déconnectée La connexion, réenregistrez une nouvelle connexion

        • La connexion des bibliothèques esclaves B et C sera reconnectée encore et encore

      • Service MySQL créera et générera automatiquement la configuration serveur-uuid

        • Si lors de la synchronisation maître-esclave Si le serveur-uuid de l'instance maître-esclave est le même, une erreur sera signalée et quittée, mais nous pouvons éviter l'erreur en définissant replicate-same-server-id=1 (non recommandé)

      5. Séparation lecture-écriture

      1) Basée sur l'implémentation du code, réduisant les dépenses matérielles

      2) Basée sur l'implémentation d'un proxy intermédiaire

      3) Délai maître-esclave

      • Les performances de la bibliothèque esclave sont pires que celles de la bibliothèque principale

      • Un grand nombre de requêtes entraîne une forte pression sur la bibliothèque esclave et consomme beaucoup de ressources CPU, affectant la vitesse de synchronisation : un maître et plusieurs esclaves

      • Exécution de transactions importantes : le journal binaire ne sera pas écrit tant que la transaction n'est pas exécutée, et le délai de lecture de la bibliothèque esclave

      • bibliothèque principale ddl (modifier, supprimer, créer)

      Vingt. Impasse

      1. Quatre conditions nécessaires à sa survenance

      • 1 Conditions d'exclusion mutuelle

      • 2.

      • 3. Condition de non-privation : Lorsque le processus obtient des ressources et attend d'autres ressources, il libère les ressources occupées

      • 4 Condition d'attente de boucle :
        Compréhension : Une ressource ne peut être occupée que par un seul processus. , et le processus obtient la ressource. Vous pouvez également demander de nouvelles ressources, et les ressources qui ont été obtenues ne peuvent pas être privées en même temps, plusieurs processus s'attendent pour les ressources occupées par d'autres processus

      . 2. Libérez l'impasse

      • 1. Terminez les processus (tuez-les tous) )

      • 2. Plantez un par un (tuez-en un pour voir s'il est soulagé)

      21. Mysql optimise en grand limite de requête de pagination 100000 (offset), 10 (page_sie)

      1. Raison

      Lorsque MySQL interroge les données de pagination, il n'ignore pas directement le décalage (100000), mais prend offset + page_size = 100000 + 10 = 100010 morceaux de données, puis supprime les 100 000 premiers éléments de données, donc l'efficacité est faible

      2 Plan d'optimisation

      • Association retardée : utilisation de l'index de couverture

      • Méthode de seuil de clé primaire : lorsque la clé primaire est automatique. -incrémenté, les valeurs maximales et minimales de la clé primaire qui remplissent les conditions sont calculées via des conditions (en utilisant l'index de couverture)

      • enregistrer la position du résultat sur la page précédente, éviter d'utiliser OFFSET

      Vingt-deux, cache redis et cohérence des données mysql

      Méthode :

      1. Mettez d'abord à jour redis, puis mettez à jour la base de données
      Scénario : mettre à jour la valeur définie = 10 où valeur = 9
      　1) la mise à jour redis est réussie : valeur redis = 10
      　2) La mise à jour de la base de données échoue : valeur mysql = 9
      　3) les données sont incohérentes
      2 Mettez d'abord à jour la base de données, puis mettez à jour redis
      Scénario : A La mise à jour du processus définit la valeur = 10 où la valeur = 9. set value = 11 où value = 9 ;
      　1) Le processus A met d'abord à jour la base de données, mais n'a pas encore écrit dans le cache : valeur mysql = 10 ; valeur redis = 9
      2) Le processus B met à jour la base de données et soumet le transaction, et écrit le cache : valeur mysql = 11 ; valeur redis = 11 ;
      　3) Le processus A termine la requête et soumet la transaction, écrit le cache : valeur redis = 10 ; valeur redis = 10
      3. Supprimez d'abord le cache, puis mettez à jour la base de données
      Scénario : Un processus met à jour la valeur définie = 10 où la valeur = 9 ; le processus B interroge la valeur ;
      1) Un processus supprime d'abord le cache, puis met à jour la base de données Il n'y a pas eu le temps de modifier les données ou la transaction n'a pas été soumise
      2) Le processus B a commencé à interroger et n'a pas atteint le cache, il a donc vérifié la base de données et l'a écrite dans le cache valeur redis = 9
      3) Le processus A a mis à jour la base de données pour terminer la valeur mysql = 10
      4) Enfin la valeur mysql = 10 ; la valeur redis = 9

      Solution :

      1. Double suppression retardée

      Scénario : Une mise à jour de processus définit la valeur =. 10 où valeur = 9 ; valeur de requête du processus B ;
      1) A Le processus supprime d'abord le cache et n'a pas eu le temps de modifier les données ou la transaction n'a pas été soumise
      2) Le processus B commence à interroger et ne le fait pas appuyez sur le cache, il vérifie donc la base de données et écrit dans le cache valeur redis = 9
      3) Le processus A termine la mise à jour de la base de données valeur mysql = 10
      4) Le processus A estime le temps de retard et supprime à nouveau le cache après le sommeil
      5) Enfin la valeur mysql = 10 ; la valeur redis est vide (vérifiez directement la base de données la prochaine fois)

      原 6) Raisons du retard pour empêcher le processus B du processus B du processus B. ) Lorsque le cache n'existe pas et que la base de données doit être vérifiée, la clé sera stockée dans la file d'attente de mise à jour

      3) Si un une nouvelle demande arrive avant que la requête ne soit terminée et que la clé existe toujours dans la file d'attente de mise à jour, la clé sera placée dans la file d'attente des requêtes et attendra. Si elle n'existe pas, répétez la deuxième étape
      4) Si les données interrogées constatent que la file d'attente des requêtes existe déjà, il n'est pas nécessaire d'écrire à nouveau dans la file d'attente
      5) Une fois la mise à jour des données terminée, rpop met à jour la file d'attente, et en même temps, rpop interroge la file d'attente et libère la requête request
      6 ) Les requêtes de requête peuvent utiliser while + sleep pour interroger le cache et définir le délai maximum. Si elle n'est pas terminée, elle retournera vide
      Vingt-trois, connectez-vous et pconnect dans redis

      1. : Libérez la connexion après la fin du script

      1 . close : Libérez la connexion

      2 pconnect (connexion longue) : La connexion n'est pas libérée à la fin du script, et la connexion reste dans le processus php-fpm. son cycle de vie suit le cycle de vie du processus php-fpm

      1 close La connexion n'est pas libérée
      C'est juste que redis ne peut pas être demandé à nouveau dans le processus php-cgi actuel

      • Suivant. les connexions dans le php-cgi actuel peuvent toujours être réutilisées jusqu'à ce que php-fpm termine le cycle de vie

        • 2 Réduisez la consommation d'établissement de connexions Redis

        3. -fpm

      • 4. Consomme plus de mémoire et le nombre de connexions continue d'augmenter

      • 5 Le même php-fpm La requête précédente du sous-processus de travail (php-cgi) peut affecter la requête suivante.
      3. Le problème de réutilisation de la connexion de pconnect

      Variable A select db 1 ;

      24. Le principe de l'utilisation de skiplist pour la collection ordonnée redis zset

      1 Concept de base

      • 1. Skiplist est une donnée aléatoire qui stocke les éléments dans une liste chaînée hiérarchique de manière ordonnée (ne peut être utilisée que lorsque les éléments. sont ordonnés)

      2. Skiplist a évolué en fonction de listes chaînées ordonnées et de listes chaînées multicouches

      • 3 . Les valeurs en double sont autorisées, donc le contrôle de comparaison doit comparer non seulement la clé mais aussi la valeur

      4. Chacun. le nœud a un pointeur arrière d'une hauteur de 1, qui est utilisé pour l'itération de la direction de la tête à la direction de la queue

      5. Complexité temporelle O(logn), complexité spatiale O(n)

      2, comparaison entre la table de saut et arbre équilibré

      1) Efficacité de la requête de plage

      La requête de plage de table de saut est plus efficace car la valeur minimale est trouvée. Après cela, il vous suffit de parcourir la liste chaînée de premier niveau jusqu'à ce qu'elle soit inférieure au maximum value

      La requête d'arbre équilibré trouve la valeur minimale, puis effectue un parcours dans l'ordre pour trouver d'autres nœuds qui ne dépassent pas la valeur maximale

      2) Mémoire occupant

      skiplist, le nombre de les pointeurs pour chaque nœud sont 1/(1-p)
      Le nombre de pointeurs pour chaque nœud de l'arbre équilibré est 2
      3) Opérations d'insertion et de suppression
      skiplist Il vous suffit de modifier le pointeurs des nœuds adjacents
      Les modifications dans l'arborescence équilibrée entraîneront des ajustements au sous-arbre
      25. Mécanisme de suppression et d'élimination expiré de Redis
      1) Stratégie de suppression conventionnelle expirée

      • 1) Suppression programmée

      • .

        Supprimer immédiatement lorsqu'il expire via une minuterie

      La mémoire est libérée dans le temps mais consomme plus de CPU En cas de concurrence importante, les ressources CPU sont consommées et la vitesse de traitement des requêtes est affectée

      Convivial pour la mémoire. CPU peu convivial

      2) Suppression paresseuse
      Ignorez les clés expirées, vérifiez si elles ont expiré et supprimez-les la prochaine fois que vous devrez les retirer
      Il peut y avoir un grand nombre de clés expirées qui ne sera pas utilisé, provoquant un débordement de mémoire
      Mémoire non conviviale, conviviale pour le processeur
      3) Suppression régulière
      Vérifiez de temps en temps, supprimez les clés expirées
      Combien supprimer et comment les choses à vérifier sont déterminées par un algorithme

      2, la suppression paresseuse + la suppression régulière adoptée par redis

      • Testez périodiquement et au hasard certaines clés avec un délai d'expiration défini pour l'inspection et supprimez-les lorsqu'elles expirent

      • Le temps de chaque nettoyage ne dépasse pas 25% du CPU, et le temps est atteint Puis quittez le contrôle

      Il n'y a pas de clés supprimées de manière régulière, et les clés qui ne seront pas utilisées à l'avenir le seront toujours existent dans la mémoire, vous devez donc coopérer avec la stratégie d'élimination

      • 3. Stratégie d'élimination (la mémoire n'est pas suffisante pour écrire de nouvelles données au moment de l'exécution)

        • volatile-lru : Le délai d'expiration est défini et moins il est utilisé récemment, la priorité sera éliminée

        • volatile-ttl : Le délai d'expiration est défini, et plus le délai d'expiration est précoce, la priorité sera éliminée

        • volatile-random : L'expiration est définie Supprimer aléatoirement dans le temps

        • allkeys-lru : Plus le délai d'expiration de toutes les clés est précoce, la priorité sera éliminée

        • allkeys-random : Toutes les clés seront aléatoires éliminé après l'expiration

        • no-enviction : L'élimination n'est pas autorisée, mémoire insuffisante Rapport d'erreurs

        Vingt-six problèmes et solutions courants Redis

        1 Avalanche de cache : Un grand nombre de pannes de cache en même temps. temps, provoquant des requêtes d'interrogation directe de la base de données, augmentant la mémoire de la base de données et la pression du processeur et même les temps d'arrêt. nombres aléatoires au temps de cache pour éviter qu'un grand nombre de caches ne s'invalident en même temps

        Faites un cache de deuxième niveau ou un double cache, A est le cache d'origine court en termes de rapidité, B est le cache de sauvegarde, qui est valable pour longtemps. Cache à double écriture lors de la mise à jour

        2. Pénétration du cache : il n'y a aucune donnée dans le cache et la base de données. Sous un grand nombre de requêtes, toutes les requêtes pénètrent directement dans la base de données, provoquant des temps d'arrêt.

        • Solution :

        • Filtre Bloom : composé d'un vecteur de bits ou d'une liste de bits de longueur m (une liste contenant uniquement des valeurs de 0 ou 1 bit)

        Utilisez plusieurs fonctions de hachage différentes pour générer plusieurs valeurs d'index , remplissez la valeur correspondant à plusieurs positions est 1

        Le filtre Bloom peut vérifier si la valeur est "peut-être dans l'ensemble" ou "certainement pas dans l'ensemble"

        • Il peut être mal jugé mais le filtrage de base l'efficacité est élevée

          • Dans les cas extrêmes, lorsqu'il n'y a pas d'espace libre dans le filtre Bloom, chaque requête renvoie vrai
          • Cache vide (court terme)

          • Filtrage des paramètres de la couche métier

        3. Cache hit Wear : il y a des données dans la base de données, mais un grand nombre de requêtes ont eu lieu après l'échec soudain du cache, ce qui a augmenté la pression sur la base de données et a même provoqué des temps d'arrêt

        • Solution :

        • données chaudes n'expire jamais

        Verrou Mutex : quel que soit le succès après l'acquisition du verrou Dans tous les cas, le verrou doit être libéré

        Vingt-sept Explication détaillée et cycle de vie de php-fpm
        1.

        • 1) Protocole CGI

        Le fichier de code du langage dynamique doit transmettre le correspondant L'analyseur peut être reconnu par le serveur

        Le protocole CGI est utilisé pour permettre au serveur et à l'interprète de communiquer entre eux autre

        Le serveur a besoin de l'interpréteur PHP ainsi que du protocole CGI correspondant pour analyser le fichier PHP

        • 2) Programme CGI = php-cgi

        • php-cgi est un programme CGI conforme au CGI. protocol

        • et est également un interpréteur PHP
        Standard CGI analysera php.ini pour chaque requête, initialisera l'environnement d'exécution, etc., réduisant les performances

        • Chaque fois que vous modifiez la configuration, vous devez re-php-cgi pour que php.ini prenne effet

        • Vous ne pouvez pas planifier dynamiquement les travailleurs, vous ne pouvez spécifier que le nombre de travailleurs au début

        • 3) Protocole FastCGI

        • C'est aussi un protocole /standard comme CGI, mais il est optimisé sur la base de CGI et est plus efficace. Il est utilisé pour améliorer les performances des programmes CGI. 4) Programme FastCGI = php-fpm

        • . php-fpm est un programme FastCGI conforme au protocole FastCGI
        Mode de gestion du programme FastCGI pour les programmes CGI

        • Démarrez un processus maître, analysez le fichier de configuration et initialisez l'environnement

        • Démarrez plusieurs sous-travailleurs -processes

        • Après avoir reçu la demande, transmettez-la au processus de travail pour exécution
        • Résolvez le problème du redémarrage en douceur après la modification de php.ini

        • process_control_timeout : le sous-processus accepte le processus principal signal de réutilisation Le délai d'attente (traiter la requête dans le délai spécifié et l'ignorer si elle ne peut pas être terminée)
          • Définir le temps que php-fpm laisse au processus fastcgi pour répondre au signal de redémarrage

          • process_control_timeout = 0, ce qui signifie qu'il ne prend pas effet et ne peut pas assurer un redémarrage en douceur

          • un paramètre process_control_timeout trop grand peut provoquer une congestion des requêtes système

          process_control_timeout = 10, si la logique du code prend 11 s, le redémarrage de l'ancien peut provoquer l'exécution du code partie pour quitter

        • Valeur recommandée : request_terminate_timeout

          • Type de redémarrage

          • Redémarrage progressif

          • Redémarrage forcé

          2. Cycle de vie de php-fpm : à mettre à jour

          • Cycle de vie PHP-FPM : https://www.abelzhou.com/php/php-fpm-lifespan/#

            Référence :

            Parlons du mécanisme de communication entre PHP-FPM et Nginx

            Une brève analyse Plusieurs configurations de délai d'attente dans le fichier de configuration PHP

            Parlons du redémarrage en douceur de nginx et du redémarrage en douceur de FPM

            Vingt-huit, communication entre Nginx et php

            1 Méthode de communication : fastcgi_pass

            . 1 )socket TCP

            • Cross-serveur, lorsque nginx et php ne sont pas sur la même machine, vous ne pouvez utiliser que cette méthode

            • Protocole orienté connexion pour mieux garantir l'exactitude et l'intégrité de la communication

            2) Unix Socket

            • ne nécessite pas de pile de protocole réseau, d'emballage et de déballage, etc.

            • réduit la surcharge TCP et est plus efficace que le socket TCP

            • Il est instable lorsque la concurrence est élevée et le une augmentation soudaine du nombre de connexions génère un grand nombre de caches à long terme. Les gros paquets de données peuvent directement renvoyer des exceptions

            Référence :

            Parlons du mécanisme de communication entre PHP-FPM et Nginx

            Cet article analyse brièvement le mécanisme de communication entre Nginx et php-fpm

            Vingt-neuf, vulnérabilités et problèmes Web

            1 injection SQL

            2. ](https://tech.meituan.com/2018/09/27/fe-security.html)

            3. Attaques CSRF :

            Lecture recommandée : [Série sur la sécurité frontale (2) : Comment empêcher les attaques CSRF ? ](https://tech.meituan.com/2018/10/11/fe-security-csrf.html)

            4. Vulnérabilité de téléchargement de fichiers

            Lecture recommandée : [Une brève analyse des vulnérabilités de téléchargement de fichiers]( https://xz.aliyun.com/t/7365)

            5. Problèmes inter-domaines :

            1) jsonp

            2) cors
            3) proxy nginx
            Apprentissage recommandé : "

            Vidéo PHP Tutoriel

            "

  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!