Analyse graphique du modèle de thread Redis

Cet article vous apporte des connaissances pertinentes sur Redis, qui présente principalement les problèmes liés au modèle de thread Redis est un thread unique. Examinons-le ensemble, j'espère qu'il sera utile à tout le monde.

Apprentissage recommandé : Tutoriel vidéo Redis

Redis est un fil unique, qui doit être noté.

Tout d'abord, nous aurons un client. Ce client a en fait utilisé un outil comme le client Redis pour se connecter au serveur Redis avant nous.
Si nous l'intégrons ultérieurement à Java, le client correspondant sera effectivement fourni en Java.

Ensuite, nous aurons un serveur Redis, qui est en fait l'un de nos Redis. Une fois l'ensemble du service démarré, il aura un processus.
Dans notre version, il contient en fait deux choses en interne.

Tout d'abord, il disposera d'un multiplexeur, que nous avons déjà présenté dans la leçon précédente. C'est un modèle non bloquant.
Ensuite, il dispose en fait d'un allocateur d'événements de fichier, qui est spécialement utilisé pour allouer certains événements.

En dessous, il sera divisé en trois processeurs différents, examinons chacun.

Il y a d'abord un gestionnaire de réponse de connexion, et enfin un gestionnaire de demande de commande, et il y a un gestionnaire de réponse de commande.

Comment le comprendre ? Examinons d'abord un gestionnaire de réponse de connexion.

Lors de la connexion au processeur de réponse, l'une de ses fonctions principales est de maintenir un lien avec notre client.
Une fois l'un de nos serveurs Redis démarré, nous aurons en fait un événement de lecture fourni avec notre répondeur de connexion.
Son nom complet s'appelle en réalité AE_readable. Vous pouvez le considérer comme un signe, il y aura un tel événement, et cet événement sera associé à notre processeur de réponse de connexion.

Enfin, lorsqu'un de nos clients souhaite établir une connexion avec notre serveur, cela signifie en fait que nous avons tapé un client redis dans l'outil de ligne de commande au début, il doit être connecté à notre serveur. établir une connexion. Lors de l'établissement d'une connexion, il enverra en fait un indicateur de lecture, qui est en fait une heure de lecture. À ce stade, sur notre serveur Redis, il aura en fait un socket serveur.

Le socket serveur correspond en fait à l'un de nos sockets clients. Ils sont un élément de contenu en programmation réseau, et la communication entre eux est un socket. Après être entré en contact avec un événement tel que read, nous le transmettrons ensuite à notre multiplexeur pour traitement.
Si vous le lui laissez pour le traitement, il est en fait non bloquant. Une fois qu'il le recevra, il le mettra dans une flèche comme la nôtre.

Pour cette flèche ici, nous pouvons l'appeler un pipeline, ou nous pouvons également l'appeler une file d'attente. Il sera ajouté ici. Après avoir été ajouté, ce monde atteindra réellement notre répartiteur d'événements de fichiers. Lorsque cet allocateur reconnaît qu'il s'agit d'un événement de lecture, il correspondra à notre processeur de réponse de connexion, c'est-à-dire qu'il le lui remettra pour traitement.
C'est une lecture qui se correspond.
À ce stade, cela peut effectivement montrer que notre client et notre serveur ont établi une connexion. Une fois la connexion établie, si l'indicateur de lecture est défini, cet événement sera effectivement transmis à notre processeur de demande de commande. Si cette commande sollicite le processeur, vous pouvez la considérer comme un traitement spécifique des requêtes, c'est-à-dire une requête. Ensuite, le processeur de réponse de commande, vous pouvez le comprendre comme une réponse, c'est-à-dire une réponse.

Ensuite, nous devrons peut-être faire quelque chose côté client, par exemple, nous devons définir une valeur, n'est-ce pas ? Si vous définissez une valeur, par exemple set name ***, il s'agit en fait d'une commande.
Pour cette commande, l'un de ses types de monde est en fait une lecture. Ensuite, il est envoyé au multiplexeur via le socket du serveur. Après l'avoir obtenu, il est placé dans notre file d'attente puis transmis au répartiteur d'événements de fichier.

Après avoir obtenu cet allocateur d'événement de fichier, il rendra un jugement et jugera que l'événement correspondant est lu. Lorsqu'il s'agit d'un événement de lecture à ce moment-là, il sera demandé à notre processeur de demande de commande de traiter notre commande. Il le reconnaîtra. Il reconnaîtra que le nom actuel est un nom défini ***, il fera donc un processus. Il souhaite stocker un contenu défini par notre utilisateur et stocker cette valeur clé dans notre mémoire. Il s'agit en fait du traitement d'une requête de commande, qui est une requête.

Après son traitement, il lui attribuera ensuite un blanc, qui est un identifiant écrit. Si ce logo est écrit ici, nous pouvons effectivement l'utiliser comme réponse. Parce qu'une fois qu'une de nos demandes est réellement traitée, après avoir fini de saisir une commande, nous pouvons voir un ok, n'est-ce pas ? Si cela est correct, cela équivaut en fait à un élément de contenu qui nous est renvoyé par l'un de nos processeurs de réponse aux commandes. Il utilisera donc une marque écrite par une écriture. De cette façon, l’une de nos balises écrites sera en fait regroupée avec notre processeur de réponse aux commandes. Quant à l'écriture, son nom complet est en fait un type d'événement appelé AE_writable.

D'accord, alors dans notre client, nous devons en fait faire une réécriture. Ce n'est pas grave, ou lorsque nous interrogeons la liste et que nous voulons afficher tout le contenu de la liste, il s'agit en fait d'une réécriture. Nous souhaitons afficher le contenu en bas de la console, qui est un type d'événement tel que l'écriture. Il est ensuite transmis à notre multiplexeur puis envoyé à l'une de nos files d'attente, qui est affectée à l'un de nos répartiteurs d'événements de fichiers. Cette fois, nos événements Web seront à la hauteur. L'événement Web correspond.

Par la suite, notre processeur de réponse aux commandes effectuera une réécriture. Il mettra notre OK, ou le numéro d'une liste que nous avons obtenue, le contenu de la liste, etc. Tant qu'il y a du contenu à afficher, il sera utilisé comme réponse, c'est-à-dire que le contenu de la réponse sera réécrit à l'un de nos clients et affiché sur le client. Dans l’ensemble de notre modèle actuel, il existe en fait deux événements différents, l’un appelé lisible et l’autre appelé inscriptible.

Bien sûr, ce que nous mettons en place maintenant n'est qu'un seul client. Si nous avons plusieurs clients, leurs principes seront exactement les mêmes. Il s'agit en fait d'un modèle de version threadé. Il peut être difficile de comprendre quand vous entrez en contact avec lui pour la première fois, mais cela n'a pas d'importance. Cette image peut réellement aider chacun à approfondir cette intention.

Ensuite, l'ensemble de son processus de traitement peut également être compris en suivant ce que j'ai dit. Afin de faciliter la compréhension de chacun, nous faisons ici un dessin pour donner un exemple.

Supposons que nous ayons un KTV maintenant, et que ce KTV soit redis.

Ensuite, nous avons beaucoup de clients qui veulent chanter. S'ils veulent chanter, il y aura certainement des employés dans notre KTV. Nous diviserons les employés en deux catégories.
La première catégorie est celle du réceptionniste à la porte, et la seconde est celle du responsable du lobby.
Le réceptionniste à la porte est en réalité un multiplexeur, et le responsable du lobby est en réalité un distributeur de fichiers.

Ensuite, nos clients doivent avoir des demandes correspondantes, ou des besoins correspondants, à ce moment-là, ils doivent demander à notre réceptionniste à la porte et laisser la réceptionniste à la porte effectuer un traitement simple.
Peut-être veut-il voir à quel type d'activités l'utilisateur souhaite participer, s'il existe des coupons, etc.

Ensuite le préposé à la commande à la porte, s'il est sûr que le client a envie de chanter, peut lui dire s'il te plaît, passe au fond, il y a un passage derrière. Ce passage est en fait une file d'attente. Vous faites la queue pour vous rendre à ce passage. Lorsque vous entrez, c'est une salle d'affaires pour l'ensemble de notre KTV. Il y aura un lobby manager dans le hall d'affaires. Le lobby manager traitera une demande réelle d'un de nos clients.

Ensuite, dans l'un de nos KTV, en fait, nous aurons certainement une boîte. Chaque boîte gérera les utilisateurs et traitera les différentes demandes des clients. À l'intérieur de notre boîte, il y aura trois jeunes filles ou jeunes frères, qui répondront aux différents besoins des utilisateurs.

Par exemple, le premier est dédié à l'ouverture de la porte aux clients. L'action d'ouvrir la porte équivaut à établir un lien entre l'un de nos clients et le libérateur. Une fois la porte ouverte, vous pouvez entrer, n'est-ce pas ? Après son arrivée, cette jeune femme ne sera plus responsable de son travail correspondant. Il le confiera à l'un de nos subordonnés. La jeune femme ou le frère suivant s'occupera de certaines demandes spécifiquement destinées aux utilisateurs.

Par exemple, si un client demande une chanson, il sera demandé à la personne qui a demandé la chanson d'effectuer le traitement correspondant. La solution à ce problème consiste à allumer l’ordinateur pour commander et sélectionner des chansons. Après avoir sélectionné la chanson, vous devez répondre au client. Vous avez raison, n'est-ce pas ? Vous devez également remettre des microphones aux clients, donc à ce moment-là, il y aura une notification indiquant qu'il y a une telle jeune femme, et cette jeune femme donnera ce microphone au client. Vous pouvez aller chanter maintenant. Nous avons déjà commandé cette chanson pour vous. Allez-y et chantez.

À ce moment-là, toute l'action d'un client demandant une chanson et chantant dans le KTV est effectivement terminée. Cela correspond en fait à une opération effectuée par un client que nous avons mentionnée précédemment dans le modèle de thread de version. Tout d'abord, la connexion est établie, puis la demande est traitée, puis l'une des demandes reçoit une réponse. Il y a trois étapes au total.

Dans notre région, l'ensemble du gestionnaire du lobby et leurs notifications de demandes de chansons sont en fait gérées en interne. Ceci est basé sur l’une de nos boîtes. Quant à la salle privée, dans notre redis, pouvons-nous l'utiliser comme mémoire, car les opérations telles que le stockage et la lecture dans redis sont en fait basées sur la mémoire. C'est donc très rapide si c'est en mémoire.

Si vous êtes dans notre salle privée, vous pouvez chanter, commander des fruits, boire de la bière, etc. dans la salle privée. En effet, si les opérations reposent toutes sur l'une de nos boîtes internes, sa série d'actions, etc., sera en réalité réalisée très rapidement.

Cela peut en fait être une simple compréhension pour l'un de nos modèles de fil. Pour notre redis, il s'agit en fait d'un mode monothread. Pourquoi l’utilisation d’un modèle monothread est-elle très rapide ?

En fait, il y a deux points principaux.
Le premier point est qu'un de nos réceptionnistes de porte est en réalité un multiplexeur. Quant à ce multiplexeur, il repose sur un modèle non bloquant, il est donc traité très rapidement. Il n'attendra pas les réponses une par une en raison du mode de blocage précédent. Maintenant qu'un modèle tel qu'un multiplexeur IO est utilisé, ses performances de traitement sont en réalité très, très rapides.

L'autre partie est notre gestionnaire de lobby. Cette partie fonctionne en fait sur la base de la mémoire. Pour les opérations de mémoire pure, ce sera en fait très, très rapide.

Bien sûr, après avoir utilisé un seul thread, l'une de ses fonctions a également été mentionnée. Si un seul thread est utilisé, cela peut éviter le multithread. Parce que si vous avez plusieurs threads, vous pouvez utiliser l'un de ses commutateurs de contexte. Une fois commuté, cela peut causer des problèmes. De plus, certaines pertes correspondantes peuvent également être évitées. Ainsi, lorsque nous utilisons le modèle tronc, sa simultanéité et son efficacité sont très, très élevées.

Apprentissage recommandé : Tutoriel vidéo Redis

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!