Problèmes d'évolutivité avec l'authentification basée sur le serveur

Question

Je lisais des problèmes avec l'authentification basée sur le serveur. J'ai besoin d'aide pour l'élaboration sur le point suivant. Évolutivité: Comme les sessions sont stockées en mémoire, cela entraîne des problèmes d'évolutivité. Au fur et à mesure que nos fournisseurs de cloud commencent à répliquer des serveurs pour gérer la charge applicative, le fait d'avoir des informations vitales dans la mémoire de session limite notre capacité à évoluer. Je ne comprends pas pourquoi «... avoir des informations vitales dans la mémoire de session limitera notre capacité d'échelle», cela limitera la capacité de mise à l'échelle. Est-ce juste parce que l'information est en train d'être répliquée? C'est donc une question de redondance? Je ne pense pas. Quoi qu'il en soit, quelqu'un aurait-il l'amabilité d'expliquer cela plus avant? Très appréciée.

Answer 1

L'authentification basée sur le serveur utilise des sessions qui, à leur tour, utilisent un identifiant de session local. Dans le cloud, lorsque les serveurs sont répliqués pour gérer la charge applicative, il devient difficile pour un serveur de savoir quelles sessions sont actives sur d'autres serveurs. Maintenant, pour surmonter ce problème, des étapes supplémentaires doivent être effectuées ... par exemple pour conserver l'identifiant de session sur la base de données. Cependant, comme les serveurs sont de plus en plus répliqués, il devient de plus en plus difficile de gérer tout cela. Par conséquent, l'authentification basée sur le serveur ou sur la session peut être problématique pour l'évolutivité.

Answer 2

On fait référence à la différence entre les opérations côté serveur sans état et avec état. Les serveurs avec état conservent une partie de leurs ressources (la mémoire principale, la plupart du temps) occupées pour conserver l'état de certains clients, même lorsque le serveur ne fait rien du tout pour le client et n'attend que le retour du client. Le profil de performance de ces systèmes est "linéaire" seulement jusqu'au point où toute la mémoire disponible a été remplie avec l'état, et au-delà de ce point, le serveur semble essentiellement décrocher. Les serveurs sans état ne conservent les ressources occupées que lorsqu'ils font quelque chose, et une fois les tâches terminées, ces ressources sont immédiatement libérées et disponibles pour les autres clients. Ces serveurs ne sont essentiellement pas plafonnés par des limites de mémoire et donc "scale easy". De plus, l'explication donnée semble se rapporter à des scénarios où un ensemble de machines distinctes se présentent au monde extérieur comme étant un, alors qu'elles ne le sont pas (ce qu'on appelle souvent un «groupe» de machines/serveurs). Dans un tel scénario, si un client s'est connecté à la «grande machine virtuelle unique», alors il est connecté à une des «machines réelles» du cluster. Si l'état est conservé, les visites ultérieures de ce même client doivent ensuite être routées vers la même machine physique, ou cet état doit être acheminé vers la machine à laquelle la prochaine visite se trouve. La première implique l'implémentation de fonctions de gestion qui prennent leur propre ensemble de ressources, plus les limitations sur la liberté du cluster pour répartir la charge (le contraire de pourquoi vous voulez faire du clustering), ce dernier implique un trafic réseau supplémentaire qui limite l'évolutivité essentiellement de la même manière que la mémoire disponible.