3
votes

"Dans un environnement distribué, on n'utilise pas le multithreading" - Pourquoi?

Je travaille sur une plate-forme qui héberge de petites applications Java, qui utilisent toutes actuellement un seul thread, vivant à l'intérieur d'un moteur Docker, consommant les données d'un serveur Kafka et se connectant à une base de données centrale.

Maintenant, je dois mettre une autre application Java sur cette plate-forme. Cette application utilise relativement fortement le multithreading, je l'ai déjà testé dans un conteneur Docker et cela fonctionne parfaitement là-bas, donc je suis prêt à le déployer sur la plate-forme où il serait mis à l'échelle manuellement, c'est-à-dire qu'un humain définirait le nombre de conteneurs qui seraient démarrés, chacun d'entre eux contenant une instance de cette application.

Mon architecte a une objection, disant que "Dans un environnement distribué, nous n'utilisons jamais le multithreading". Alors maintenant, je dois refactoriser mon application en éliminant toute logique liée aux threads, ce qui en fait un thread unique. Je lui ai demandé un raisonnement plus détaillé, mais il crie "Si vous n'êtes pas conscient de ce principe, vous n'avez pas de place près de Java".

Est-ce vraiment une erreur d'utiliser une application Java multithread dans un système distribué - un simple cluster avec dix ou vingt machines physiques, chacune hébergeant un certain nombre de machines virtuelles, qui exécutent ensuite des conteneurs Docker, avec des applications Java à l'intérieur.

/ p>

Honnêtement, je ne vois pas le problème du multithreading à l'intérieur d'un conteneur. Est-ce vraiment une erreur ou en quelque sorte "interdit"?

Merci.


4 commentaires

Je suis désolé que vous ayez à travailler avec un intimidateur.


@DavidSchwartz Pas n'importe quel intimidateur, un intimidateur irréfléchi d'esprit fermé qui veut forcer l'adhésion à des aphorismes malavisés du culte du fret. C'est comme dire: "Si votre maison a plusieurs unités A / C mini-split au lieu d'une unité centrale A / C, vous ne pouvez pas utiliser une clé à douille pour résoudre vos problèmes A / C!" Parce que «si vous n'êtes pas conscient de ce principe, vous n'avez pas de place à proximité de Java» signifie en réalité «je n'ai aucune idée de ce dont je parle». De quelle base de données rectale vient CELA ?!?! Et oui, j'espère qu'il lit ceci.


En fait, une application distribuée est toujours multithread. Même lorsque chaque nœud est monothread, l'ensemble du cluster multi-nœuds est multithread. Ainsi, rendre le multithread à un seul nœud ne serait pas plus complexe, mais peut vous faciliter la vie. Bref, je ne laisserais pas votre architecte traîner près de Java.


C'est idiot d'utiliser des absolus comme ça. Je veux dire, Elasticsearch est distribué et fortement multithread, donc je suppose qu'il y a au moins un contre-argument.


4 Réponses :


1
votes

Je suppose qu'il vous le dit seulement car l'utilisation d'un seul thread élimine les problèmes de multi-threading et de tri des données. Il n'y a cependant rien de mal avec le multithreading.


0 commentaires

2
votes

Lorsque vous écrivez par exemple une application Web qui s'exécutera dans un serveur d'applications Java EE, vous ne devriez normalement pas démarrer vos propres threads dans votre application Web. Le serveur d'application gérera les threads et allouera des threads pour traiter les requêtes entrantes sur le serveur.

Cependant, il n'y a pas de règle absolue ou de raison pour laquelle il n'est jamais judicieux d'utiliser le multi-threading dans un environnement distribué.

Il y a des avantages à créer des applications à un seul thread: le code sera plus simple et vous n'aurez pas à faire face à des problèmes de concurrence difficiles.

Mais "dans un environnement distribué, nous n'utilisons jamais le multithreading" n'est pas forcément toujours vrai et "si vous n'êtes pas conscient de ce principe, vous n'avez pas de place près de Java" semble arrogant et condescendant.


0 commentaires

0
votes

Quoi? Nous utilisons beaucoup RxJava et Spring Reactor dans notre application et cela fonctionne assez bien. De toute façon, vous ne pouvez pas travailler avec des threads sur deux JVM. Assurez-vous donc que votre logique fonctionne comme prévu sur une seule JVM.


0 commentaires

0
votes

Les systèmes distribués ont généralement des tâches fortement liées aux E / S.

Si les appels d'E / S se bloquent dans votre système

Le seul moyen d'obtenir la concurrence dans le processus est de créer de nouveaux threads pour effectuer d'autres travaux utiles. (Multi-threading).

  • La mise en garde avec cette approche est que, s'il y a trop de threads en vol, le système d'exploitation passera trop de temps en contexte basculer entre les threads, ce qui est un travail inutile.

Si les appels d'E / S ne sont pas bloquants dans votre système

Ensuite, vous pouvez éviter l'approche multi-thread et utiliser un seul thread pour traiter toutes vos demandes. (en savoir plus sur les boucles d'événements ou Netty Framework ou NodeJS de Java)

L'avantage de l'approche à thread unique

  1. Le système d'exploitation n'effectue aucun changement de contexte de thread inutile.
  2. Vous ne rencontrerez AUCUN problème d'accès concurrentiel comme des verrous morts ou des conditions de concurrence.

L'inconvénient est que

  1. Il est souvent plus difficile de coder / penser de manière non bloquante
  2. Vous finissez généralement par utiliser plus de mémoire sous la forme de files d'attente de blocage.

0 commentaires