table des matières
1. Qu'est-ce que la communication inter-processus?
Troisièmement, le partage de mémoire locale
Quatre, message / file d'attente local
Six, file d'attente de messages
7.1 Quelles sont les méthodes de communication inter-processus?
1. Qu'est-ce que la communication inter-processus?
Communication de processus intermédiaire (IPC). La soi-disant communication est l'échange de données. Par conséquent, au sens strict, les processus créés par le système d'exploitation échangent des données.
Aujourd'hui, nous ne discutons pas seulement de la communication au sens étroit, mais aussi de la signification plus large de la communication IPC entre les programmes.
Un programme peut être un processus, cela peut être un thread, cela peut être deux parties d'un processus (le processus lui-même s'envoie), ou il peut être distribué - en bref, nous discutons aujourd'hui de l'échange de données dans un large contexte. sens .
Deuxièmement, le pipeline
Les pipelines offrent une capacité très importante, qui consiste à organiser les calculs. Le processus n'a pas besoin de savoir qu'il y a un tuyau, donc la conception du tuyau est non intrusive. Le programmeur peut d'abord se concentrer sur la conception du programme lui-même, et n'a besoin que de réserver l'interface du pipeline de réponse pour utiliser les capacités du pipeline. Par exemple, pour shellexécuter une instruction MySQL, cela peut être comme ceci:
进程1 | 进程2 | 进程3 | mysql -u... -p | 爬虫进程Nous pouvons calculer les instructions requises par MySQL à partir des processus 1, 2 et 3, puis les exécuter directement via le pipeline. MySQL transmet le résultat à un processus de robot après le calcul, et le robot commence à fonctionner. MySQL n'est pas conçu pour être utilisé dans les pipelines, et le processus du robot d'exploration n'est pas conçu pour être spécifiquement utilisé dans les pipelines. C'est juste que les programmeurs trouvent qu'il peut être utilisé de cette manière, ce qui résout parfaitement leurs propres problèmes, tels que construire un micro robot avec des pipelines et stocker les résultats dans la base de données .
Nous avons également appris un mot appelé tube nommé . Les tuyaux nommés n'ont pas changé l'utilisation des tuyaux. Par rapport aux canaux anonymes, les canaux nommés fournissent plus de méthodes de programmation. tel que:
-
进程1 > namedpipe -
进程2 > namedpipe
Le programme ci-dessus redirige les résultats temporaires des deux processus vers namedpipe en même temps, ce qui équivaut à fusionner le contenu et à chercher une chance de le traiter. Pour un autre exemple, si votre processus a besoin d'interroger en permanence le MySQL local, vous pouvez également envisager d'utiliser un tube nommé pour transmettre la requête à MySQL, puis d'utiliser un autre tube nommé pour le renvoyer.
Cela élimine le besoin d'établir un temps de prise de contact à 3 voies localhost et TCP . Bien sûr, les bases de données sont toutes distantes maintenant, voici juste un exemple.
Le cœur du pipeline est non intrusif, flexible, n'augmente pas le fardeau de la conception du programme et peut organiser des processus de calcul complexes.
Troisièmement, le partage de mémoire locale
Plusieurs threads du même processus partagent eux-mêmes la mémoire de processus. Dans ce cas, il n'est pas nécessaire de considérer particulièrement la mémoire partagée. S'il s'agit d'un thread inter-processus (ou compris comme un programme inter-processus), vous pouvez envisager d'utiliser la mémoire partagée. Le partage de mémoire est une capacité fournie par les systèmes d'exploitation modernes.Les systèmes d'exploitation Unix, y compris Linux, ont une bibliothèque partagée de mémoire POSIX-shmem. (Si vous êtes intéressé, vous pouvez vous référer au contenu de la page Web )
Le principe des bibliothèques partagées La mémoire Linux se présente sous la forme d'un système de fichiers virtuel , divisé en une zone de mémoire, couramment utilisée pour les deux processus. Cela ressemble à un fichier, mais l'opération réelle est la mémoire.
La méthode de mémoire partagée est très rapide, mais le programme n'est pas très facile à écrire, car il s'agit d'un développement intrusif , ce qui signifie que vous devez écrire beaucoup de programmes pour cela. Par exemple, si vous modifiez la valeur dans la mémoire partagée, vous devez appeler l'API. Si vous envisagez un contrôle d'accès concurrentiel , vous devez également gérer les problèmes de synchronisation .
Par conséquent, tant qu'il ne s'agit pas d'un scénario hautes performances, la communication inter-processus ne prend généralement pas en compte le mode de mémoire partagée.
Quatre, message / file d'attente local
Le partage de mémoire n'est pas facile à utiliser, il existe donc deux méthodes courantes pour la messagerie locale. La première consiste à utiliser des files d'attente de messages - les systèmes d'exploitation modernes offriront des capacités similaires. Le système Unix peut utiliser mqueue standard POSIX. Une autre façon consiste à utiliser directement la requête réseau, comme le protocole TCP / IP, mais également à inclure plus de protocoles de communication construits dessus
Essentiellement, ce sont tous les modes de réception / envoi de messages. Le processus encapsule les données qui doivent être transférées dans un message avec un certain format, ce qui est très utile pour écrire des programmes. Les programmeurs peuvent répondre à des messages dans différentes catégories selon le type de message; ils peuvent également déclencher des opérations logiques spéciales en fonction du contenu du message. Dans le cas d'un volume de messages important, il est également possible de construire une file d'attente de producteur et une file d'attente de consommateur, et d'utiliser la technologie simultanée pour le traitement.
Cinq, appel à distance
L'appel de procédure à distance (RPC) est une méthode d'encapsulation des demandes de service à distance via des appels de procédure locale .
RPC appelle la méthode (service) d'une autre machine (serveur) à partir d'une machine (client) via le passage de paramètres et renvoie le résultat.
Lorsqu'un programmeur appelle un RPC, le programme semble appeler une méthode locale ou effectuer une tâche locale, mais il y aura un programme de service (généralement appelé un stub) plus tard pour convertir cet appel local en une demande de réseau distant. De la même manière, une fois que le serveur a reçu la demande, il y aura également un programme serveur (stub) qui convertit la demande en un véritable appel de méthode serveur.
Vous pouvez observer l'image ci-dessus, qui montre le processus de communication entre le client et le serveur. Il y a un total de 10 étapes, à savoir:
-
Fonction d'appel client (méthode);
-
Le stub encapsule l'appel de fonction en tant que demande;
-
Le socket client envoie la demande et le socket serveur reçoit la demande;
-
Le stub de serveur traite la demande et restaure la demande en un appel de fonction;
-
Exécuter des méthodes côté serveur;
-
Renvoie le résultat dans le stub;
-
Le stub encapsule le résultat de retour en tant que données de retour;
-
Le socket serveur envoie les données de retour et le socket client reçoit les données de retour;
-
Le socket client transmet les données au stub client;
-
Le stub client échappe les données renvoyées dans la valeur de retour de la fonction.
Il existe de nombreuses conventions dans le processus d'appel RPC, telles que
- Format des paramètres de fonction
- Renvoyer le format du résultat
- Comment gérer l'exception
- Il existe de nombreux problèmes très précis
- Tels que la gestion des paquets persistants TCP, la gestion des exceptions réseau et la sélection du mode d'E / S
Les problèmes ci-dessus sont plus difficiles, donc la pratique habituelle dans le combat réel est d'utiliser un cadre.
- Cadre Thrift (Facebook open source)
- Cadre Dubbo (Ali open source)
- grpc (Google open source)
Ces frameworks RPC prennent généralement en charge plusieurs langues, ce qui nécessite un langage de définition d'interface pour prendre en charge la définition d'interfaces (IDL) entre plusieurs langues.
La méthode d'appel RPC est plus appropriée pour le développement d'un environnement de microservices. Bien sûr, RPC nécessite généralement une structure d'équipe professionnelle pour prendre en charge les scénarios à forte concurrence et à faible latence. Cependant, il est vrai que RPC a une surcharge de conversion de données supplémentaire (principalement la sérialisation), mais ce n'est pas le principal inconvénient de RPC.
Le vrai défaut du RPC est qu'il augmente le couplage entre les systèmes . Lorsque le système appelle activement la méthode d'un autre système , cela signifie que le couplage des deux systèmes augmente . Augmentation à long terme des appels RPC , le système frontalier pourrira progressivement . C'est ce à quoi vous devez vraiment faire attention lorsque vous utilisez RPC.
Six, file d'attente de messages
Puisque RPC augmentera le couplage, que devons-nous faire - les événements peuvent être envisagés. Les événements n'augmenteront pas le couplage. Si un système s'abonne aux événements d'un autre système, peu importe qui fournit le même type d'événements à l'avenir, ils peuvent fonctionner normalement. Ce dont dépend le système, ce n'est pas un autre système, mais une sorte d'événement . Si un jour un autre système n'existe pas, tant que l'événement est fourni par l'autre système, le système peut encore fonctionner normalement.
Un autre scénario dans lequel des files d'attente de messages sont utilisées est la transmission de quantités de données purement importantes .
Par exemple, dans la transmission de journaux, il peut y avoir des nœuds pour la collecte, le nettoyage, le filtrage et la surveillance au milieu, ce qui constitue un énorme réseau informatique distribué.
En général, les files d'attente de messages sont un modèle moins couplé et plus flexible. Mais les exigences pour les concepteurs de systèmes seront plus élevées, et il y aura certaines exigences pour l'architecture du système lui-même.
La file d'attente de messages pour des scénarios spécifiques a Kafka, qui traite principalement les flux;
RabbitMQ, ActiveMQ, RocketMQ et autres communications inter-applications distribuées majeures (découplage d'application)
Sept, le problème
7.1 Quelles sont les méthodes de communication inter-processus?
Il peut être expliqué à l'enquêteur d'un point de vue autonome et distribué .
Le processus 9999 peut recevoir ce signal en écrivant un programme. En plus d'utiliser des killinstructions, le processus ci - dessus peut également être effectué en appelant l'API du système d'exploitation .
-
Si vous considérez le modèle autonome, il existe des pipelines, un partage de mémoire et des files d'attente de messages . De ces trois modèles, les programmes de partage de mémoire sont les plus difficiles à écrire, mais ils ont les performances les plus élevées. Le programme pipeline est mieux écrit et possède une interface standard. Les programmes de file d'attente de messages sont également plus faciles à écrire, comme l'utilisation du mode de publication / abonnement pour implémenter des programmes spécifiques.
-
Si nous considérons un modèle distribué, nous avons des appels distants, des files d'attente de messages et des requêtes réseau . L'envoi direct d'un programme de requête réseau n'est pas facile à écrire, il est donc préférable d'utiliser directement le RPC implémenté pour appeler le framework. Le cadre RPC augmentera le couplage du système.Vous pouvez considérer la file d'attente des messages et le mode de publication et d'abonnement aux événements, ce qui peut réduire le couplage entre les systèmes.
-
Utiliser la base de données
-
Utiliser des fichiers normaux
-
Il y a aussi un signal, un processus peut fournir des signaux via le système d'exploitation. Par exemple, si vous souhaitez envoyer un signal USR1 à un processus (pid = 9999), vous pouvez utiliser:
-
kill -s USR1 9999