5 questions d'entretien Dubbo à haute teneur en or !

Aujourd'hui, je vous propose un article sur l'interaction Dubbo IO.

Cet article est écrit par un collègue. Il utilise des mots intéressants pour écrire des points de connaissances ennuyeux. C'est facile à comprendre et très intéressant, j'ai donc hâte de trouver l'autorisation de l'auteur et de le partager avec tout le monde :

Quelques questions intéressantes

Dubbo est un excellent framework RPC avec des modèles de threads complexes Dans cet article, l'auteur analyse l'ensemble du processus IO de Dubbo sur la base de mes connaissances superficielles. Avant de commencer, examinons d'abord les questions suivantes :

• Une fois la méthode métier exécutée, le paquet de données est-il envoyé ?
• Quelle est la différence dans les modèles de thread entre netty3 et netty4 ?
• Le paquet de données atteint le tampon du socket du système d'exploitation, que s'est-il passé ?
• Le journal généré par le fournisseur prend très peu de temps, mais le client expire. Comment pouvons-nous résoudre le problème ?
• Le paquet de données est-il envoyé directement via un canal au niveau de la couche physique ?
• Le fil d'affaires grand public en attente est activé. Condition, à quelle heure est-il réveillé ?
• ...

Ensuite, l'auteur utilisera Dubbo2.5.3 comme consommateur et 2.7.3 comme fournisseur pour décrire l'ensemble du processus d'interaction. L'auteur se place dans la perspective du paquet de données et le raconte. à la première personne. Attachez votre ceinture.

Voyage intéressant

1. Dubbo2.5.3 Le consommateur lance une demande

Je suis un paquet de données, né dans une ville appelée Dubbo2.5.3 Consommateur, ma mission est de fournir des informations et j'apprécie également voyages.

Un jour, j'étais sur le point d'être envoyé. On a dit que j'allais à un endroit appelé Dubbo 2.7.3 Provider.

Ce jour-là, le fil métier a lancé un appel de méthode, dans FailoverClusterInvoker#doInvoke code> J'ai choisi un fournisseur, puis je suis passé par divers filtres grand public, puis par le pipeline Netty3, et enfin j'ai passé <code style="font-size: 14px;word-wrap: break-word;padding: 2px 4px;border-radius : 4px ;marge : 0 2px ;couleur d'arrière-plan : rgba(27,31,35,.05) ;famille de polices : Operator Mono, Consolas, Monaco, Menlo, monospace ;saut de mot : break-all ;couleur : # ff6441; ">NioWorker#scheduleWriteIfNecessary, je suis arrivé à la file d'attente writeTaskQueue de NioWorker. FailoverClusterInvoker#doInvoke我选择了一个Provider，然后经过各种Consumer Filter，再经过Netty3的pipeline，最后通过NioWorker#scheduleWriteIfNecessary方法，我来到了NioWorker的writeTaskQueue队列中。

当我回头看主线程时，发现他在DefaultFuture中的Condition等待，我不知道他在等什么，也不知道他要等多久。

我在writeTaskQueue队列排了一会队，看到netty3 IO worker线程在永不停歇的执行run方法，大家都称这个为死循环。

最后，我很幸运，NioWorker#processWriteTaskQueue

Enfin, j'ai eu de la chance, NioWorker#processWriteTaskQueue m'a sélectionné, je a été écrit dans le tampon Socket du système d'exploitation. Quoi qu'il en soit, j'ai eu assez de temps pour réfléchir au voyage d'aujourd'hui, j'ai parcouru deux groupes de tournée, appelés le thread principal et netty3 IO. fil de travail. Eh bien, les deux services de groupe de touristes sont tous bons et très efficaces.

J'ai simplement enregistré ce que j'ai vu aujourd'hui et je l'ai dessiné en image. Bien sûr, j'ai ignoré les parties sans importance.

1. J'ai vécu beaucoup de choses magiques dans le tampon du socket du système d'exploitation.

2. Dans un endroit appelé couche transport, j'ai ajouté le numéro de port cible et le numéro de port source

3. Dans un endroit appelé couche réseau, j'ai ajouté l'IP cible et l'IP source, et en même temps temps, via L'IP cible est AND avec le masque pour trouver l'IP du « prochain saut »

   🎜🎜🎜🎜Dans un endroit appelé la couche de liaison de données, j'ai ajouté l'adresse MAC cible du « prochain saut » via la source du protocole ARP. Adresse MAC🎜

Le plus intéressant c'est que nous avons pris un téléphérique section par section. Chaque fois que nous changeions de téléphérique, nous devions modifier l'adresse MAC cible et l'adresse MAC source. Plus tard, j'ai demandé à mes amis du paquet de données dans le. même industrie que ce mode s'appelle "Next Jump", sautez saut après saut. Il y a beaucoup de paquets de données ici. Les plus gros sont dans un seul téléphérique, et les plus petits sont regroupés dans un seul téléphérique. Il y a aussi une chose terrible s'ils sont plus gros, ils doivent être divisés en plusieurs câbles. voitures (bien que cela n'ait pas d'importance pour nos paquets de données). Question), cela s'appelle le déballage et le collage. Pendant cette période, nous avons croisé des commutateurs et des routeurs, et nous étions très heureux de jouer avec ces endroits.

Bien sûr, il y a aussi des choses désagréables, c'est-à-dire des embouteillages, le téléphérique à destination est plein, et il n'y a pas de temps pour être emporté, donc vous ne pouvez qu'attendre.

3. Expérience côté Provider

Finalement, je suis arrivé à destination, je suis monté sur un hors-bord appelé "Zero Copy" et je suis rapidement arrivé à netty4, c'était vraiment magnifique. Après NioEventLoop#processSelectedKeys，再经过pipeline中的各种入站handler，我来到了AllChannelHandler的线程池，当然我有很多选择，但是我随便选了一个目的地，这里会经历解码、一系列的Filter，才会来的目的地“业务方法”，NettyCodecAdapter#InternalDecoderdecoder C'est génial, il peut s'occuper du déballage et du collage.

Je vais rester dans le pool de threads d'AllChannelHandler pendant un moment, j'ai donc également dessiné une image pour enregistrer le voyage.

Depuis, mon voyage est terminé, et de nouvelles histoires se poursuivront avec de nouveaux packages de données.

4. Un nouveau paquet de données a été généré du côté du fournisseur

Je suis un paquet de données, né dans une ville appelée Dubbo2.7.3 Provider, ma mission est de réveiller le fil destiné, ensuite je vous le ferai. commencez un voyage vers un endroit appelé Dubbo2.5.3 Consumer.

Une fois la méthode commerciale du fournisseur exécutée

• 由业务线程经过io.netty.channel.AbstractChannelHandlerContext#writeAndFlush
io.netty.channel.AbstractChannelHandlerContext#writeAndFlush