Comment traiter plusieurs résultats de firebase database provenant de serveurs différents pour une requête

Vous souhaitez redimensionner votre application, mais vous avez conçu un goulot d’étranglement inhérent. À savoir: le Mgr.

Ce que je ferais, c’est que je diviserais le gestionnaire en au moins deux parties. Front-end et backend. Le serveur frontal peut simplement être un agrégateur et / ou un contrôleur qui collecte toutes les demandes de tous les serveurs d’interface utilisateur différents, horodate ces demandes et les place dans une file d’attente (RabbitMQ, Kafka, Redis, etc.) en envoyant un message avec l’ID de session de l’UI. ou quelque chose de similaire qui identifie de manière unique la source de la demande. Ensuite, il vous suffit d’attendre d’avoir une réponse dans la queue (avec un sujet différent bien sûr).

Ensuite, sur votre backend (de l’autre côté de la file d’attente), vous pouvez configurer autant de nœuds que votre charge le requirejs et les exécuter dans la même tâche. À savoir: extraire les demandes de la queue et appeler ces API de surveillance des performances si nécessaire. Vous pouvez redimensionner ces nœuds dorsaux autant de fois que vous le souhaitez car ils n’ont pas d’état; tout l’état à stocker fait déjà partie des messages de la file d’attente qui seront automatiquement conservés par Redis / Kafka / RabbitMQ. ou quoi que vous choisissiez d’autre.

Vous pouvez également utiliser Apache Storm ou quelque chose de similaire pour le faire dans le backend, car il a été conçu pour ce type d’applications.

Apache Storm possède également une fonctionnalité de fusion intégrée exposée via l’ API Trident .

Note sur l’authentification: vous devez authentifier les requêtes HTTP du côté frontal et tout ira bien. Il vous suffit d’atsortingbuer des identifiants uniques (identifiants de session les plus probables) aux utilisateurs connectés à votre système de gestion et d’utiliser cet ID interne lorsque vous transmettez vos demandes à des serveurs en aval.

Maintenant, comment envoyer des requêtes parallèles à un moniteur individuel et consumr uniquement lorsque tous les nœuds ont répondu? Cela signifie comment attendre que le thread utilisateur consum toutes les réponses des moniteurs de performances? Comment déclencher une demande REST parallèle pour une demande d’interface utilisateur unique sur MGR.

Eh bien, si vous avez tant de questions concernant la gestion des connexions utilisateur et la fourniture de réponses à ces clients, je vous suggérerais de choisir un livre sur l’API des servlets Java. Vous voudrez peut-être lire celui-ci par exemple: Servlet & JSP: un didacticiel (série de didacticiels) . C’est un peu démodé mais bien écrit.

Mais avec tout le respect que je vous dois, si vous avez tellement de questions sur ces sujets fondamentaux, il serait peut-être préférable de laisser la conception de l’architecture à quelqu’un de plus expérimenté.

Ne réinventez pas la roue, utilisez de bons outils de surveillance BAM et de firebase database existants, ils ont beaucoup de tableaux de bord et de statistiques intégrés, faciles à connecter avec Java et les stream de travail.

Mais pour l’évolutivité; la collecte de données sera collectée par plusieurs machines (moniteur de performance) connectées à des bases de données individuelles.

Quel type de mise à l’échelle envisagez-vous approximativement? S’agit-il d’une centaine d’octets Terra multiples de Go? La raison en est que de nos jours, SQL Server et Oracle peuvent gérer de très gros volumes de données. Une fois que les données sont collectées dans une firebase database centrale, le jeu est terminé en ce qui concerne la recherche et les calculs.

Maintenant, Manager (Mgr) est responsable de la multidiffusion de la requête sur tous les moniteurs de perf. pour collecter les données statistiques globales afin de satisfaire une seule demande d’interface utilisateur.

Ce sera une tâche majeure pour écrire ceci et ce sera vraiment IMHO complexe. Cela dit, je ne suis pas un expert dans cet aspect.

Ce que je ferais, c’est de placer une couche de Hazelcast ou d’Infinispan ou quelque chose du genre dans votre Performance Monitor au lieu de Hazelcast. Le moniteur de performances lui-même, comme une logique, peut faire partie du DataGrid. Ensuite, MySQL fonctionnera comme un stockage persistant de cette grid de données. En ce sens, vous pouvez avoir plus d’un Mysql et chaque mysql ne contiendra qu’une partie des données. Cela fonctionnera simplement comme une capacité d’extension pour aller au-delà de votre RAM maximale. En temps supplémentaire, vous adaptez votre moniteur de performances et vos capacités persistantes.

Young puis Map Reduce ou d’autres fonctions dissortingbuées pour l’agrégation peuvent entraîner une quantité importante de parallélisme et la capacité de traiter beaucoup plus de requêtes. En outre, une telle architecture est horizontale. A la fin, cela devrait ressembler à ceci:

Et juste sur une autre note pour dire qu’il n’est pas nécessaire en général d’avoir 1 MySQL pour chaque hazelcast. Cela dépend de l’objective. J’ai aussi un peu oublié le gestionnaire du diagramme, mais les choses simples, cela peut fonctionner comme une passerelle vers la grid de données ou bien il peut être fusionné avec la grid.

Je ne sais pas si ma réponse vous serait utile, car cette question a été publiée parfois.

Je voudrais y répondre en fonction de votre question, des problèmes dans l’approche actuelle et de la solution proposée …

1) Comment vais-je faire en sorte que les données du moniteur multiple soient sortingées en fonction de la demande du client chez Mgr. Chaque moniteur peut donner le résultat selon la demande du client; mais comment encore fusionner plusieurs données de machines via java? Moyens Comment effectuer en mémoire la fonction d’agrégat / scalaire sql (par exemple, Groupby, orderby, avg) sur tous les résultats extraits de plusieurs clusters chez MGR. Comment puis-je implémenter les fonctionnalités agrégées / scalaires DB sql du côté Java, toutes les API connues? Je pense que ce dont j’ai besoin est de réduire une partie de la technique de mapreduce en hadoop.

Java fourni dans Java DB dans le cadre de la dissortingbution Java qui est également disponible en tant que firebase database Apache Derby. Cette firebase database peut être utilisée comme firebase database SQL en mémoire. JavaDB & Apache Derby stocke les données sur le disque. Ainsi, vous ne perdrez pas les données après le redémarrage. Vérifiez ici http://www.oracle.com/technetwork/java/javadb/overview/index.html https://db.apache.org/derby/

Pour Map-Reduce, l’approche de la collection Java simple fonctionnerait. Dans ce cas, je ne pense pas que vous ayez besoin d’un framework spécial Map-Réduire. Vous devez toutefois prendre en compte la mémoire insuffisante, la bande passante réseau, etc. lorsque vous lisez des données provenant de plusieurs sources.

2) Une demande de l’interface utilisateur (supposons que le compte de sélection (*) de la firebase database où la mémoire> 1000 Mo) doit être transférée à plusieurs machines. Maintenant, comment envoyer des requêtes parallèles à un moniteur individuel et consumr uniquement lorsque tous les nœuds ont répondu? Signifie comment attendre le fil de l’utilisateur jusqu’à ce qu’il consum toutes les réponses des moniteurs de perf? Comment déclencher une demande REST parallèle pour une demande d’interface utilisateur unique sur MGR.

Idéalement, le type d’application NodeJS est vraiment la meilleure suite où l’application reçoit un rappel chaque fois qu’il y a une réponse à l’appel HTTP. Cependant, vous pouvez implémenter Observer Pattern comme expliqué ici. Comment effectuer un rappel JAVA entre les classes?

3) Dois-je authentifier l’utilisateur de l’interface utilisateur sur le moniteur Mgr et Perf?

Il devrait être basé sur vos besoins

4) Pensez-vous que cette approche présente des inconvénients?

Cette approche présente plusieurs inconvénients

• Les données ne doivent pas être extraites à la demande de l’interface utilisateur. Au minimum, les données doivent être disponibles dans la firebase database centralisée chaque fois qu’il est demandé de générer les données. Extraire des données de différents points de terminaison coûte cher.
• Les statistiques doivent être collectées périodiquement pour conserver l’historique et les rapports doivent être générés en fonction de la fenêtre temporelle en mouvement.
• JVM peut être OutOfMemory si des données volumineuses doivent être traitées. Une manipulation appropriée est requirejse.
• Des données volumineuses peuvent être transférées sur le réseau à chaque nouvelle demande. Ce pourrait être pour les mêmes données à nouveau.

Remarques:

1) Je n’ai pas choisi NoSql car les données sont structurées et aucune jointure n’est requirejse.

Pas de SQL ne veut pas dire qu’il n’y a pas de structure suivie. Même la firebase database NoSQL est la meilleure solution pour ces données où vous ne mettez pas à jour les enregistrements, les transactions, etc. ne sont pas requirejses.

2) Je ne suis pas allé pour node.js depuis que je suis nouveau pour cela et que cela peut prendre plus de temps pour le développer. Je ne développe pas non plus de critiques simultanées où les threads simples sont les mieux adaptés. Ici, seul le push / récupération des données est effectué. Pas de modification en cours.

NodeJS ne sera pas un bon choix car il est à thread unique. NodeJS ne doit pas être utilisé lorsque vous avez un travail intensif en CPU à effectuer. Comme le tien.

3) Je souhaite une firebase database individuelle pour chaque moniteur OU au moins deux instances de firebase database avec plusieurs clusters pour une instance afin de prendre en charge un access plus rapide aux données statistiques BIG en temps réel.

** Je vous suggérerais plutôt de stocker les données dans une firebase database pouvant être mise à l’échelle horizontalement, de les traiter au fur et à mesure de leur arrivée ou de les traiter par lots afin que votre expérience utilisateur soit satisfaisante. **