Discussion :

[flavors]

Bonjour,

Dans le cadre de mes cours, je dois développer un chat instantané. Ce dernier doit fonctionner avec 2 serveurs dans le cas où il y ait un problème sur l'un des deux. Il doit aussi implémenter une BDD pour garder un historique des conversations, gérer les bans, login, etc.
Pour l'instant, le fonctionnement est le suivant :
Un client connecté sur le serveur1 envoie un message. Ce message est mis en BDD par le serveurs 1. Pour que les utilisateurs présents du serveur2 puissent voir le message, il faut que le serveur2 aille piocher le message le message dans la BDD.

C'est sur cette dernière étape que je rencontre mon problème.
Comment le serveur est sensé savoir quand il doit aller chercher ce message dans la BDD.

J'ai pensé à 2 solutions:
- Une boucle dans un thread qui parcours la BDD à intervalle régulier.
- Ouvrir un socket entre les 2 serveurs. Quand un des serveurs effectue une action sur la BDD, il en informe l'autre qui va aller chercher cette information.
Je me dis alors que quitte à avoir un socket ouvert entre les 2 serveurs, autant transmettre directement le message au travers de ce dernier.

Pensez-vous que ces solutions soient viables? Avez-vous d'autres pistes à me proposer ?

Je vous en remercie par avance.

[Pill_S]

Ton besoin ressemble à du load balancing / failover. Répartir la charge entre plusieurs serveurs et/ou avoir un serveur de secours si le premier tombe.

Je te rassure, pas besoin de réinventer la roue, ça existe depuis longtemps. Notamment dans Apache, tu peux utiliser mod_proxy et BalancerMember: https://httpd.apache.org/docs/2.2/fr...balancermember : tu places un apache http en mode reverse proxy devant ta webapp, et apache s'occupe de router les requêtes vers le serveur le plus adapté.

De plus, le balancing peut se faire au niveau de la webapp, mais également au niveau de la base de données. Pas besoin de plusieurs connexions à plusieurs bases et de les synchroniser manuellement, p.ex. avec MySQL tu configure tes serveurs et déclare la même data source dans toutes tes applications. MySQL s'occupe de répliquer les données partout et de synchroniser toutes les données: https://www.digitalocean.com/communi...d-balancing--3

Par contre, à moins que ça soit un exercice d'étudiant pour essayer de mettre en place quelque chose soi-même, oublie toutes les solutions maison, c'est largement moins efficace et standard que ce qui existe sur le marché et va te prendre un temps infini avant que ça marche correctement

[flavors]

Bonjour et merci pour votre réponse.

J'ai lu le lien que vous m'avez donné mais je vais devoir me pencher un peu plus dessus pour bien comprendre la chose.
Pour l'instant quand je parlais de serveur, c'était un simple ServerSocket qui accepter les connexion entrante du client.
La sélection du serveur se faisait au lancement du client avec une simple condition (le client essayer de se connecter à l'adresse du 1er serveur et si il n'y arrive pas, il essaye sur la seconde.

De ce que j'en ai lu pour l'instant de loadbalancing se fait au niveau d'appache donc au niveau du serveur? Dans mon cas le 2eme serveur est utile dans le cas ou les 1er est down. Donc si le le 1er serveur est down, comment le client sait qu'il doit se connecter au second ?

[Pill_S]

Justement, avec un load balancer, le client ne sait même pas qu'il y a plusieurs serveurs. C'est d'ailleurs une mauvaise idée de déléguer la responsabilité du choix du serveur au client, ça sous-entend que le client connait les adresses réelles de tous les serveurs, et en terme de sécurité c'est déjà pas le top.

Dans notre cas, le load balancer/fail over (notre apache), agit comme une "porte d'entrée": on parle toujours avec lui, et lui sait quelle est la liste de serveurs disponibles, leurs adresses réelles, etc. et sait "router" les requêtes vers le serveurs le mieux adapté pour la tâche en cours.

Après tu as évoqué la notion de (Server)Socket. Tu n'es donc à priori pas dans un contexte web traditionnel (http), mais sur un protocole fait maison à base de tcp/ip. Bien qu'il existe également des load balancer purement TCP (et donc savent travailler avec de Socket et ServerSocket), je vérifierais par deux fois qu'un protocole de plus haut niveau ne soit pas plus intéressant (eg. REST, http+json), que cela soit en terme de maintenance, de fonctionnalités, de sécurité, d'interopérabilité, etc...

De nos jours, il n'y a pratiquement plus de cas d'utilisation qui justifient d'implémenter un protocole soi-même

[Cafeinoman]

Petite question, vu que c'est un travail de cour, as tu des limites en termes de techno ?

Si ce n'est pas le cas, vertx te permet de créer un serveur avec un bus d'événements (qui permet donc de publier a tout ceux qui écoutent), duplicable avec un loadbalancing automatiquement géré, et interfacable avec du tcp ou du http/rest. Sur un réseau local, tu peux même le faire serverless... et bien sur, il s'interface sans soucis avec des bdd.

[tchize_]

On peut aller très loin comme on peux faire très simpel, suivant les besoins.

En l'occurence si t'écoute juste sur un port, genre serveur IRC, tu peux avoir une simple infra avec les deux serveur qui se parlent pour s'envoyer les messages et les client qui se connectent directement aux serveur. La redondance peux se faire sans front end avec juste du loadbalancing dns. Simple et ne nécessitant pas de code particulier. Les deux serveur ont juste le même nom.

Pour la synchro entre les serveur. Soit tu y va à la mano basiquement pour les besoin d'un cours, soit tu peux utiliser d'autres librairies de synchro. Dans ce cas des outils comme Jgroups peuvent venir à la rescousse en gérant la couche transfert, discovering, election d'un maitre, ...

[flavors]

Bonour,

Merci pour toutes vos réponses, elles me donnent pas mal à creuser.
Pour ce qui est de ce projet de cours, nous ne sommes pas vraiment limité niveau technologie.
Je me suis penché sur le loadbalancing et pense avoir compris la chose (c'est vrai que ça semble répondre à ma problématique). Maintenant je dois essayer de l'implémenter.

Merci encore et bonne journée.