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.). [Recommandation associée : didacticiel 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 technologie de récupération rapide après sinistre). , l'expansion de la capacité des données doit également être prise en compte, la sécurité des données ne sera pas perdue, etc.
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. |
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, afin de préparer une sauvegarde après sinistre, les fichiers persistants peuvent être copiés vers un emplacement distant.
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 un fichier)
Le principe est d'écrire le journal des opérations Redis dans le fichier de manière ajoutée, 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.
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 le binaire. compression pour le stocker. Le suffixe du fichier enregistré est rdb ; lorsque Redis est redémarré, le fichier instantané peut être lu pour restaurer les données.
Le déclenchement de la persistance RDB est divisé en deux types : le déclenchement manuel et le déclenchement automatique.
La commande save et la commande bgsave peuvent 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 principal Redis) continuera à traiter les requêtes.
Lors de 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é dans l’environnement en ligne.
Lorsque la persistance RDB est automatiquement déclenchée, Redis choisira également bgsave au lieu de save pour la persistance.
Défini en modifiant le fichier de configuration : enregistrer m n
La situation la plus courante de déclenchement automatique consiste à enregistrer m n dans le fichier de configuration, en spécifiant quand n changements se produisent dans les m secondes, déclencher bgsave.
[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
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 nœud maître 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.
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.
Lors de la création d'un processus enfant, le processus parent a effectué une opération fork, provoquant le blocage du processus parent. Pendant cette période, Redis n'a pu 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 temporaire Fichier d'instantané basé sur l'instantané de la mémoire du processus parent. Une fois terminé, le fichier d'origine est remplacé de manière atomique. Le processus enfant envoie un signal au processus parent pour indiquer l'achèvement et le processus parent met à jour les statistiques. Il n'y a pas d'ordres spéciaux d'exécution. 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 charge 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.Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置
[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...
由于需要记录Redis的每条写命令，因此AOF不需要触发，下面介绍AOF的执行流程。
AOF的执行流程包括：
命令追加（append）：将Redis的写命令追加到缓冲区aof_buf；
根据不同的同步策略，把aof_buf中的内容写入硬盘，并实现文件同步
文件重写（rewrite）：定期重写AOF文件，达到压缩的目的。
Redis先将命令追加到缓冲区，而不是直接写入文件，主要是为了避免每次有写命令都直接写入硬盘，导致硬盘IO称为Redis负载的瓶颈。
命令追加的格式是Redis命令请求的协议格式，它是一种纯文本格式，具有兼容性好、可读性强、容易处理、操作简单、避免二次开销等优点。在AOF文件中，除了用于指定数据库的select命令（如select 0为选中0号数据库）是由Redis添加的，其他都是客户端发送来的写命令。
Redis提供了多种AOF缓存区的同步文件策略，策略涉及到操作系统的write和fsync函数，说明如下：
为了提高文件写入效率，在现代操作系统中，当用户调用write函数将数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区被填满或超过了指定时限后，才真正将缓冲区的数据写入到硬盘里。这样的操作虽然提高了效率，但也带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失；因此系统同时提供了fsync、fdatasync等同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保数据的安全性。
AOF缓存区的同步文件策略存在三种同步方式，通过对/etc/redis/6379.conf的729行的修改进行配置。
将命令写入aof_buf后，立即进行系统fsync操作，将其同步到AOF文件，当fsync操作完成后，线程便会返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也就只能处理几万个命令，而且会大大降低SSD的寿命。
命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负载，通常同步周期为30秒。文件同步时间不可预测，并且缓冲区中的数据会堆积很多，导致数据安全性无法保障。
命令写入aof_buf后调用系统write操作，write完成后线程返回：fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，一次是Redis的默认配置，也是我们推荐的配置。
随着时间流逝，Redis服务器执行的写命令越来越多，AOF文件也会越来越大；过大的AOF文件不仅会影响服务器的正常运行，也会导致数据恢复需要的时间过长。
文件重写是指定期重写AOF文件，减小AOF文件的体积。需要注意的是，AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件；不会对旧的AOF文件进行任何读取、写入操作。
关于文件重写需要注意的另一点是：对于AOF持久化来说，文件重写虽然是强烈推荐的，但并不是必须的；即使没有文件重写，数据也可以被持久化并在Redis启动的时候导入；因此在一些现实中，会关闭自动的文件重写，然后定时任务在每天的某一时刻定时执行。
文件重写之所以能够压缩AOF文件，原因在于：
过期的数据不再写入文件。
无效的命令不再写入文件：如有些数据被重复设置（set mykey v1,set mykey v2）、有些数据被删除了（set myset v1,del myset）等。
多条命令可以合并为一个：如sadd myset v1,sadd myset v2,sadd myset v3可以合并为sadd myset v1 v2 v3。
通过上述原因可以看出，由于重写后AOF执行的命令减少了，文件重写既可以减少文件占用的空间，也可以加快恢复速度。
文件重写分为手动触发和自动触发：
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 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
文件重写的流程如下：
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重写。
关于文件重写的流程，有两点需要特别注意：
La taille actuelle du fichier AOF ( c'est-à-dire que aof_current_size ) est deux fois la taille du fichier AOF (aof_base_size) lors de la dernière réécriture du journal, l'opération bgrewriteaof se produit
auto-aof-rewrite-min-size 64mb
La valeur minimale du fichier AOF actuel pour exécuter la commande bgrewriteaof pour éviter le démarrage initial En raison de la petite taille du fichier dans Redis, bgrewriteaof
Le processus enfant ne peut partager les données de la mémoire que pendant l'opération fork. En effet, l'opération fork utilise la technologie de copie sur écriture. É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 sous-processus écrit dans le nouveau fichier AOF selon l'instantané de mémoire et les 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 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éviant le processus enfant🎜🎜🎜🎜La commande d'écriture exécutée par Redis lors de la réécriture, doit être ajouté au nouveau fichier AOF Pour cette raison, Redis introduit le cache aof_rewrite_buf 🎜🎜🎜🎜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 ; uniquement lorsque AOF Lorsqu'il est fermé, le fichier RDB sera chargé pour restaurer 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. 🎜Semblable au bgsave de RDB, la réécriture des fichiers AOF sera également confrontée aux problèmes de blocage des forks et de charge d'E/S des processus enfants. AOF écrit plus fréquemment des données sur le disque dur, ce qui aura un impact plus important sur les performances du processus principal Redis.
De 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'effectuer 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.
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!
Logiciel de base de données couramment utilisé
Que sont les bases de données en mémoire ?
Lequel a une vitesse de lecture plus rapide, mongodb ou redis ?
Comment utiliser Redis comme serveur de cache
Comment Redis résout la cohérence des données
Comment MySQL et Redis assurent-ils la cohérence des doubles écritures ?
Quelles données le cache Redis stocke-t-il généralement ?
Quels sont les 8 types de données de Redis
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
