Maison > Article > développement back-end > Partagez les 28 dernières questions d'entretien PHP en 2023 (avec réponses)

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

青灯夜游avant: 2022-03-03 13:20:1636090parcourir

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 : 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

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

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)

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

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
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

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

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)

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

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

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
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
prevent Phantom Reading
- 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

- .
- .
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
  - 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
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

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 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 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é
- 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é
- 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

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)

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

- Pagination entre nœuds, tri, problèmes de fonction
- Cohérence des transactions
- Identifiant de clé primaire globale
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.
- 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
- - . 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.
  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)
  - 3 . Les valeurs en double sont autorisées, donc le contrôle de comparaison doit comparer non seulement la clé mais aussi la valeur
  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
  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, 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
    - 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
    - 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é
    - 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é
      - 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!

Déclaration：

Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer

Article précédent：Explication détaillée de la façon d'utiliser Trait pour résoudre un problème d'héritage unique en PHPArticle suivant：Explication détaillée de la façon d'utiliser Trait pour résoudre un problème d'héritage unique en PHP

Articles Liés

Voir plus

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

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

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

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

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

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

1. Classification du code d'état

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 :

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. Cache statique

1. Filtrer les caractères spéciaux

14. Niveau d'isolation des transactions

15. Principe de l'index

Diviser horizontalement en plusieurs tables en fonction des champs

format. (fichier binaire) :

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

Vingt. Impasse

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

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

Vingt-six problèmes et solutions courants Redis

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

Vingt-huit, communication entre Nginx et php

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

Articles Liés