Qu'arrive-t-il aux messages qui parviennent à un serveur implémente le traitement de flux après que la source a atteint sa limite?

Question

flux AKKA d'apprentissage Im, mais de toute évidence son rapport avec tout cadre de streaming :)

citant akka documentation:

réactifs Streams est juste pour définir un mécanisme commun de la façon de déplacer données à travers une frontière asynchrone sans pertes, tampon ou épuisement des ressources

maintenant, ce que je comprends est que si jusqu'à avant les flux, permet de prendre un serveur http, par exemple, la demande viendrais quand le récepteur a été fini avec une requête, donc les nouvelles demandes à venir seront collectées dans un tampon qui contiendra les demandes en attente, et ensuite il y aura un problème que cette mémoire tampon ait une taille inconnue et à un moment donné si le serveur est surchargé nous pouvons perdre des demandes qui attendaient. Alors, le traitement des flux est arrivé et ils ont limité ce tampon pour qu'il soit contrôlable ... afin que nous puissions prédéfinir le nombre de messages (demandes dans mon exemple) que nous voulons avoir en ligne et nous pouvons nous occuper de chacun à une fois.

ma question, si nous mettre en œuvre qu'une source de notre serveur peut avoir un 3 messages au plus, donc si le 4ème id venir ce qui se passe avec lui?

je veux dire quand un autre serveur nous appeler et nous prenons déjà en charge les demandes 3 ... ce sera passé à la demande de lui?

Answer 1

Qu'est-ce que vous décrivez est pas vraiment le principal problème que les implémentations réactives Streams résoudre.

La contre-pression en termes de nombre de requêtes est résolue avec des outils de mise en réseau normaux. Par exemple, en Java, vous pouvez configurer un pool de threads d'une bibliothèque de mise en réseau (par exemple Netty) à un certain niveau de parallélisme, et la bibliothèque se chargera d'accepter autant de requêtes que possible. Ou, si vous utilisez API sockets synchrones, c'est encore plus simple - vous pouvez reporter l'appel accept() sur le socket serveur jusqu'à ce que tous les clients actuellement connectés soient servis. Dans les deux cas, il n'y a pas de «tampon» de chaque côté, c'est juste que le serveur accepte une connexion, le client sera bloqué (soit dans un appel système pour bloquer les API, soit dans une boucle d'événements pour les API asynchrones).

Ce que les implémentations réactives Streams résoudre est comment gérer l'intérieur d'une contre-pression pipeline de données de niveau supérieur. Les implémentations de flux réactifs (par exemple akka-streams) fournissent un moyen de construire un pipeline de données dans lequel, lorsque le consommateur de données est lent, le producteur ralentira automatiquement, et cela fonctionnera avec n'importe quel type de transport sous-jacent, que ce soit HTTP, WebSockets, les connexions TCP brutes ou même la messagerie in-process.

Par exemple, considérons une simple connexion WebSocket, où le client envoie un flux continu d'informations (par exemple les données de certains capteurs), et le serveur écrit ces données à une base de données. Supposons maintenant que la base de données côté serveur devienne lente pour une raison quelconque (problèmes de mise en réseau, surcharge de disque, etc.). Le serveur ne peut plus suivre les données envoyées par le client, c'est-à-dire qu'il ne peut pas les enregistrer dans la base de données avant l'arrivée de la nouvelle donnée. Si vous utilisez une implémentation de flux réactifs tout au long de ce pipeline, le serveur signalera automatiquement au client qu'il ne peut pas traiter plus de données, et le client ajustera automatiquement son taux de production afin de ne pas surcharger le serveur.

Naturellement, ceci peut être effectué sans aucune mise en œuvre des flots réactifs, par ex. en contrôlant manuellement les accusés de réception.Cependant, comme avec beaucoup d'autres bibliothèques, les implémentations de Reactive Streams résolvent ce problème pour vous. Ils fournissent également un moyen facile de définir de tels pipelines, et généralement ils ont des interfaces pour divers systèmes externes tels que les bases de données. En particulier, de telles bibliothèques peuvent implémenter une contre-pression au niveau le plus bas, jusqu'à la connexion TCP, ce qui peut être difficile à faire manuellement. En ce qui concerne les flux réactifs eux-mêmes, il s'agit simplement d'une description d'une API qui peut être implémentée par une bibliothèque, qui définit des termes et un comportement communs et permet à ces bibliothèques d'être interchangeables ou d'interagir facilement, par ex. vous pouvez connecter un pipeline akka-streams à un pipeline Monix en utilisant les interfaces de la spécification, et le pipeline combiné fonctionnera de manière transparente et supportera toutes les fonctions de contre-pression des Reacive Streams.