Une explication détaillée de la haute disponibilité et de la persistance dans Redis

Cet article parlera de la haute disponibilité et de la persistance dans Redis, et examinera la fonction de persistance et deux méthodes de Redis (RDB et AOF). J'espère qu'il vous sera utile !

1. Haute disponibilité de Redis

1. Présentation de la haute disponibilité de Redis

  Dans les serveurs Web, la haute disponibilité fait référence à la durée pendant laquelle le serveur est accessible normalement, et la norme de mesure est la durée pendant laquelle il peut fournir des services normaux ( 99,9%, 99,99%, 99,999%, etc.). [Recommandations associées : Tutoriel vidéo Redis]

  Cependant, dans le contexte de Redis, la signification de la haute disponibilité semble être plus large en plus d'assurer la fourniture de services normaux (tels que la séparation maître-esclave, la reprise rapide après sinistre). technologie), la capacité des données doit également être considérée comme une expansion, la sécurité des données ne sera pas perdue, etc.

2. Stratégie de haute disponibilité Redis

Dans Redis, les technologies permettant d'atteindre la haute disponibilité incluent principalement la persistance, la séparation maître-esclave, les sentinelles et les clusters.

Stratégie de haute disponibilité	Explication
Persistance	La persistance est la méthode de haute disponibilité la plus simple (parfois même pas classée comme méthode de haute disponibilité), sa fonction principale est la sauvegarde des données, bientôt les données sont stockées sur le disque dur pour garantir que les données ne seront pas perdues à la fin du processus.
Réplication maître-esclave	La réplication maître-esclave est la base de Redis à haute disponibilité. Sentinel et Cluster atteignent tous deux une haute disponibilité basée sur la réplication maître-esclave. La réplication maître-esclave implémente principalement la sauvegarde des données sur plusieurs machines, ainsi que l'équilibrage de charge et une simple récupération des pannes pour les opérations de lecture. Défauts : la récupération après panne ne peut pas être automatisée, les opérations d'écriture ne peuvent pas être équilibrées et la capacité de stockage est limitée par une seule machine.
Sentinel	Basé sur la réplication maître-esclave, Sentinel implémente une récupération automatique des pannes. Inconvénients : les opérations d'écriture ne peuvent pas être équilibrées et la capacité de stockage est limitée par une seule machine.
Cluster	Grâce au clustering, Redis résout le problème selon lequel les opérations d'écriture ne peuvent pas être équilibrées et la capacité de stockage est limitée par une seule machine, obtenant ainsi une solution de haute disponibilité relativement complète.

2. Persistance Redis

1. Fonction de persistance Redis

  Redis est une base de données en mémoire et les données sont stockées en mémoire afin d'éviter une perte permanente de données après la fermeture anormale du processus Redis en raison de pannes de courant du serveur et autres. Pour des raisons similaires, une maintenance régulière est requise. Enregistrez les données dans Redis de la mémoire sur le disque dur sous une forme quelconque (données ou commande) ; lors du prochain redémarrage de Redis, utilisez le fichier persistant pour récupérer les données. De plus, les fichiers persistants peuvent être copiés vers un emplacement distant à des fins de sauvegarde après sinistre.

2. Deux méthodes de persistance Redis

• Persistance RDB
  Le principe est de sauvegarder régulièrement les enregistrements de la base de données Redis en mémoire sur le disque.
• Persistance AOF (ajouter uniquement le fichier)
  Le principe est d'écrire le journal des opérations Redis dans le fichier de manière annexante, similaire au binlog de MySQL.
  Étant donné que la persistance AOF offre de meilleures performances en temps réel, c'est-à-dire que moins de données sont perdues lorsque le processus se termine de manière inattendue, AOF est actuellement la méthode de persistance dominante, mais la persistance RDB a toujours sa place.

3. Persistance RDB

 La persistance RDB fait référence à la génération d'un instantané des données du processus en cours en mémoire et à son enregistrement sur le disque dur dans un intervalle de temps spécifié (on l'appelle donc également persistance d'instantané), en utilisant la compression binaire. pour stocker et enregistrer Le suffixe du fichier est rdb ; lorsque Redis redémarre, le fichier instantané peut être lu pour restaurer les données.

3.1 Conditions de déclenchement

Le déclenchement de la persistance RDB est divisé en deux types : le déclenchement manuel et le déclenchement automatique.

3.1.1 Le déclenchement manuel de la commande

• save et de la commande bgsave peut générer des fichiers RDB. La commande
• save bloquera le processus du serveur Redis jusqu'à ce que le fichier RDB soit créé. Tant que le serveur Redis est bloqué, le serveur ne peut traiter aucune demande de commande.
• La commande bgsave fork() un processus enfant, qui sera responsable de la création du fichier RDB, tandis que le processus parent (c'est-à-dire le processus Redis principal) continuera à traiter les requêtes.
• Pendant l'exécution de la commande bgsave, seul le processus enfant fork bloquera le serveur, tandis que pour la commande save, l'ensemble du processus bloquera le serveur, donc save a été fondamentalement abandonné et l'utilisation de save doit être éliminée dans l’environnement en ligne.

3.1.2 Déclenchement automatique

• Lorsque la persistance RDB est automatiquement déclenchée, Redis choisira également bgsave au lieu de sauvegarder pour la persistance.

3.2 Méthode de configuration

• Défini en modifiant le fichier de configuration : save m n
• La situation la plus courante de déclenchement automatique est de passer save m n dans le fichier de configuration, en précisant que lorsque n changements surviennent en m secondes, bgsave sera déclenché .

[root@localhost ~]# vim /etc/redis/6379.conf ##219行，以下三个save条件满足任意一个时，都会引起bgsave的调用save 900 1	##当时间到900秒时，如果redis数据发生了至少1次变化，则执行bgsavesave 300 10	##当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsavesave 60 10000	##当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave##254行，指定RDB文件名dbfilename dump.rdb##264行，指定RDB文件和AOF文件所在目录dir /var/lib/redis/6379##242行，是否开启RDB文件压缩rdbcompression yes

3.3 Autres mécanismes de déclenchement automatique

En plus de la sauvegarde m n, il existe d'autres situations qui déclencheront bgsave :

• Dans le scénario de réplication maître-esclave, si le nœud esclave effectue une opération de copie complète, le maître Le nœud exécutera la commande bgsave et enverra le fichier rdb au nœud esclave.
• Lors de l'exécution de la commande shutdown, la persistance RDB est automatiquement exécutée.

3.4 Processus d'exécution

• Le processus parent Redis détermine d'abord s'il exécute actuellement save, ou le processus enfant de bgsave/bgrewriteaof s'il est en cours d'exécution, la commande bgsave revient directement. Les sous-processus de bgsave/bgrewriteaof ne peuvent pas être exécutés en même temps, principalement pour des raisons de performances ; deux sous-processus simultanés effectuent un grand nombre d'opérations d'écriture sur disque en même temps, ce qui peut entraîner de graves problèmes de performances.
• Le processus parent effectue une opération fork pour créer un processus enfant. Au cours de ce processus, le processus parent est bloqué et Redis ne peut exécuter aucune commande du client.
• Après le fork du processus parent, la commande bgsave renvoie le message « Sauvegarde en arrière-plan démarrée » et ne bloque plus le processus parent, et peut répondre à d'autres commandes
• Le processus enfant crée un fichier RDB et génère un fichier instantané temporaire basé. sur l'instantané de mémoire du processus parent. Une fois terminé, le processus d'origine est enregistré. Il existe un fichier pour le remplacement atomique
• Le processus enfant envoie un signal au processus parent pour indiquer l'achèvement, et le processus parent met à jour les statistiques

. 3.5 Chargement au démarrage

  Le chargement des fichiers RDB s'effectue automatiquement au démarrage du serveur, et il n'y a pas de commande dédiée. Cependant, comme AOF a une priorité plus élevée, lorsque AOF est activé, Redis donnera la priorité au chargement du fichier AOF pour restaurer les données ; uniquement lorsque AOF est désactivé, le fichier RDB sera détecté au démarrage du serveur Redis et chargé automatiquement. Le serveur est bloqué lors du chargement du fichier RDB jusqu'à ce que le chargement soit terminé.
 Lorsque Redis chargera un fichier RDB, il vérifiera le fichier RDB. Si le fichier est endommagé, une erreur sera imprimée dans le journal et Redis ne pourra pas démarrer.

4. Persistance AOF

  La persistance RDB écrit les données de processus dans des fichiers, tandis que la persistance AOF enregistre chaque commande d'écriture et de suppression exécutée par Redis dans un fichier journal séparé, et les opérations de requête ne sont pas enregistrées. Lorsque Redis redémarre, exécutez la commande dans le fichier journal. Fichier AOF à nouveau pour restaurer les données.
 Par rapport à RDB, AOF a de meilleures performances en temps réel, il est donc devenu une solution de persistance grand public.

4.1 Activer AOF

Le serveur Redis active RDB par défaut et désactive AOF ; pour activer AOF, vous devez le configurer dans le fichier de configuration

[root@localhost ~]# vim /etc/redis/6379.conf ##700行，修改，开启AOFappendonly yes##704行，指定AOF文件名称appendfilename "appendonly.aof"##796行，是否忽略最后一条可能存在问题的指令aof-load-truncated yes[root@localhost ~]# /etc/init.d/redis_6379 restartStopping ...
Redis stopped
Starting Redis server...

4.2 Processus d'exécution

Étant donné que chaque commande d'écriture de Redis doit être enregistré, AOF n'a pas besoin d'être déclenché. Ce qui suit décrit le processus d'exécution d'AOF.

Le processus d'exécution d'AOF comprend :

• Command append (append) : ajoutez la commande d'écriture Redis au tampon aof_buf ;
• Écriture de fichiers (écriture) et synchronisation de fichiers (sync) : synchronisez le contenu de aof_buf sur le disque dur selon différentes stratégies de synchronisation ; réécrire (réécrire) : réécrivez régulièrement les fichiers AOF pour obtenir une compression.
• 4.2.1 Ajout de commande (append)

Redis ajoute d'abord la commande au tampon au lieu de l'écrire directement dans le fichier. Ceci est principalement pour éviter d'écrire la commande directement sur le disque dur à chaque fois qu'il y a une commande d'écriture. , ce qui fait que l'E/S du disque dur est appelée goulot d'étranglement de chargement Redis.

Le format de la commande append est le format de protocole demandé par la commande Redis. Il s'agit d'un format de texte brut et présente les avantages d'une bonne compatibilité, d'une forte lisibilité, d'un traitement facile, d'un fonctionnement simple et de l'évitement des frais généraux secondaires. Dans le fichier AOF, à l'exception de la commande select utilisée pour spécifier la base de données (comme select 0 pour sélectionner la base de données n°0), qui est ajoutée par Redis, les autres sont des commandes d'écriture envoyées par le client.

4.2.2 Écriture de fichiers (écriture) et synchronisation de fichiers (sync)

Redis fournit une variété de stratégies de fichiers de synchronisation pour la zone tampon AOF. Les stratégies impliquent les fonctions d'écriture et fsync du système d'exploitation. :

Afin d'améliorer l'efficacité de l'écriture de fichiers. Dans les systèmes d'exploitation modernes, lorsque les utilisateurs appellent la fonction d'écriture pour écrire des données dans un fichier, le système d'exploitation stocke généralement temporairement les données dans une mémoire tampon lorsque la mémoire tampon est remplie ou dépasse la limite. délai spécifié, ce n'est qu'alors que les données du tampon seront réellement écrites sur le disque dur. Bien qu'une telle opération améliore l'efficacité, elle pose également des problèmes de sécurité : si l'ordinateur s'arrête, les données dans la mémoire tampon seront perdues, le système fournit également des fonctions de synchronisation telles que fsync et fdatasync, qui peuvent forcer le système d'exploitation à le faire ; transférez immédiatement les données dans le tampon vers Les données sont écrites sur le disque dur pour assurer la sécurité des données.

4.2.3 Trois méthodes de synchronisation

La stratégie des fichiers de synchronisation de la zone de cache AOF comporte trois méthodes de synchronisation, qui sont configurées en modifiant la ligne 729 de /etc/redis/6379.conf.

4.2.3.1 appendfsync toujours

La commande appelle immédiatement l'opération fsync du système pour se synchroniser avec le fichier AOF après avoir écrit dans aof_buf. Le thread revient une fois fsync terminé. Dans ce cas, chaque commande d'écriture doit être synchronisée avec le fichier AOF et les E/S du disque dur deviennent un goulot d'étranglement des performances. Redis ne peut prendre en charge qu'environ quelques centaines d'écritures TPS, réduisant considérablement les performances de Redis même en utilisant un disque SSD ( SSD), il ne peut gérer que des dizaines de milliers de commandes par seconde, et cela réduira considérablement la durée de vie du SSD.

4.2.3.2 appendfsync no

La commande appelle l'opération d'écriture du système après avoir écrit dans aof_buf et n'effectue pas de synchronisation fsync du fichier AOF ; la synchronisation est chargée par le système d'exploitation et la période de synchronisation est généralement de 30 secondes. Dans ce cas, le temps de synchronisation des fichiers est incontrôlable, de nombreuses données s'accumuleront dans le tampon et la sécurité des données ne peut pas être garantie.

4.2.3.3 appendfsync Everysec (recommandé)

L'opération d'écriture du système est appelée une fois la commande écrite dans aof_buf. Une fois l'écriture terminée, le thread renvoie : l'opération de fichier de synchronisation fsync est appelée une fois par seconde par un thread dédié. Everysec est un compromis entre les deux stratégies susmentionnées, un équilibre entre performances et sécurité des données. C'est la configuration par défaut de Redis et notre configuration recommandée.

4.2.4 Réécriture de fichier (réécriture)

Au fil du temps, le serveur Redis exécute de plus en plus de commandes d'écriture, et le fichier AOF deviendra de plus en plus gros ; un fichier AOF trop volumineux n'affectera pas seulement le fonctionnement normal du fichier AOF ; serveur, entraînera également une récupération des données trop longue.

La réécriture de fichiers signifie réécrire régulièrement les fichiers AOF pour réduire la taille des fichiers AOF. Il convient de noter que la réécriture AOF convertit les données du processus Redis en commandes d'écriture et les synchronise avec le nouveau fichier AOF ; aucune opération de lecture ou d'écriture n'est effectuée sur l'ancien fichier AOF ;

Un autre point à noter concernant la réécriture de fichiers est : pour la persistance AOF, bien que la réécriture de fichiers soit fortement recommandée, elle n'est pas nécessaire même sans réécriture de fichiers, les données peuvent être persistantes et démarrées dans Redis. Lors de l'importation donc dans certaines réalités, réécriture automatique de fichiers ; sera désactivé, puis la tâche planifiée sera exécutée régulièrement à une certaine heure chaque jour.

4.2.4.1 Raisons d'avoir une fonction de compression

La raison pour laquelle File Rewrite peut compresser les fichiers AOF est parce que :

Les données expirées ne sont plus écrites dans le fichier.

• Les commandes invalides ne seront plus écrites dans le fichier : comme certaines données définies à plusieurs reprises (set mykey v1, set mykey v2), certaines données supprimées (set myset v1, del myset), etc.
• Plusieurs commandes peuvent être fusionnées en une seule : telles que sadd myset v1, sadd myset v2, sadd myset v3 peuvent être fusionnées dans sadd myset v1 v2 v3.
• Il ressort des raisons ci-dessus que, puisque AOF exécute moins de commandes après la réécriture, la réécriture du fichier peut non seulement réduire l'espace occupé par le fichier, mais également accélérer la vitesse de récupération.

4.2.4.2 Déclenchement de la réécriture de fichiers

La réécriture de fichiers est divisée en déclenchement manuel et déclenchement automatique :

• Déclenchement manuel : appelez directement la commande bfrewriteaof. L'exécution de cette commande est quelque peu similaire à bgsave. Les deux processus fork effectuent un travail spécifique et ne se bloquent que lors du fork.
• Déclenchement automatique : exécutez automatiquement bgrewriteaof en définissant l'option auto-aof-rewrite-min-size et l'option auto-aof-rewrite-percentage. Ce n'est que lorsque les deux options auto-aof-rewrite-min-size et auto-aof-rewrite-percentage sont satisfaites en même temps que la réécriture AOF, c'est-à-dire l'opération bgrewriteaof, sera automatiquement déclenchée.

La configuration déclenchée automatiquement se trouve aux lignes 771 et 772 de /etc/redis/6379.conf自动触发的配置位于/etc/redis/6379.conf的771行和772行

• auto-aof-rewrite-percentage 100
  当前AOF文件大小（即aof_current_size）是上次日志重写时AOF文件大小（aof_base_size）两倍时，发生bgrewriteaof操作
• auto-aof-rewrite-min-size 64mb
  当前AOF文件执行bgrewriteaof命令的最小值，避免刚开始启动Redis时由于文件尺寸较小导致频繁的bgrewriteaof

4.2.4.3 文件重写的流程

文件重写的流程如下：

• Redis父进程首先平判断当前是否存在正在执行bgsave/bgrewriteaof的子进程；如果存在则bgrewriteaof命令直接返回，如果存在bgsave命令则等bgsave执行完成后再执行。
• 父进程执行fork操作创建子进程，这个过程中父进程是阻塞的。
• 父进程fork后，bgrewriteaof命令返回“Background append only file rewrite started”信息并不再阻塞父进程，并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制的正确。
• 由于fork操作使用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令，因此Redis使用AOF重写缓冲区（aof_rewrite_buf）保存这部分数据，防止新AOF文件生成期间丢失这部分数据。也就是说，bgrewriteaof执行期间，Redis的写命令同时追加到aof_buf和aof_rewrite_buf两个缓冲区。
• 子进程根据内存快照，按照命令合并规则写入到新的AOF文件。
• 子进程写完新的AOF文件后，向父进程发信号，父进程更新统计信息，具体可以通过info persistence查看。
• 父进程把AOF重写缓冲区的数据写入到新的AOF文件，这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。
• 使用新的AOF文件替换老文件，文成AOF重写。

关于文件重写的流程，有两点需要特别注意：

auto-aof-rewrite-percentage 100
• La taille actuelle du fichier AOF (c'est-à-dire aof_current_size ) est lorsque la taille du fichier AOF (aof_base_size) a doublé lors de la dernière réécriture du journal, l'opération bgrewriteaof s'est produite
• auto-aof-rewrite-min-size 64mb
La valeur minimale pour exécuter la commande bgrewriteaof sur le fichier AOF actuel à éviter. erreurs de fichier lors du démarrage de Redis. La petite taille entraîne un bgrewriteaof

4.2.4.3 Processus de réécriture de fichiers

Le processus de réécriture de fichier est le suivant :
• Le processus parent Redis détermine d'abord s'il existe un processus enfant en cours d'exécution de bgsave/bgrewriteaof ; si il existe, bgrewriteaof La commande est renvoyée directement S'il existe une commande bgsave, elle sera exécutée une fois l'exécution de bgsave terminée.
• Le processus parent effectue une opération fork pour créer un processus enfant Au cours de ce processus, le processus parent est bloqué.

Après le fork du processus parent, la commande bgrewriteaof renvoie le message « Ajout en arrière-plan uniquement, réécriture du fichier démarrée » et ne bloque plus le processus parent et peut répondre à d'autres commandes. Toutes les commandes d'écriture Redis sont toujours écrites dans le tampon AOF et synchronisées sur le disque dur conformément à la politique appendfsync pour garantir l'exactitude du mécanisme AOF d'origine.

Étant donné que l'opération fork utilise la technologie de copie sur écriture, le processus enfant ne peut partager les données de mémoire que pendant l'opération fork. Étant donné que le processus parent répond toujours à la commande, Redis utilise le tampon de réécriture AOF (aof_rewrite_buf) pour enregistrer cette partie des données afin d'éviter que cette partie des données ne soit perdue lors de la génération du nouveau fichier AOF. En d'autres termes, lors de l'exécution de bgrewriteaof, la commande d'écriture de Redis est ajoutée simultanément aux tampons aof_buf et aof_rewrite_buf.

Le processus enfant écrit dans le nouveau fichier AOF conformément à l'instantané de mémoire et aux règles de fusion de commandes.

Une fois que le processus enfant a fini d'écrire le nouveau fichier AOF, il envoie un signal au processus parent, et le processus parent met à jour les informations statistiques, qui peuvent être consultées via la persistance des informations.

Le processus parent écrit les données du tampon de réécriture AOF dans le nouveau fichier AOF, garantissant ainsi que l'état de la base de données enregistré dans le nouveau fichier AOF est cohérent avec l'état actuel du serveur.

Remplacez l'ancien fichier par le nouveau fichier AOF et réécrivez-le dans AOF.

Concernant le processus de réécriture de fichiers, deux points nécessitent une attention particulière :

La réécriture est effectuée par le processus parent en dérivant le processus enfant

La commande d'écriture exécutée par Redis lors de la réécriture doit être ajouté à Dans le nouveau fichier AOF, Redis introduit le cache aof_rewrite_buf à cet effet

🎜4.3 Chargement au démarrage🎜🎜🎜Lorsque AOF est activé, Redis chargera d'abord le fichier AOF pour restaurer les données au démarrage ; ne peut être chargé que lorsque AOF est désactivé. Entrez le fichier RDB pour récupérer les données. 🎜🎜Lorsque AOF est activé mais que le fichier AOF n'existe pas, le fichier RDB ne sera pas chargé même s'il existe. 🎜🎜Lorsque Redis chargera un fichier AOF, il vérifiera le fichier AOF. Si le fichier est endommagé, une erreur sera imprimée dans le journal et Redis ne pourra pas démarrer. Cependant, si la fin du fichier AOF est incomplète (un temps d'arrêt soudain de la machine peut facilement rendre la fin du fichier incomplète) et que le paramètre aof_load_truncated est activé, un avertissement sera affiché dans le journal et Redis ignorera la fin du fichier AOF et démarrez avec succès. Le paramètre aof_load_truncated est activé par défaut. 🎜🎜🎜5. Avantages et inconvénients de RDB et AOF🎜🎜🎜Persistance RDB🎜🎜🎜Avantages : les fichiers RDB sont compacts, de petite taille, rapides en transmission réseau, adaptés à une vitesse de récupération complète est beaucoup plus rapide que celle d'AOF ; Bien entendu, l’un des avantages les plus importants du RDB est qu’il a un impact relativement faible sur les performances par rapport à l’AOF. 🎜 Inconvénients : L'inconvénient bien connu des fichiers RDB est que la méthode de persistance des instantanés de données détermine que la persistance en temps réel ne peut pas être obtenue. Aujourd'hui, alors que les données deviennent de plus en plus importantes, une grande quantité de données est souvent inacceptable. donc la persistance de l'AOF devient courante. De plus, les fichiers RDB doivent répondre à un format spécifique et avoir une mauvaise compatibilité (par exemple, l'ancienne version de Redis n'est pas compatible avec la nouvelle version des fichiers RDB). 🎜 Pour la persistance RDB, d'une part, le processus principal Redis sera bloqué lorsque bgsave effectue une opération fork. D'autre part, le sous-processus écrivant des données sur le disque dur entraînera également une pression d'E/S. 🎜🎜🎜Persistance AOF🎜🎜🎜Correspondant à la persistance RDB, la priorité d'AOF est de prendre en charge la persistance de deuxième niveau et une bonne compatibilité. Les inconvénients sont des fichiers volumineux, une vitesse de récupération lente et un impact important sur les performances. 🎜🎜Pour la persistance AOF, la fréquence d'écriture des données sur le disque dur est considérablement augmentée (deuxième niveau sous la politique Everysec), la pression d'E/S est plus grande et il peut même y avoir des problèmes de blocage supplémentaires dans l'AOF. 🎜🎜La réécriture des fichiers AOF est similaire à la bgsave de RDB, et il y aura des problèmes de blocage lors du fork et de la pression des E/S sur les processus enfants. Relativement parlant, étant donné qu'AOF écrit plus fréquemment des données sur le disque dur, cela aura un impact plus important sur les performances du processus principal Redis. 🎜

D'une manière générale, il est recommandé de désactiver la fonction de réécriture automatique d'AOF, de définir une tâche planifiée pour l'opération de réécriture et de l'exécuter tôt le matin lorsque le volume d'affaires est faible, afin de réduire l'impact d'AOF sur les performances du processus principal et la pression de lecture et d'écriture des IO.

Pour plus de connaissances sur la programmation, veuillez visiter : Introduction à la programmation ! !

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!