Systèmes distribués en tant que pipelines de données – meilleure programmation

Online Coding Courses for Kids

La contre-pression est un mécanisme pour résister au flux de données à travers les systèmes logiciels afin de maintenir un flux stable face aux variations locales de capacité et de débit.

Nous voulons réguler le débit d’eau en ne laissant pas trop d’eau entrer à trop grande vitesse, ce qui risquerait d’endommager le maillage du tuyau d’eau. Pour ce faire, inversons l’analogie et essayons d’extraire les données du système plutôt que d’essayer de les pousser.

Disons que, conceptuellement, la file d’attente se trouve à l’intérieur du producteur du pipeline de tâches, et sa taille est limitée. (Jamais, jamais utiliser des tampons infinis. Jamais. Jamais.) L’appelant tend la main à l’appelé dans ce cas pour obtenir une nouvelle tâche du tampon à traiter. Le débit est ainsi explicitement contrôlé par le côté consommateur (ce qui est logique – celui qui doit faire le travail doit décider à quelle vitesse il peut aller), et la capacité (la mesure des demandes ouvertes) est déterminée par le côté appelant en décidant comment de nombreuses tâches non traitées que nous voulons conserver (alias la taille de la file d’attente).

Si la file d’attente est pleine parce que le consommateur ne s’exécute pas assez rapidement, l’appelant a le choix – il peut supprimer les tâches les plus anciennes (et, probablement, les moins pertinentes) de la file d’attente pour faire de la place ou arrêter de prendre d’autres demandes immédiatement ( car ils échoueront probablement de toute façon).

Cela diffère de la définition des délais d’expiration des tâches, car nous ne disons pas combien de temps une tâche devrait prendre, mais nous limitons le nombre de tâches inachevées que le système dans son ensemble peut avoir et nous espérons toujours les terminer dans le SLA.

Nous pouvons également faire en sorte que l’appelé soit propriétaire de la file d’attente et lui permettre de gérer à la fois le tarif et le nombre de demandes en attente. Cela centralise la logique dans une certaine mesure, mais il est possible que ce système soit tellement chargé lors d’une augmentation de trafic qu’il ne sera même pas en mesure de prendre la décision de charger le délestage.

Il existe trois façons de réaliser une contre-pression:

Dites à l’appelant d’arrêter de donner de nouvelles tâches

C’est généralement le meilleur moyen et le plus efficace.

Si un système en aval sous charge peut demander de manière proactive une pause, un équilibre dynamique entre producteur et consommateur peut être atteint très rapidement. RxJava utilise ce paradigme.

Bloquer l’appelant lorsqu’il essaie de lui confier une nouvelle tâche

Ceci est légèrement différent car, dans ce cas, l’appelant fait face à une situation d’erreur lors de la production d’une nouvelle tâche, et il doit prendre une décision indépendante sur la façon de gérer cette erreur après avoir pris la tâche.

Des modèles tels que la limitation de débit conviennent ici.

Commencez à supprimer certaines tâches

Selon le contexte, l’appelé peut commencer à supprimer les tâches les plus anciennes ou les plus récentes du pipeline.

Ce comportement silencieux n’est pas mon préféré car il donne moins de visibilité sur le système à moins que l’appelant ne surveille correctement l’achèvement de la tâche, mais c’est la même chose qui lui donne de la valeur – l’appelé peut l’implémenter indépendamment si l’appelant ne peut pas être influencé à changer leur comportement.

Close Menu